สรุปสั้น

เมื่อ 27 ตุลาคม 2569 Anthropic เผยว่าโมเดล AI ภายในของตนเขียน exploit ที่ยึดเซิร์ฟเวอร์ Linux ระดับ root จากเครือข่ายได้โดยไม่ต้องล็อกอิน (ดูข่าว 2026/10/308 ) ช่องโหว่ที่อยู่เบื้องหลัง คือ CVE-2026-98432 ซึ่งเป็นบั๊ก use-after-free (เคอร์เนลอ่านหน่วยความจำที่คืนไปแล้ว) ในโค้ดสร้างการเชื่อมต่อ TCP บน IPv4 มีมาตั้งแต่ Linux 4.4 และแก้ใน upstream ตั้งแต่ 5 ตุลาคม เว็บไซต์ The Hacker News ไล่ตรวจสถานะของแต่ละ distro ณ 29 ตุลาคม พบว่า Debian, Oracle Linux, SUSE บางรุ่น และ Amazon Linux บางแพ็กเกจออกเคอร์เนลที่แก้แล้ว แต่ Ubuntu และ Red Hat Enterprise Linux (RHEL) ยังไม่มีแพตช์และยังไม่ระบุวันออก

อีกประเด็นที่ทำให้ผู้ดูแลสับสน คือ คะแนนความรุนแรงต่างกันมาก ทีม CVE ของเคอร์เนลให้ 9.8 ขณะที่ Red Hat ให้ 5.9 ในหน้า CVE แต่ 8.1 ในไฟล์ประกาศ และ Oracle กับ SUSE ให้ 8.1 ส่วน Amazon ให้ 7.0 ความต่างมาจากการประเมินว่าแข่ง race condition ได้ยากแค่ไหน ยังไม่มีรายงานการโจมตีจริงและช่องโหว่ยังไม่อยู่ในรายการ KEV ของ CISA แต่ exploit ของ Anthropic ทำซ้ำได้โดยไม่ทำให้ระบบล่ม ผู้ดูแลควรติดตั้งเคอร์เนลที่แก้แล้วทันทีที่ distro ของตนปล่อย

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 29 ตุลาคม 2569 (อัปเดต 30 ตุลาคม) ว่า แพตช์ในเคอร์เนลให้เครดิตนาย Xinyang Ge นักวิจัยของ Anthropic เป็นผู้รายงาน ทั้งบันทึก CVE และแพตช์ไม่ได้พูดถึง multipath TCP (MPTCP) ความเชื่อมโยงกับฟีเจอร์นี้มาจากบทความของ Anthropic เท่านั้น ทีม CVE ของเคอร์เนลเผยแพร่ CVE เมื่อ 15 ตุลาคม และเพิ่มคะแนน 9.8 เมื่อ 24 ตุลาคม ณ 28 ตุลาคม NVD ยังไม่ให้คะแนนเอง และแสดงคะแนนของทีมเคอร์เนล ด้าน Red Hat เมื่อ 29 ตุลาคมระบุว่าการแก้ “เลื่อนไปในอัปเดตอนาคต” ก่อนเปลี่ยนสถานะ RHEL 8, 9, 10 และ OpenShift 4 เป็น Affected ในวันที่ 30 ตุลาคม และทีมความปลอดภัยของภาษา Go ออกคำแนะนำเพิ่มเมื่อ 29 ตุลาคม เพราะโปรแกรม Go ตั้งแต่ 1.24 เปิด MPTCP ให้ socket ที่รอรับการเชื่อมต่อโดยค่าเริ่มต้น

สถานะแพตช์ของ distro หลัก ณ 29–30 ตุลาคม 2569 มีดังนี้

Distributionคะแนนของผู้ผลิตสถานะแพ็กเกจหรือประกาศที่แก้
Ubuntu 22.04, 24.04, 26.04, 26.10Priority Highกำลังดำเนินการยังไม่ออก
Ubuntu 16.04, 18.04, 20.04Priority Highมีช่องโหว่ยังไม่ออก
RHEL 8, 9, 10 และ OpenShift 4Moderate 5.9 (หน้า CVE) / Important 8.1 (ไฟล์ประกาศ)Affectedยังไม่ออก
RHEL 7—ไม่กระทบไม่ต้องแก้
Amazon Linux 2023 แพ็กเกจ kernel6.18Important 7.0แก้แล้ว 24 ต.ค.ALAS2023-2026-3251
Amazon Linux 2023 แพ็กเกจ kernel6.12Important 7.0แก้แล้ว 29 ต.ค.ALAS2023-2026-3335
Amazon Linux 2 และ AL2023 แพ็กเกจ kernelImportant 7.0รอแก้ยังไม่ออก
Oracle Linux 7–10 (UEK)Important 8.1แก้แล้ว 16 ต.ค.ELSA-2026-500397/500398/500399
Debian trixie—แก้แล้ว 16 ต.ค.DSA-6568-1 (linux 6.12.113-1)
Debian 12 bookworm—แก้แล้ว 17 และ 22 ต.ค.DLA-4841-1, DLA-4850-1
SUSE Linux Micro 6.2, openSUSE Leap 16.0Important 8.1แก้แล้วkernel-default 6.12.0-160000.40.1 ขึ้นไป
SLES 15 SP4–SP6 LTSS, SLES 16.0, SLE Micro 5.3–5.5Important 8.1อยู่ระหว่างทดสอบยังไม่ออก
SLES 15 SP7Important 8.1กำลังแก้ยังไม่ออก

