ช่องโหว่ Linux kernel Fragnesia ถูกโจมตีจริง เช็กเวอร์ชันและอัปเดตอย่างไร

ช่องโหว่ Linux kernel ที่เปลี่ยนผู้ใช้ธรรมดาเป็น root

Fragnesia เป็นช่องโหว่ยกระดับสิทธิ์ภายในเครื่อง (local privilege escalation) คำว่ายกระดับสิทธิ์หมายความว่าคนที่มีบัญชีผู้ใช้ธรรมดาในเครื่อง ทำตัวให้กลายเป็น root หรือผู้ดูแลระบบสูงสุดได้ ตามที่ผู้เชี่ยวชาญด้านความปลอดภัยอธิบายไว้ ผู้โจมตีต้องมีบัญชีในเครื่องอยู่ก่อน ช่องโหว่นี้อยู่ในระบบย่อย XFRM ESP-in-TCP ของเคอร์เนล คะแนน CVSS v3 อยู่ที่ราว 7.8 ซึ่งเป็นระดับสูง (ข้อมูลส่วนนี้อ้างตามบทความของ Security Boulevard สื่อความปลอดภัย ไม่ใช่ผู้ผลิต)

ฝั่ง Ubuntu อธิบายต้นเหตุว่าเป็นข้อผิดพลาดด้านเครือข่ายในเคอร์เนล เมื่อโค้ดย้ายข้อมูลจาก socket buffer หนึ่งไปอีกอันหนึ่ง ตัวบ่งชี้ว่าข้อมูลส่วนนั้นใช้ร่วมกันอยู่หายไป โค้ดส่วนถอดรหัส ESP จึงถอดรหัสทับข้อมูลที่ผูกกับ page cache ได้ CISA สรุปผลไว้ว่าเกิดการแก้ไขข้อมูลใน page cache โดยไม่ได้รับอนุญาต ทีมความปลอดภัยของ Ubuntu เตือนว่าผู้โจมตีในเครื่องอาจยกระดับสิทธิ์ หรืออาจหลุดออกจากคอนเทนเนอร์ได้

ช่องโหว่นี้เปิดเผยเมื่อวันที่ 13 พ.ค. 2569 โดย William Bowling จาก V12 Security พร้อมโค้ดพิสูจน์แนวคิดที่เผยแพร่สาธารณะ ตอนนั้นบทความวิเคราะห์ระบุว่ายังไม่มีรายงานโจมตีจริงและยังไม่อยู่ใน KEV สถานะนี้เปลี่ยนไปแล้วเมื่อ CISA ขึ้นบัญชี นอกจากนี้ แพตช์ของช่องโหว่ Dirty Frag ที่เคยออกมาไม่ครอบคลุมช่องโหว่นี้ ต้องลงเคอร์เนลที่แก้ Fragnesia โดยเฉพาะ ผู้ที่คิดว่าอัปเดตเรื่อง Dirty Frag ไปแล้วจึงยังไม่ปลอดภัยโดยอัตโนมัติ

เมื่อเว็บ PHP ที่ถูกเจาะเจอช่องโหว่เคอร์เนล

ความเสี่ยงของช่องโหว่ยกระดับสิทธิ์อยู่ที่การต่อกับช่องโหว่อื่น CISA ระบุว่า Fragnesia ใช้ต่อกับ CVE-2026-109618 และ CVE-2026-109619 (กลุ่มช่องโหว่ PHP2Shell) ได้ ผลคือฝัง PHP webshell แล้วรันคำสั่งเป็น root ได้ สำหรับเจ้าของเว็บ นี่หมายความว่าการอุดช่องโหว่ฝั่งแอปพลิเคชันอย่างเดียวไม่พอ ต้องอัปเดตเคอร์เนลของเซิร์ฟเวอร์ด้วย จึงจะปิดทั้งสองชั้น

เซิร์ฟเวอร์ที่มีผู้ใช้หลายคนใช้ร่วมกัน เช่น โฮสติ้งแบบแชร์ และเครื่องที่รันคอนเทนเนอร์ เสี่ยงเป็นพิเศษ เพราะต้องมีบัญชีในเครื่องก่อนจึงจะโจมตีได้ และเทคนิคนี้ใช้ user namespace กับ network namespace ซึ่งเปิดไว้โดยปริยายในดิสโทรส่วนใหญ่ ตามบทความของ Security Boulevard ส่วนผู้ที่ใช้เครื่องคนเดียวและไม่มีบริการที่เปิดให้ผู้อื่นรันโค้ดก็ไม่ควรชะล่าใจ เพราะหากมีเว็บแอปที่ถูกเจาะได้ ผู้โจมตีก็ได้ที่ยืนในเครื่องแล้ว

ตรวจเวอร์ชันเคอร์เนลและอัปเดตให้ครบ

ขั้นแรกให้รู้ว่าเครื่องใช้เคอร์เนลรุ่นไหน เปิดเทอร์มินัลแล้วพิมพ์ uname -r จะได้เลขรุ่น เช่น 6.8.0-124-generic จากนั้นเทียบกับรุ่นที่แก้แล้วของดิสโทรที่ใช้ ทุกดิสโทรมีประกาศความปลอดภัยของตัวเอง ดังนั้นต้องเปิดประกาศของผู้ผลิตเสมอ ผู้ใช้ Debian, RHEL, AlmaLinux, Amazon Linux หรือ CloudLinux ให้เปิดประกาศความปลอดภัยของดิสโทรตัวเองเพื่อดูรุ่นที่แก้

