CVE-2026-98432: Ubuntu และ RHEL ยังไม่มีแพตช์ และ Claude Model ได้เขียน Exploit ขึ้นมาแล้ว

สองข้อเท็จจริงเกี่ยวกับ CVE-2026-98432 ไม่ได้สอดคล้องกันอย่างลงตัวนัก มันเป็นช่องโหว่ use-after-free ในขั้นตอนการจับมือ TCP แบบ IPv4 ของเคอร์เนล Linux ที่เข้าถึงได้ผ่านเครือข่ายโดยไม่ต้องเข้าสู่ระบบและไม่ต้องมีปฏิสัมพันธ์ใด ๆ และทีม CVE ของเคอร์เนลให้คะแนน 9.8 ณ วันที่ 30 ตุลาคม 2026 Ubuntu ยังไม่มีแพตช์ที่เผยแพร่สำหรับ 22.04, 24.04, 26.04 หรือ 26.10 และ Red Hat ระบุว่า RHEL 8, 9 และ 10 ได้รับผลกระทบ โดยไม่มีแพตช์และไม่มีมาตรการบรรเทาที่ได้รับการรับรอง ข้อเท็จจริงประการที่สองคือเมื่อวันที่ 27 ตุลาคม Anthropic เผยแพร่งานวิจัยที่ระบุว่าโมเดล Claude ที่ยังไม่เปิดตัวสร้าง proof of concept ที่ใช้งานได้สำหรับการเป็น root จากระยะไกลโดยไม่ต้องยืนยันตัวตนต่อเซิร์ฟเวอร์ที่มีตัวรับฟัง MPTCP — ใช้เวลาประมาณ 48 นาทีในการรั่วไหลที่อยู่เคอร์เนล และอีกห้านาทีเพื่อไปถึงการรันคำสั่ง

ช่องโหว่ที่ผู้จำหน่าย Linux ระดับองค์กรรายใหญ่ที่สุดสองรายยังไม่สามารถแพตช์ได้ พร้อม exploit ที่ใช้งานได้จริงซึ่งเขียนขึ้นบางส่วนโดยเครื่องจักร ไม่ใช่ Patch Tuesday ตามปกติ แต่เป็นกรณีที่ชี้ขาดว่ากระบวนการอัปเกรดเคอร์เนลและนโยบายการเข้าถึงของ agent ของคุณมีความเกี่ยวข้องกันหรือไม่

บั๊ก ในหนึ่งย่อหน้า

เมื่อกำลังตั้งค่าการเชื่อมต่อ TCP ตัวเลือก IP ที่แนบมากับแพ็กเก็ตขาเข้าจะถูกส่งต่อไปยังซ็อกเก็ตใหม่แทนการคัดลอก หากแฮนด์เชกส่งซ้ำ แพ็กเก็ตอาจถูกประมวลผลบน CPU ที่ต่างจากตัวที่เป็นเจ้าของบัฟเฟอร์ตัวเลือก — และ CPU ตัวที่สองนั้นสามารถอ่านหน่วยความจำที่ตัวแรกปล่อยไปแล้ว มีสภาวะการแข่งกันแบบเดียวกันในเส้นทางการย้ายคำขอ ช่วงที่ได้รับผลกระทบเริ่มตั้งแต่เคอร์เนล 4.4 ซึ่งหมายความว่าเครื่องส่วนใหญ่ที่ยังรันเคอร์เนลที่ได้รับการดูแลอยู่ก็อยู่ในช่วงนี้ การแก้ไขจากต้นทาง คอมมิต code>e3f33b0a1d89/code> เลื่อนการปล่อยบัฟเฟอร์ตัวเลือกออกไปจนกว่าจะไม่มีคอร์อื่นใดที่ยังถือการอ้างอิงอยู่ได้

ความเป็นไปได้ในการโจมตี (exploitability) เกิดขึ้นจากกลไกเหล่านี้: ไม่มีการยืนยันตัวตน ไม่ต้องมีการโต้ตอบของผู้ใช้ มีเส้นทางที่เข้าถึงได้ผ่านเครือข่าย และมีการแข่ง (race) ที่สามารถลองใหม่ได้ สรุปของ Anthropic เองว่าทำไม PoC จึงใช้งานได้จริงก็คือคุณสมบัติข้อนั้นพอดี — การแพ้ในการแข่งทำให้แฮนด์เชกหนึ่งครั้งล้มเหลว แทนที่จะทำให้เครื่องล่ม ดังนั้นผู้โจมตีจึงลองอีกครั้ง