ข้อจำกัดของหลักฐานในเรื่องนี้มีหลายข้อ ดังนี้

  • บทความของ Anthropic ไม่มีโค้ด exploit — ไม่ระบุเวอร์ชันเคอร์เนลหรือคอนฟิกที่ทดสอบ
  • ไม่ชัดว่าต้องมี MPTCP หรือไม่ — Red Hat ระบุว่าผู้โจมตีที่เข้าถึงบริการ TCP ที่เปิดอยู่ก็กระตุ้น race ได้ แต่ exploit ระดับ root ของ Anthropic เล็งเซิร์ฟเวอร์ที่มี MPTCP listener และไม่บอกว่าเซิร์ฟเวอร์ที่ไม่มีจะถูกยึดแบบเดียวกันได้หรือไม่
  • ไม่มีมาตรการลดความเสี่ยงที่ยืนยันแล้ว — ทั้งประกาศของ distro และบทความ Anthropic ไม่ได้บอกว่าการปิด MPTCP หรือบล็อกแพ็กเก็ตที่มี IP options จะช่วยได้
  • คะแนนในหน้าเดียวกันยังขัดกัน — Red Hat แสดง Moderate 5.9 ในหน้า CVE ขณะที่ไฟล์ประกาศและระบบติดตามบั๊กยกเป็น Important 8.1 ในวันเดียวกัน

รายละเอียดช่องโหว่

บั๊กเกิดตอนจับมือ TCP — ระหว่างการสร้างการเชื่อมต่อ TCP (handshake) เมื่อการเชื่อมต่อสำเร็จ เคอร์เนลส่งต่อ IP options ที่เก็บไว้กับคำขอที่ค้างอยู่ให้ socket ใหม่โดยไม่คัดลอก ถ้า socket นั้นถูกทำลายขณะที่ CPU อีกตัวยังใช้ options เดิมเพื่อตอบคำขอเชื่อมต่อที่ถูกส่งซ้ำ เคอร์เนลจะอ่านหน่วยความจำที่คืนไปแล้ว IPv6 ไม่ได้รับผลเพราะเคอร์เนลคัดลอก options ให้การเชื่อมต่อ IPv6 แพตช์ทำให้เคอร์เนลรอจน CPU อื่นอ่านเสร็จก่อนคืนหน่วยความจำ

ทำไมคะแนนต่างกัน — ทีมเคอร์เนลสมมติว่าผู้โจมตีส่งคำขอเชื่อมต่อที่มี IPv4 options แบบ Record Route หรือ Timestamp แล้วส่งซ้ำเพื่อแข่ง race โดยมองว่าผู้โจมตีกระตุ้นทั้งสองฝั่งของ race ได้เอง จึงให้ความซับซ้อนต่ำ และระบุว่าผลอาจเป็นการส่งหน่วยความจำเคอร์เนลกลับไปให้ผู้โจมตี หน่วยความจำเสียหาย หรือระบบล่ม ด้าน Red Hat ในหน้า CVE ให้ 5.9 เพราะมองว่าแข่ง race ได้ยาก และผลที่น่าจะเกิดที่สุด คือ เคอร์เนลล่ม ส่วน Oracle และ SUSE ใช้ vector เดียวกับไฟล์ประกาศของ Red Hat (8.1) ซึ่งตรงกับทีมเคอร์เนลทุกตัวยกเว้นความซับซ้อนที่ให้เป็นสูง

exploit ของ Anthropic ทำงาน 2 ขั้น — ขั้นแรก race ทำให้เคอร์เนลส่งไบต์เกินกลับไปหาผู้โจมตี เมื่อคำตอบใดมีที่อยู่ของเคอร์เนล ผู้โจมตีก็ข้าม KASLR (กลไกสุ่มตำแหน่งเคอร์เนลในหน่วยความจำ) ได้ ขั้นที่สองใช้บั๊กเดิมทำ buffer overflow เขียนทับ callback pointer ให้ชี้ไปยังเพย์โหลดที่วางไว้ในหน่วยความจำเคอร์เนลแล้ว เมื่อเคอร์เนลเรียก pointer นั้น เพย์โหลดก็รันคำสั่งเชลล์ระดับ root การแพ้ race แค่ทำให้การเชื่อมต่อครั้งนั้นล้มเหลวโดยไม่ทำให้ระบบล่ม ผู้โจมตีจึงลองซ้ำได้ ในการทดสอบ การทำให้ที่อยู่รั่วใช้เวลา 48 นาที และอีก 5 นาทีจนรันคำสั่งได้