• รัน sudo apt update เพื่อดึงรายการแพ็กเกจล่าสุด (สำหรับ Ubuntu)
• รัน sudo apt upgrade เพื่อติดตั้งเคอร์เนลที่แก้แล้ว
• รีบูตเครื่องด้วย sudo reboot เพื่อให้เคอร์เนลใหม่เริ่มทำงาน
• รัน uname -r อีกครั้ง แล้วเทียบเลขรุ่นกับตารางของผู้ผลิต

อย่าลืมขั้นรีบูต การติดตั้งเคอร์เนลใหม่ไม่ได้ทำให้เครื่องที่เปิดอยู่เปลี่ยนมาใช้เคอร์เนลใหม่ทันที ถ้าไม่รีบูต uname -r จะยังแสดงรุ่นเดิม ซึ่งยังมีช่องโหว่อยู่

Ubuntu รุ่นไหนต้องอัปเดตเป็นเคอร์เนลรุ่นไหน

ตามหน้า Ubuntu Security ของ CVE-2026-46300 แพ็กเกจ linux หลักของ Ubuntu แต่ละรุ่นที่แก้แล้วเป็นดังนี้ ช่องโหว่นี้อยู่ในระดับความสำคัญสูง (High) ของ Ubuntu

• Ubuntu 26.04 LTS แก้แล้วในเคอร์เนล 7.0.0-22.22
• Ubuntu 25.10 แก้แล้วในเคอร์เนล 6.17.0-35.35
• Ubuntu 24.04 LTS แก้แล้วในเคอร์เนล 6.8.0-124.124
• Ubuntu 22.04 LTS แก้แล้วในเคอร์เนล 5.15.0-181.191

Ubuntu 26.10, 20.04 LTS และ 18.04 LTS ระบุว่าไม่ได้รับผลกระทบสำหรับแพ็กเกจ linux หลัก หน้าเดียวกันยังแสดงการแก้ไขของเคอร์เนลสายอนุพันธ์ เช่น linux-aws, linux-azure และ linux-gcp ซึ่งมีเลขรุ่นของตัวเอง ใครใช้ VPS บนคลาวด์ที่ติดตั้งเคอร์เนลสายเหล่านี้ ควรเปิดหน้าดังกล่าวเช็กรุ่นของแพ็กเกจที่ตรงกับเครื่อง

ถ้าอัปเดตทันทีไม่ได้ และหลังอัปเดตต้องตรวจอะไร

สำหรับกรณีที่ยังรีบูตหรืออัปเดตไม่ได้ทันที บทความของ Security Boulevard เมื่อ พ.ค. แนะนำวิธีชั่วคราวคือถอดโมดูล esp4, esp6 และ rxrpc ด้วยคำสั่ง rmmod แล้วตั้งค่าไม่ให้โหลดกลับมาในไฟล์ใต้ /etc/modprobe.d นี่เป็นคำแนะนำจากสื่อความปลอดภัย ไม่ใช่จากผู้ผลิตเคอร์เนล การปิดโมดูลกลุ่มนี้อาจกระทบการใช้งาน IPsec หรือ VPN ให้ตรวจว่าเครื่องใช้บริการเหล่านี้อยู่หรือไม่ก่อนปิด และถือเป็นทางออกชั่วคราวเท่านั้น

หลังอัปเดต CISA ให้หน่วยงานทำ forensic triage (การตรวจพิสูจน์หลักฐานเบื้องต้น) ตามแนวทาง BOD 26-04 ผู้ดูแลเซิร์ฟเวอร์ทั่วไปไม่ได้ถูกบังคับตามคำสั่งนี้ แต่ใช้เป็นแนวทางได้ เพราะ CISA ระบุว่าช่องโหว่นี้ใช้ฝัง PHP webshell ได้ จึงควรไล่ดูไฟล์ PHP ที่ไม่รู้จักในโฟลเดอร์เว็บ และคำสั่งที่รันด้วยสิทธิ์ root ที่ไม่ใช่ฝีมือของทีม มีข้อควรระวังอีกอย่างคือโค้ดพิสูจน์แนวคิดที่เปิดเผยตอน พ.ค. แก้ไฟล์ /usr/bin/su เฉพาะใน page cache ส่วนไฟล์บนดิสก์ไม่เปลี่ยน การตรวจแค่ว่าไฟล์บนดิสก์ถูกแก้หรือไม่ จึงอาจไม่เจอร่องรอย

ที่มา: หน้าบัญชีช่องโหว่ที่ถูกโจมตีจริง (KEV) ของ CISA, หน้า Ubuntu Security ของ CVE-2026-46300, บทความของ Security Boulevard (สื่อความปลอดภัย ใช้อ้างข้อมูลการเปิดเผยช่องโหว่ ข้อกำหนดเบื้องต้น และวิธีบรรเทาชั่วคราว)