ผู้ขายสามราย ตัวเลขความรุนแรงสามค่า

ส่วนที่ควรทำความเข้าใจให้ลึกซึ้งคือการแบ่งเกณฑ์การให้คะแนน เพราะมันเป็นตัวกำหนดว่าสแกนเนอร์ของคุณจะเปิดทิกเก็ตในสัปดาห์นี้หรือไม่

• Kernel CVE team — 9.8 ระดับวิกฤต เข้าถึงได้ผ่านเครือข่าย ไม่ต้องมีสิทธิ์ ไม่ต้องมีปฏิสัมพันธ์

• Red Hat — 8.1, สำคัญ จุดยืนของบริษัทคือการแข่งขันนั้นยากที่จะชนะในทางปฏิบัติ

• Ubuntu — ความสำคัญสูง โดยไม่มีการเผยแพร่คะแนนเป็นตัวเลขบนหน้าที่ตรวจสอบ

ช่องว่างระหว่าง 9.8 กับ 8.1 ไม่ใช่ความเห็นต่างเกี่ยวกับบั๊ก แต่เป็นความเห็นต่างเกี่ยวกับความน่าจะเป็นที่จะชนะ race ทั้งสองค่ามีเหตุผลรองรับได้ และความแตกต่างนี้สำคัญในเชิงปฏิบัติการ: 9.8 ที่มี PoC สาธารณะคือเหตุฉุกเฉิน ขณะที่ 8.1 ที่มี race ยากคือการแก้ไขตามกำหนด จนกว่าจะมีคนเผยแพร่ตัวเลขการเกิดซ้ำบนฮาร์ดแวร์จริง การตีความอย่างตรงไปตรงมาคือ race นี้ชนะได้ เนื่องจากมีรายงานว่าโมเดลระดับแนวหน้าชนะมันได้

ใครมีทางแก้ และใครไม่มี

ณ วันที่ 29–30 ตุลาคม ภาพรวมยังไม่สม่ำเสมอในลักษณะที่ทำให้ผู้ที่คิดว่าเคอร์เนลที่เสถียรหมายถึงเคอร์เนลที่ได้รับการแพตช์แล้วนั้นเข้าใจผิด

• Debian 12 bookworm — แก้ไขแล้วใน 6.1.190-1 ผ่าน DLA-4841-1

• Debian 13 trixie — แก้ไขแล้วใน 6.12.113-1 ผ่าน DSA-6568-1

• Ubuntu 22.04, 24.04, 26.04, 26.10 — ยังไม่มีการแก้ไขที่เผยแพร่แล้ว; อยู่ระหว่างดำเนินการ

• Ubuntu 16.04, 18.04, 20.04 — มีช่องโหว่ ยังไม่มีการเผยแพร่การแก้ไข

• RHEL 8, 9, 10 และ OpenShift 4 — ได้รับผลกระทบ ไม่มีวิธีแก้ไข และไม่มีการบรรเทาผลกระทบที่ได้รับการรับรองจาก Red Hat

• RHEL 6 และ 7 — ไม่ได้รับผลกระทบ

• Amazon Linux 2023 — รายงานว่าเคอร์เนล 6.18 ได้รับการแก้ไขแล้ว; Oracle Linux UEK รายงานว่าได้รับการแก้ไขแล้ว; SUSE รายงานว่าบางรีลีสได้รับการแก้ไขแล้ว และบางรุ่นยังอยู่ระหว่างการทดสอบ โดยไม่ได้ระบุชื่อเวอร์ชัน

รีลีสเสถียรจากอัปสตรีมที่มีแพตช์แก้ไข ได้แก่ 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 และ 7.3 — ซึ่งเป็นรายการที่คุณควรใช้ตรวจสอบเทียบกับบิลด์ของคุณเอง หากคุณคอมไพล์เคอร์เนลเองแทนที่จะใช้แพ็กเกจจากดิสทริบิวชัน

ทำไม MPTCP ถึงถูกพูดถึงอยู่เรื่อย ๆ

บั๊กนี้ไม่ได้เฉพาะเจาะจงกับ MPTCP และนี่คือจุดที่การรายงานข่าวจำนวนมากเข้าใจผิด Red Hat มองว่าบริการ TCP ใดก็ตามที่เข้าถึงได้เป็นตัวกระตุ้นที่เป็นไปได้ สิ่งที่ MPTCP จัดหาให้คือเส้นทางที่พิสูจน์แล้ว และสิ่งที่สร้างทราฟฟิกคือ Go: เวอร์ชัน 1.24 ขึ้นไปจะเปิดใช้งาน Multipath TCP โดยค่าเริ่มต้นสำหรับซ็อกเก็ตที่รับฟังบน Linux เมื่อเคอร์เนลเปิด MPTCP อยู่ ทีมความปลอดภัยของ Go ได้เตือนเกี่ยวกับการรวมกันนี้เมื่อวันที่ 29 ตุลาคม

