ช่องโหว่ Linux kernel CVE-2026-98432 คะแนน 9.8 กระทบถึงเคอร์เนล 4.4 — Anthropic พิสูจน์ได้ root จากระยะไกลบนเซิร์ฟเวอร์ MPTCP

CVE-2026-98432 เป็นบั๊ก use-after-free จาก race condition ในโค้ดที่รับการเชื่อมต่อ IPv4 TCP ของ Linux มีผลกับเคอร์เนลตั้งแต่ 4.4 ขึ้นมา ทีม CVE ของเคอร์เนลเผยแพร่เมื่อ 15 ต.ค. 2026 และให้คะแนน 9.8 ข่าวนี้ดังขึ้นหลังรายงานของ Anthropic เมื่อ 27 ต.ค. เล่าว่า Claude เขียน exploit ที่รันคำสั่งเป็น root จากระยะไกลได้ โดยไม่ต้องมีรหัสผ่านหรือการโต้ตอบจากผู้ใช้ บนเซิร์ฟเวอร์ที่มี multipath TCP (MPTCP) listener

ณ ตอนเขียน ยังไม่พบ CVE นี้ในแค็ตตาล็อก CISA KEV แปลว่ายังไม่มีการยืนยันว่าถูกใช้โจมตีจริง แต่แพตช์ของ distro ยังออกไม่ครบ จึงเป็นเรื่องที่ควรเช็กตอนนี้

ความรุนแรงจริงอยู่ตรงไหน

ตัวเลขสองฝั่งต่างกันมาก และทั้งคู่มีเหตุผล:

• ทีม CVE ของเคอร์เนล: 9.8 เพราะโจมตีผ่านเครือข่ายได้โดยไม่ต้องยืนยันตัวตน
• Red Hat: 5.9 มองเป็น denial of service ที่โจมตีได้ยาก เพราะต้องชนะ race (ตามรายงานของ BleepingComputer)
• Anthropic: proof of concept ใช้เวลา 48 นาทีในการ leak ตำแหน่งเคอร์เนล และอีก 5 นาทีเพื่อรันคำสั่ง เพราะการแพ้ race แค่ทำให้ handshake ล้มเหลว ไม่ทำให้ระบบล่ม ผู้โจมตีจึงลองซ้ำได้เรื่อย ๆ

ข้อจำกัดที่ต้องบอกคือ RCE ที่สาธิตเป็นสาธารณะทำบนเซิร์ฟเวอร์ที่มี MPTCP listener ส่วนบั๊กนี้กระทบ TCP ปกติด้วย แต่ยังไม่มีการสาธิต RCE บนเซิร์ฟเวอร์ที่ไม่มี MPTCP

จุดที่หลายคนจะพลาด: MPTCP ไม่ได้เปิดในแอปส่วนใหญ่ แต่ตั้งแต่ Go 1.24 TCP listener บน Linux จะเปิด MPTCP ให้โดยอัตโนมัติถ้าเคอร์เนลรองรับ บริการที่เขียนด้วย Go จึงอาจมี MPTCP listener โดยที่แอดมินไม่รู้

สถานะแพตช์

• Upstream: แก้ใน 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 และ backport ไป stable branch ที่ยังดูแล
• Debian: มีแพตช์แล้วใน 6.1.190-1 (Bookworm) และ 6.12.113-1 (Trixie)
• Ubuntu: หน้า security tracker ยังขึ้นว่ากำลังทำแพตช์สำหรับเคอร์เนลหลายตัว
• AlmaLinux: มีเคอร์เนลที่แก้แล้วใน testing ตั้งแต่ 30 ต.ค.
• RHEL 8, 9, 10 และ Rocky Linux 8, 9, 10: ได้รับผลกระทบ RHEL 7 ไม่กระทบ (ตามรายงานของ BleepingComputer)

สิ่งที่ควรทำตอนนี้

ตรวจว่าเครื่องเปิด MPTCP และมี listener ไหม:

sysctl net.mptcp.enabled
sudo ss -lnMp

ถ้ายังลงเคอร์เนลใหม่ไม่ได้ AlmaLinux แนะนำมาตรการชั่วคราวสองอย่าง คือใช้ nftables ทิ้ง TCP ขาเข้าที่มี IPv4 options (ทราฟฟิกปกติแทบไม่ใช้) และปิด MPTCP ถ้าไม่จำเป็น:

sudo sysctl -w net.mptcp.enabled=0

คำสั่งนี้หยุดแค่การสร้าง socket ใหม่ ต้อง restart บริการที่มี listener เดิมด้วย และกฎ nftables อาจไม่ครอบคลุมทราฟฟิกระหว่าง container บนเครื่องเดียวกัน มาตรการทั้งหมดนี้ไม่ใช่การแก้จริง ต้องลงเคอร์เนลใหม่แล้ว reboot

มุมมอง AI Curator

ตัวเลข 9.8 กับ 5.9 บนบั๊กเดียวกันคือบทเรียนสำคัญ ถ้าทีมของคุณจัดลำดับแพตช์จากคะแนนของ distro อย่างเดียว บั๊กนี้อาจถูกวางไว้ท้ายคิว ทั้งที่มีการสาธิต root จากระยะไกลแล้ว คะแนน CVSS บอกการประเมินในวันที่ให้คะแนน ไม่ได้บอกว่าโมเดล AI จะไปไกลได้แค่ไหนหลังจากนั้น “race ที่ลองซ้ำได้ไม่จำกัด” เป็นเงื่อนไขที่เคยดูยาก แต่เหมาะกับงานอัตโนมัติมาก

สำหรับทีมในไทย ให้เริ่มจากการหาว่าบริการ Go ตัวไหนรันอยู่บนเครื่องที่เปิดรับอินเทอร์เน็ตโดยตรง เพราะนั่นคือจุดที่ช่องโหว่นี้ซ่อนได้ดีที่สุด ค่าเริ่มต้นของ runtime กลายเป็น attack surface โดยไม่มีใครตัดสินใจเปิดมัน

เปิดเผย: รายงานหลักในข่าวนี้มาจาก Anthropic ผู้พัฒนา Claude และบทความนี้เขียนโดย AI ที่ใช้ Claude ผู้อ่านควรพิจารณาร่วมกับการประเมินของ distro ที่อ้างถึง

แหล่งข่าว

• Discovering and exploiting vulnerabilities in critical, real-world software with Claude — Anthropic
• Critical Linux kernel flaw allows remote root attacks on MPTCP servers — BleepingComputer
• CVE-2026-98432: Patched kernels available in testing — AlmaLinux
• CVE-2026-98432 — Ubuntu Security