เวอร์ชันที่แก้และสถานะการโจมตี — แพตช์อยู่ใน Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 และ 7.3 ณ 29 ตุลาคม ไม่มีประกาศของผู้ผลิต บันทึก CVE หรือบทความ Anthropic ที่รายงานการโจมตีจริง และช่องโหว่ไม่อยู่ในสำเนารายการ KEV ของ CISA ที่ CIRCL ของลักเซมเบิร์กอัปเดตเมื่อ 28 ตุลาคม

ผลกระทบ

กลุ่มที่เสี่ยงที่สุด คือ เซิร์ฟเวอร์ Linux ที่เปิดบริการ TCP บน IPv4 สู่เครือข่ายภายนอก และมีโปรแกรมที่รอรับการเชื่อมต่อแบบ MPTCP ซึ่งรวมถึงบริการที่เขียนด้วย Go 1.24 ขึ้นไปที่เปิด MPTCP โดยค่าเริ่มต้นโดยที่ผู้ดูแลอาจไม่รู้ตัว ถ้าถูกโจมตีสำเร็จ ผู้โจมตีได้สิทธิ์ root เต็มเครื่องโดยไม่ต้องมีบัญชี ส่วนในกรณีที่ race ไม่สำเร็จ ผลที่เลวร้ายสุดตามการประเมินของ Red Hat คือ เคอร์เนลล่ม

ปัญหาเฉพาะหน้า คือ ผู้ใช้ Ubuntu และ RHEL ซึ่งเป็นสอง distro ที่ใช้มากที่สุดในเซิร์ฟเวอร์องค์กรยังไม่มีเคอร์เนลที่แก้ให้ติดตั้ง และ Red Hat ระบุว่าไม่มีมาตรการลดความเสี่ยงใดที่เข้าเกณฑ์ว่าใช้ง่าย เหมาะกับการติดตั้งส่วนใหญ่ และเสถียร ช่วงเวลาระหว่างที่รายละเอียดการโจมตีเปิดเผยแล้วกับที่แพตช์ยังไม่ออกจึงเป็นช่วงที่ต้องเฝ้าระวัง

คำแนะนำ

  • ติดตั้งเคอร์เนลที่แก้แล้วทันทีถ้า distro ปล่อยแล้ว — Debian, Oracle Linux, SUSE บางรุ่น และ Amazon Linux 2023 บางแพ็กเกจมีแพตช์ตามตารางด้านบน ติดตั้งแล้วรีบูตให้เคอร์เนลใหม่ทำงาน
  • ผู้ใช้ Ubuntu และ RHEL ติดตามประกาศอย่างใกล้ชิด — สมัครรับ USN ของ Ubuntu และประกาศ RHSA ของ Red Hat และเตรียมหน้าต่างรีบูตไว้ล่วงหน้า
  • ผู้ที่คอมไพล์เคอร์เนลเอง — อัปเกรดเป็นเวอร์ชัน stable ล่าสุดในสาย 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 หรือ 7.3 ทีมเคอร์เนลไม่สนับสนุนการ cherry-pick แพตช์เดี่ยว
  • สำรวจโปรแกรมที่เปิด MPTCP — ตรวจ socket ที่ใช้ MPTCP ด้วยคำสั่ง ss -M และทบทวนบริการที่เขียนด้วย Go 1.24 ขึ้นไป
  • โปรแกรม Go ปิด MPTCP ชั่วคราว — ตั้ง GODEBUG=multipathtcp=0 ในสภาพแวดล้อมของโปรแกรม หรือใส่ godebug multipathtcp=0 ใน go.mod ของโมดูลหลัก แต่โค้ดที่เรียก SetMultipathTCP จะทับค่านี้ ทีม Go ย้ำว่าเป็นมาตรการที่เปราะบาง เพราะบั๊กไม่ได้จำเพาะกับ MPTCP และวิธีที่ดีที่สุดยังเป็นการอัปเดตเคอร์เนล
  • จำกัดการเข้าถึงบริการที่ไม่ต้องเปิดสู่ภายนอก — ระหว่างรอแพตช์ ใช้ไฟร์วอลล์ลดจำนวนพอร์ต TCP ที่เข้าถึงได้จากอินเทอร์เน็ต เพื่อลดพื้นที่ที่ผู้โจมตีใช้แข่ง race
  • เฝ้าดูเคอร์เนลล่มผิดปกติ — การล่มซ้ำ ๆ ของเซิร์ฟเวอร์ที่เปิดสู่ภายนอกอาจเป็นสัญญาณของความพยายามโจมตี ให้เก็บ kernel log และ crash dump ไว้ตรวจสอบ

แหล่งอ้างอิง