ดังนั้น การ "ปิดใช้งาน MPTCP" จึงตัดเส้นทางที่ Anthropic สาธิตให้เห็นออกไป ไม่ได้กำจัดช่องโหว่ เป็นมาตรการชั่วคราวที่ปกป้องได้ในระดับหนึ่ง โดยมีข้อแม้เฉพาะเจาะจง: ในวันนี้คุ้มค่าที่จะทำกับบริการที่เขียนด้วย Go และมันไม่ใช่สิ่งทดแทนเคอร์เนลที่ได้รับการแพตช์แล้ว

การตรวจสอบนั้นสั้น:

• code>ss -Mltnp/code> — แสดงรายการซ็อกเก็ตที่กำลังใช้งาน MPTCP อยู่ในปัจจุบัน

• code>net.mptcp.enabled/code> — ฟีเจอร์เคอร์เนลเปิดใช้งานอยู่หรือไม่

• code>net.ipv4.tcp_migrate_req/code> — ปิดเป็นค่าเริ่มต้น; หากคุณเปิดใช้งานไว้ ให้ปิดกลับไปอีกครั้ง

สำหรับ Go โดยเฉพาะ code>GODEBUG=multipathtcp=0/code> ในขณะรัน หรือ code>godebug/code> ที่เป็นบรรทัดใน code>go.mod/code> จะทำให้ไบนารีเลือกที่จะไม่ใช้

ไม่มีรายการใดได้รับการรับรองจากผู้จำหน่าย Red Hat ระบุตรง ๆ ว่าไม่มีมาตรการบรรเทาผลกระทบใดที่ผ่านมาตรฐานของตนเอง ซึ่งเป็นประโยคที่มีประโยชน์มากกว่ารายการวิธีเลี่ยงปัญหาที่หวังว่าจะได้ผล

สิ่งที่ Anthropic เผยแพร่จริง ๆ

งานวิจัยนี้แคบและเฉพาะเจาะจง โมเดล Claude ที่ยังไม่เปิดตัว เมื่อได้รับ CVE และเป้าหมายที่มีตัวรับฟัง MPTCP ได้สร้างเชนที่รั่วไหลที่อยู่เคอร์เนลภายในเวลาประมาณ 48 นาที และไปถึงการรันคำสั่งได้ราวห้านาทีถัดมา Anthropic ยังไม่ได้เผยแพร่ exploit และ ณ วันที่ 29 ตุลาคม ทั้งผู้จำหน่ายและบันทึก CVE ยังไม่มีรายงานการโจมตีในสภาพจริง ช่องโหว่นี้ไม่อยู่ในแคตตาล็อก KEV ของ CISA เมื่อวันที่ 30 ตุลาคม ที่เก็บ GitHub ของบุคคลที่สามได้เผยแพร่เครื่องมือแล็บสำหรับทริกเกอร์ race และการรั่วไหลของหน่วยความจำ ซึ่งเป็นฮาร์เนสสำหรับทำซ้ำ โดยยังไม่ถึงขั้นการรันโค้ดเต็มรูปแบบ

การผสมผสานนั้นคือส่วนที่น่าสนใจ ความสามารถถูกแสดงให้เห็น อาวุธถูกเก็บงำไว้ และรายละเอียดที่ทำให้มันเกิดขึ้น — คุณสมบัติการลองใหม่ซึ่งเปลี่ยนการแข่งขันที่เปราะบางให้กลายเป็นสิ่งที่เชื่อถือได้ — เปิดเผยต่อสาธารณะในรูปแบบร้อยแก้ว ใครก็ตามที่สามารถจำลองการแข่งขันนั้นได้ตอนนี้ย่อมรู้แล้วว่าทำไมมันจึงคุ้มค่าที่จะยืนหยัดต่อไป

สิ่งที่ต้องทำในสัปดาห์นี้

• แพตช์และรีบูตเมื่อมีวิธีแก้ไข การแก้ไขเคอร์เนลที่ติดตั้งแล้วแต่ยังไม่ได้รีบูตไม่ถือเป็นการแก้ไข; ตรวจสอบด้วย code>uname -r/code>.

• ในกรณีที่ดิสทริบิวชันของคุณยังไม่มีแพตช์ — Ubuntu 22.04 ถึง 26.10, RHEL 8 ถึง 10 — จงตัดสินใจตอนนี้ว่าคุณจะใช้ไลฟ์แพตช์จากผู้จำหน่าย ย้ายไปยังเวอร์ชันที่ได้รับการแก้ไขแล้ว หรือยอมรับความเสี่ยงโดยปิด MPTCP บนบริการ Go

• ตรวจสอบการเปิดรับ MPTCP แทนที่จะถือว่าปิดอยู่ ค่าเริ่มต้นเปลี่ยนไปใน Go ไม่ใช่ในการกำหนดค่าของคุณ และการเปลี่ยนแปลงค่าเริ่มต้นจะมองไม่เห็นใน config diff

• ซ้อมการรีบูต การแก้ไขประเภทนี้ต้องรีสตาร์ทแบบเต็มรูปแบบ และองค์กรที่จะเสียเวลามากที่สุดคือองค์กรที่เพิ่งมาค้นพบเรื่องราว failover ของตนเองในช่วงเวลาบำรุงรักษา

สองคำถามที่ CVE นี้ยกขึ้นมาจริง ๆ

เรื่องแรกเกี่ยวกับการสร้างเอ็กซ์พลอยต์ และมันไม่ใช่เรื่องปรัชญา โมเดลหนึ่งค้นพบลำดับหนึ่งที่นักวิจัยมนุษย์จำนวนมากไม่พบ บนเป้าหมายที่มีการกำหนดค่าที่เอื้ออำนวยเฉพาะเจาะจง ภายในเวลาไม่ถึงชั่วโมง ไม่ว่าจะเผยแพร่เอ็กซ์พลอยต์นั้นหรือไม่ กรอบเวลาก็เปลี่ยนไปแล้ว: ช่วงเวลาระหว่างประกาศเตือนภัยสาธารณะกับเอ็กซ์พลอยต์ที่ใช้งานได้ ตอนนี้ถูกวัดเทียบกับโมเดลที่อ่านประกาศนั้น

ประเด็นที่สองว่าด้วยความหมายของการแพตช์เมื่อผู้จำหน่ายไม่สามารถแพตช์ได้ ดิสทริบิวชันที่ส่งเคอร์เนลมาให้คุณกับเคอร์เนลที่มีแพตช์แก้ไขนั้นไม่ใช่สิ่งเดียวกัน และช่องว่างระหว่างทั้งสองก็คือที่ที่ช่องโหว่นี้ดำรงอยู่สำหรับผู้อ่านโพสต์นี้ส่วนใหญ่ OrcaRouter AI Incident Archive จัดทำดัชนีเหตุการณ์เช่นนี้เทียบกับแหล่งข้อมูลปฐมภูมิ ระดับความรุนแรง และระดับความเชื่อมั่น ซึ่งเป็นฉบับของเรื่องนี้ที่ควรค่าแก่การเก็บรักษาไว้เมื่อกระแสข่าวเคลื่อนผ่านไป

สิ่งที่ไม่ควรทำคือจัดเรื่องนี้ไว้ในหมวด “รอผู้ขาย” หน้าของผู้ขายเองระบุว่ายังไม่มีอะไรให้ต้องรอในตอนนี้

หมายเหตุแหล่งที่มา: กลไก ช่วงที่ได้รับผลกระทบตั้งแต่เคอร์เนล 4.4 คอมมิตต้นทาง code>e3f33b0a1d89/code> รายการเวอร์ชันเสถียรและคำแนะนำการบรรเทามาจากบันทึก CVE และประกาศของดิสทริบิวชันที่อ่านเมื่อวันที่ 30 ตุลาคม 2026 คะแนน 9.8, 8.1 และระดับ High ของ Ubuntu เป็นของทีม CVE ของเคอร์เนล ของ Red Hat และของ Canonical ตามลำดับ สถานะแพตช์แยกตามดิสทริบิวชันมาจาก DLA-4841-1 และ DSA-6568-1 ของ Debian หน้า CVE ของ Red Hat และ Ubuntu และแถลงการณ์ของผู้จำหน่ายในวันเดียวกัน ไทม์ไลน์ของ proof-of-concept ตัวเลข 48 นาทีและ 5 นาที และคุณสมบัติการลองซ้ำ เป็นงานวิจัยของ Anthropic เมื่อวันที่ 27 ตุลาคม ซึ่งไม่เปิดเผย exploit รีโพซิทอรีแล็บเมื่อวันที่ 30 ตุลาคมถูกระบุว่าเป็นของบุคคลที่สามและไม่ใช่ของเรา