ช่องโหว่โดยสังเขป
CVE-2026-98432 เป็น race condition ในโค้ด IPv4 TCP handshake ของ Linux kernel ที่อาจก่อให้เกิด use-after-free โค้ดที่มีข้อบกพร่องนี้มีมาตั้งแต่ Linux 4.4 เมื่อการเชื่อมต่อใหม่เสร็จสมบูรณ์ เคอร์เนลจะถ่ายโอนตัวเลือก IP ที่เกี่ยวข้องกับคำขอที่ค้างอยู่ไปยังซ็อกเก็ตใหม่โดยไม่คัดลอก หากซ็อกเก็ตนั้นถูกทำลายในขณะที่ CPU อื่นยังคงใช้ตัวเลือกเหล่านั้นในการตอบสนองคำขอเชื่อมต่อที่ถูกส่งซ้ำ เคอร์เนลจะอ่านหน่วยความจำที่ถูกปล่อยไปแล้ว IPv6 ไม่ได้รับผลกระทบจาก race นี้ ทีม CVE ของเคอร์เนลเองให้คะแนนความรุนแรงของปัญหาไว้ที่ 9.8 บนเกณฑ์ CVSS โดยถือว่าความซับซ้อนของการโจมตีอยู่ในระดับต่ำ บางการแจกจ่ายให้คะแนนต่ำกว่าในช่วงแรกด้วยเหตุผลว่าการชนะ race นั้นทำได้ยาก แม้ Red Hat จะปรับให้ใกล้เคียงกับการประเมินที่สูงขึ้นในภายหลัง
แพตช์จาก upstream ถูกนำไปใช้ในต้นเดือนตุลาคม และถูกถ่ายทอดไปยัง branches ของ stable kernel ที่ยังได้รับการดูแล Debian, Oracle Linux (สำหรับ UEK kernels) และแพคเกจบางส่วนของ Amazon Linux และ SUSE ได้จัดส่งเคอร์เนลที่แก้ไขแล้ว ณ ต้นเดือนพฤศจิกายน 2026 รุ่นที่ได้รับการสนับสนุนของ Ubuntu (รวมถึง LTS และ cloud variants ล่าสุด) และ Red Hat Enterprise Linux 8, 9 และ 10 ยังคงระบุสถานะของปัญหาว่ายัง取เสี่ยงหรืออยู่ในระหว่างดำเนินการ โดยยังไม่มีแพคเกจที่แก้ไขแล้ว RHEL 7 ไม่ได้รับผลกระทบเพราะเคอร์เนลของมันไม่มีโค้ดที่มีช่องโหว่
การโจมตี remote root ที่สาธิตใช้ multipath TCP (MPTCP) listener เป็นจุดเข้าแรก โมเดลวิจัยที่ยังไม่ได้เปิดเผยของ Anthropic สร้างการโจมตีสองขั้นตอนที่รั่วไหล pointer ของเคอร์เนลเพื่อเอาชนะ KASLR จากนั้นใช้ use-after-free เดียวกันเพื่อเขียนทับ callback และรันคำสั่งในฐานะ root ทั้งรายงาน CVE และแพตช์ของเคอร์เนลไม่ได้กล่าวถึง MPTCP การเชื่อมโยงมาจากบทความของ Anthropic ข้อบกพร่องพื้นฐานมีอยู่ในขั้นตอนการตั้งค่าการเชื่อมต่อ IPv4 TCP ธรรมดา ดังนั้นบริการที่ไม่ใช้ MPTCP จึงไม่ปลอดภัยโดยอัตโนมัติ การกำหนดค่า MPTCP เพียงแค่ให้เส้นทางที่เชื่อถือได้สำหรับการโจมตี remote root แบบเต็มรูปแบบที่ถูกสาธิต
ผลกระทบในทางปฏิบัติคือโฮสต์ Linux ใดก็ตามที่ยอมรับการเชื่อมต่อ IPv4 TCP ยังคงถูกเปิดโปงจนกว่าเคอร์เนลจะได้รับการอัปเดต พื้นที่ผิวที่มีลำดับความสำคัญสูงสุดสำหรับการโจมตีที่ถูกพิสูจน์แล้วคือกระบวนการใดก็ตามที่เปิด MPTCP listener นั่นคือรายละเอียดที่ทำให้พฤติกรรมเริ่มต้นของ Go runtime รุ่นล่าสุดมีความเกี่ยวข้องในทันที
เหตุใดบริการ Go จึงเป็นพื้นที่เสี่ยงในทางปฏิบัติ
ตั้งแต่ Go 1.24 ไลบรารีมาตรฐานเปิดใช้งาน Multipath TCP โดยค่าเริ่มต้นสำหรับ listener บน Linux เมื่อใดก็ตามที่เคอร์เนลรองรับ การเปลี่ยนแปลงนี้มีผลเฉพาะฝั่งเซิร์ฟเวอร์เท่านั้น Dialer ยังคงใช้ TCP ธรรมดาเว้นแต่จะกำหนดค่าไว้เป็นอย่างอื่น ผลลัพธ์คือการเรียกแบบธรรมดาเช่น `net.Listen("tcp", …)` จะสร้าง MPTCP listening socket โดยไม่ต้องมีโค้ดที่เกี่ยวข้องกับ MPTCP ปรากฏในแอปพลิเคชัน Go HTTP server, gRPC service, reverse proxy และ listener แบบกำหนดเองที่สร้างด้วย Go 1.24 หรือใหม่กว่าส่วนใหญ่จึงเปิดเผยการกำหนดค่าที่ Anthropic’s model ใช้เพื่อให้ได้ remote root อย่างแม่นยำ
ค่าเริ่มต้นนี้ถูกควบคุมด้วยการตั้งค่า GODEBUG multipathtcp ซึ่งถูกตั้งค่าเป็น listeners-only ใน Go 1.24 ผู้ดูแลระบบสามารถแทนที่ได้สองวิธี การตั้งค่าตัวแปรสภาพแวดล้อม `GODEBUG=multipathtcp=0` จะปิด MPTCP สำหรับทั้ง listener และ dialer ขณะรันโปรแกรม การใส่ `godebug multipathtcp=0` ในไฟล์ `go.mod` ของโมดูลหลัก (หรือใช้คำสั่ง `//go:debug`) จะตั้งค่าพฤติกรรมเดียวกันขณะสร้างโปรแกรม การเรียก `SetMultipathTCP` โดยตรงบน `ListenConfig` หรือ `Dialer` จะแทนที่ค่าของ GODEBUG ดังนั้นตำแหน่งเหล่านั้นต้องถูกตรวจสอบแยกต่างหาก ทีมความปลอดภัยของ Go ระบุว่าการปิดใช้งานทีละโปรแกรมเป็นการบรรเทาที่เปราะบาง: MPTCP listener ที่หลงเหลือเพียงตัวเดียวก็เพียงพอที่จะนำเส้นทางการโจมตีที่ถูกสาธิตกลับมา และข้อบกพร่องในเคอร์เนลไม่ได้จำกัดอยู่ที่ MPTCP
การตรวจจับทำได้ตรงไปตรงมา คำสั่ง `ss -Mltnp` (หรือ `ss -lnMp`) จะแสดงรายการ MPTCP listeners พร้อมกับกระบวนการที่เป็นเจ้าของ บนบริการ Go ทั่วไป ผลลัพธ์จะแสดงทั้ง TCP listener ธรรมดาที่เครื่องมือเช่น `ss -tlnp` แสดง และซ็อกเก็ต MPTCP ที่สอดคล้องกัน หลังจากนำ `GODEBUG=multipathtcp=0` ไปใช้และรีสตาร์ทกระบวนการ รายการ MPTCP ควรหายไป ในระดับระบบ `sysctl net.mptcp.enabled=0` จะป้องกันการสร้าง MPTCP socket ใหม่ แม้ listener ที่มีอยู่จะยังคงอยู่จนกว่าจะรีสตาร์ทกระบวนการ ขั้นตอนเหล่านี้จะลบการกำหนดค่าที่ถูกพิสูจน์แล้วว่าเอารัดเอาเปรียบได้ แต่ไม่ได้แก้ไข use-after-free ในเคอร์เนล จึงยังคงเป็นมาตรการชั่วคราวจนกว่าจะติดตั้งเคอร์เนลที่ได้รับแพตช์และรีบูตโฮสต์
โค้ดโจมตียังเป็นความลับ แผนที่นั้นไม่ได้
Anthropic’s Frontier Red Team ได้เผยแพร่รายงานระดับสูงเกี่ยวกับการโจมตี remote root ที่ใช้ได้จริงสำหรับ CVE-2026-98432 แต่เก็บโค้ดโจมตี เวอร์ชันเคอร์เนลและการกำหนดค่าที่ใช้ในการทดสอบที่แน่นอน รวมถึง proof of concept ที่พร้อมใช้งานไว้เป็นความลับ สิ่งที่ปรากฏคือคำอธิบายที่ชัดเจนของเส้นทางที่ประสบความสำเร็จ: MPTCP listener เป็นจุดเข้า, การชนะ race ของ IPv4 TCP handshake ซ้ำ ๆ เพื่อรั่วไหล kernel pointer และเอาชนะ KASLR ตามด้วยการใช้ use-after-free เดียวกันเพื่อเขียนทับ callback pointer และรันคำสั่ง shell แบบอิสระในฐานะ root บทความระบุว่าการแพ้ race จะยกเลิกการพยายามเชื่อมต่อนั้น ๆ เท่านั้น ไม่ทำให้ระบบล่ม จึงอนุญาตให้ผู้โจมตีลองใหม่ได้ตลอด ในรันที่รายงานในห้องปฏิบัติการ การรั่วไหลของที่อยู่ใช้เวลาประมาณ 48 นาที และการรันคำสั่งใช้เวลาอีก 5 นาที
คำอธิบายนั้นเพียงพอที่จะเป็นแผนที่สำหรับผู้อื่นในการเริ่มทำงาน เมื่อไม่กี่ปีก่อน การเปลี่ยนรายงานดังกล่าวให้เป็น remote root exploit ที่เชื่อถือได้ต้องใช้ความเชี่ยวชาญด้านเคอร์เนลเฉพาะทางและการวนซ้ำด้วยมือที่ยาวนาน วันนี้ข้อความเดียวกันสามารถป้อนให้กับโมเดล open-weight ที่มีความสามารถ เช่น Qwen ที่รันบน GPU cluster ที่หาได้ง่าย โมเดลเหล่านี้ไม่ได้สร้าง exploit ที่เสร็จสมบูรณ์ในครั้งแรก แต่ช่วยลดต้นทุนของการสำรวจ การดีบั๊ก และการปรับปรุงได้อย่างมาก กลุ่มอิสระหลายกลุ่มสามารถรันการค้นหานั้นพร้อมกันได้ ลดอุปสรรคที่เคยจำกัดงานในระดับนี้ไว้กับนักวิจัยจำนวนน้อย
เอกสารสาธารณะที่มีจนถึงขณะนี้ยังคงจำกัด Research toolkit ได้แสดงความสามารถในการกระตุ้น race และรับ memory leak แต่ยังไม่มีรายงานว่าสามารถจำลองขั้นตอน KASLR bypass และ root payload แบบเต็มตามที่ Anthropic อธิบาย ไม่มีการรายงานการโจมตีในโลกจริง และปัญหาไม่ได้ปรากฏในแคตตาล็อก Known Exploited Vulnerabilities ของ CISA ความคาดหวังที่สมจริงจึงไม่ใช่การระบาดของ exploit สาธารณะทันที แต่เป็นช่วงเวลาที่สั้นลงอย่างมีนัยสำคัญระหว่างการเผยแพร่แผนที่และการปรากฏของเวอร์ชันที่ใช้งานได้อิสระ สำหรับผู้ปฏิบัติงานที่ยังคงเปิด MPTCP listeners ในบริการ Go ช่วงเวลานั้นคือระยะที่มาตรการบรรเทาชั่วคราวมีความสำคัญมากที่สุด
ความเป็นจริงของ Kubernetes และ Service Mesh
ช่องโหว่ตั้งอยู่ใน Linux kernel ที่รันบนโหนด มันถูกกระตุ้นระหว่าง IPv4 TCP handshake ก่อนที่แพ็กเก็ตใดจะถึงคอนเทนเนอร์, sidecar หรือแอปพลิเคชัน ดังนั้น container image, pod security context และการกำหนดค่า service mesh จึงไม่สามารถปิดช่องว่างนี้ได้ เคอร์เนลที่ได้รับแพตช์บนโหนด (ตามด้วยการรีบูต หรือ live patch จากผู้จำหน่ายถ้ามี) ยังคงเป็นวิธีแก้ไขที่แท้จริง จนกว่าเคอร์เนลนั้นจะถูกนำมาใช้ พ็อดทุกตัวที่ถูกจัดกำหนดการบนโหนดจะได้รับการเปิดโปงจากโฮสต์พื้นฐาน
คอมโพเนนต์ control-plane ของ Kubernetes, operator และ custom controller จำนวนมากถูกเขียนด้วย Go เมื่อไบนารีเหล่านั้นถูกสร้างด้วย Go 1.24 หรือใหม่กว่า พวกมันจะได้รับ MPTCP listener default เว้นแต่จะถูกปิดใช้งานอย่างชัดเจน Workload ที่เขียนด้วย Go รุ่นล่าสุดก็ทำงานในลักษณะเดียวกัน Envoy ซึ่งเป็น data-plane proxy ที่ใช้โดย service mesh ส่วนใหญ่ ไม่ได้เปิดใช้งาน MPTCP โดยค่าเริ่มต้น การรองรับของมันเป็นตัวเลือก listener ที่ต้องเปิดใช้งานในการกำหนดค่า ดังนั้น mesh เองจึงไม่ค่อยเป็นต้นตอของพื้นที่โจมตีที่ถูกสาธิต ในขณะที่บริการ Go ที่อยู่ด้านหลังหรือข้างเคียง mesh มักจะเป็น
Network policy, mutual TLS และ sidecar interception ทำงานหลังจากที่เคอร์เนลได้ยอมรับและประมวลผล TCP handshake แล้ว พวกมันไม่สามารถป้องกัน use-after-free ที่เกิดขึ้นภายใน handshake นั้น ผู้โจมตีที่สามารถเข้าถึงพอร์ตที่เปิดฟังบนโหนดสามารถพยายาม race ได้โดยไม่คำนึงว่าทราฟฟิกสุดท้ายจะถูกเข้ารหัสหรืออนุญาตโดย mesh หรือไม่ ผลกระทบเชิงปฏิบัติสำหรับทีมแพลตฟอร์มคือการควบคุมของ mesh ยังคงมีคุณค่าสำหรับภัยคุกคามอื่น ๆ อีกมาก แต่ไม่สามารถแทนที่การแพตช์เคอร์เนลของโหนดหรือขั้นตอนชั่วคราวในการลบ MPTCP listeners ออกจากคอมโพเนนต์ Go ในสภาพแวดล้อมที่ยังคงรันคลัสเตอร์ของตนเองบน Ubuntu หรือ RHEL ไทม์ไลน์ของเคอร์เนลบนโหนดยังคงเป็นความรับผิดชอบของผู้ปฏิบัติงาน
การดำเนินการชั่วคราวขณะรอเคอร์เนล
ขั้นตอนปฏิบัติแรกคือการสำรวจ บนแต่ละโหนดให้รัน `ss -Mltnp` (หรือ `ss -lnMp`) เพื่อแสดงรายการ MPTCP listener ทุกตัวและกระบวนการที่เป็นเจ้าของ ตรวจสอบกระบวนการเหล่านั้นกับไบนารี Go ที่รู้จัก สำหรับบริการ Go ที่สร้างด้วย 1.24 หรือใหม่กว่า ให้ยืนยันว่า MPTCP default ยังคงใช้งานอยู่หรือไม่โดยตรวจสอบสภาพแวดล้อมหรือไฟล์ `go.mod` ที่ใช้ขณะสร้าง ขั้นตอนนี้ช่วยแยกการกำหนดค่าที่ Anthropic สาธิตออกจาก TCP listener ธรรมดาที่ยังคงอยู่ภายใต้ use-after-free ที่กว้างกว่าเท่านั้น
ในกรณีที่บริการ Go สามารถรีสตาร์ทได้ ให้ปิดใช้งานค่าเริ่มต้น ตั้งค่า `GODEBUG=multipathtcp=0` ในสภาพแวดล้อมของกระบวนการ หรือเพิ่ม `godebug multipathtcp=0` ลงใน `go.mod` ของโมดูลหลักแล้วสร้างใหม่ หลังรีสตาร์ท ให้รันคำสั่ง `ss` อีกครั้งเพื่อยืนยันว่า MPTCP socket หายไปแล้ว บนโฮสต์ที่ไม่ใช้ MPTCP เลย ให้ใช้ `sysctl -w net.mptcp.enabled=0` เพื่อป้องกันการสร้าง MPTCP socket ใหม่ Listener ที่มีอยู่จะยังคงอยู่จนกว่าจะรีสตาร์ทกระบวนการ ดังนั้น sysctl เพียงอย่างเดียวจึงไม่เพียงพอ การเปลี่ยนแปลงเหล่านี้จะลบเส้นทาง root ที่ถูกสาธิตโดยไม่ต้องรอเคอร์เนลจากผู้จำหน่าย
การเสริมความแข็งแกร่งเพิ่มเติมสามารถลดโอกาสของการชนะ race ขณะที่เคอร์เนลที่ยังไม่ได้รับแพตช์ยังคงอยู่ การกรองแพ็กเก็ตขาเข้าที่มี IPv4 options (Record Route หรือ Timestamp) ที่ไฟร์วอลล์ของโฮสต์หรือที่ขอบเครือข่าย จะจำกัดเงื่อนไขหนึ่งที่ทีม CVE ของเคอร์เนลใช้ในการให้คะแนน การเฝ้าระวัง repeated failed handshakes หรือรายการล็อกเคอร์เนลที่ไม่คาดคิดสามารถให้สัญญาณล่วงหน้า แม้การโจมตีจะถูกออกแบบมาเพื่อหลีกเลี่ยงการทำให้ระบบล่ม ในกรณีที่ผู้จำหน่ายมี live patch สำหรับ CVE เฉพาะนี้ ให้นำไปใช้ การดำเนินการเหล่านี้ไม่มีขั้นตอนใดที่แก้ไข use-after-free เอง
ขั้นตอนทั้งหมดข้างต้นเป็นมาตรการชั่วคราว พวกมันลดขนาดหรือลบการกำหนดค่าที่ถูกพิสูจน์แล้วว่าสามารถให้ remote root และอาจทำให้ความพยายามโจมตีอื่น ๆ ยากขึ้น แต่พวกมันไม่ได้กำจัดข้อบกพร่องพื้นฐานในเคอร์เนล MPTCP listener ที่ถูกมองข้ามเพียงตัวเดียว, การเรียก `SetMultipathTCP(true)` โดยตรง หรือการปรับปรุงการโจมตีในอนาคตที่ไม่ต้องการ MPTCP อีกต่อไป สามารถเปิดการเปิดโปงใหม่ได้ วิธีแก้ไขที่ยั่งยืนเพียงอย่างเดียวคือเคอร์เนลที่ได้รับแพตช์ที่ติดตั้งและรันบนโหนด จนกว่า Ubuntu และ RHEL จะจัดส่งแพคเกจเหล่านั้น การสำรวจและการปิดใช้งานยังคงเป็นการควบคุมที่มีประสิทธิภาพสูงสุดที่ผู้ปฏิบัติงานมี
สิ่งนี้หมายถึงอะไรสำหรับทีมแพลตฟอร์ม
CVE-2026-98432 ให้ตัวอย่างที่ชัดเจนของความรับผิดชอบที่ยังคงเหลืออยู่เมื่อองค์กรรัน Kubernetes cluster ของตนเอง Service-mesh policy, network control และ container hardening สามารถจัดการภัยคุกคามในระดับแอปพลิเคชันได้หลายอย่าง แต่ยังคงปล่อยให้ไทม์ไลน์ของเคอร์เนลบนโหนดอยู่ในมือของผู้ปฏิบัติงาน Ubuntu และ RHEL ยังไม่ได้ปล่อยแพคเกจที่แก้ไขสำหรับปัญหานี้ ในขณะที่ Debian และการแจกจ่ายอื่น ๆ บางรายได้ทำไปแล้ว ทีมที่มีโหนดยังคงอยู่บนการแจกจ่ายแรกจึงเผชิญกับหน้าต่างการเปิดโปงที่ยาวนานกว่าทีมที่ใช้ base image หรือ managed platform ที่มี upstream fix แล้ว สำหรับธนาคาร, บริษัทประกันภัย และผู้ปฏิบัติงานที่มีการกำกับดูแลอื่น ๆ ที่มาตรฐานบน Ubuntu หรือ RHEL ด้วยเหตุผลด้าน compliance หรือการสนับสนุน หน้าต่างนั้นคือข้อเท็จจริงทางปฏิบัติมากกว่าความเสี่ยงเชิงนามธรรม
เหตุการณ์นี้ยังเน้นย้ำถึงผลกระทบสะสมของ silent defaults ใน runtime สมัยใหม่ การตัดสินใจของ Go ในการเปิด MPTCP บน listener ถูกทำขึ้นเพื่อเหตุผลด้านประสิทธิภาพและการป้องกันอนาคต และได้รับการบันทึกไว้ ในทางปฏิบัติกลับสร้างการกำหนดค่าที่ถูกนำไปใช้อย่างแพร่หลายซึ่งตรงกับเส้นทาง remote root ที่ถูกสาธิตโดยไม่ต้องมีคำขออย่างชัดเจนจากเจ้าของแอปพลิเคชัน Default ที่คล้ายกันมีอยู่ใน stack อื่น ๆ ทีมแพลตฟอร์มที่มองพฤติกรรมของภาษาและ runtime เป็นรายละเอียดการใช้งานภายในคอนเทนเนอร์อาจพลาดการเปิดโปงในระดับโฮสต์ที่ปรากฏให้เห็นก็ต่อเมื่อมีการเผยแพร่ช่องโหว่ของเคอร์เนล กระบวนการสำรวจที่รวมทั้งเวอร์ชันเคอร์เนลของโหนดและตัวเลือกซ็อกเก็ตที่มีผลของบริการที่รันยาวนานจะช่วยลดความประหลาดใจนี้
สุดท้าย การผสมผสานระหว่างแผนทางเทคนิคสาธารณะและโมเดล open-weight ที่มีให้ใช้อย่างแพร่หลายทำให้ช่วงเวลาที่การควบคุมชั่วคราวยังเพียงพอสั้นลง องค์กรที่ได้ย้ายการแพตช์เคอร์เนลของโหนดไปสู่ cadence ที่คาดการณ์ได้ หรือที่ใช้เคอร์เนลจากผู้จำหน่ายที่มีการตอบสนองด้านความปลอดภัยที่เร็วขึ้น จะสามารถดูดซับปัญหาในระดับนี้ได้ด้วยการรบกวนน้อยลง ผู้ที่ยังคงรอแพคเกจจาก Ubuntu หรือ RHEL ต้องมอง Go MPTCP default เป็นการควบคุมที่เร่งด่วนและย้อนกลับได้ในขณะที่กำลังเตรียมการอัปเดตเคอร์เนล บทเรียนที่กว้างขึ้นคือ Kubernetes แบบทั่วไปไม่ได้กำจัดความจำเป็นในการเป็นเจ้าของ lifecycle ของระบบปฏิบัติการโฮสต์ มันเพียงแค่ย้ายจุดที่ความเป็นเจ้าของนั้นปรากฏให้เห็น
สรุปและขั้นตอนต่อไป
ลำดับความสำคัญชัดเจน เคอร์เนลที่ได้รับแพตช์บนทุกโหนดคือมาตรการเดียวที่ปิด use-after-free ได้ จนกว่า Ubuntu และ RHEL จะจัดส่งแพคเกจเหล่านั้น การควบคุมชั่วคราวที่มีประสิทธิภาพสูงสุดคือการลบ MPTCP listeners ออกจากบริการ Go และกระบวนการอื่น ๆ ที่เปิดใช้ ขั้นตอนนี้จะกำจัดการกำหนดค่าที่โมเดลของ Anthropic ใช้เพื่อให้ได้ remote root มันไม่ได้แก้ไขข้อบกพร่องของเคอร์เนลและไม่ได้ป้องกันการปรับปรุงการโจมตีในอนาคตทุกกรณี แต่ช่วยลดพื้นที่ผิวที่ถูกพิสูจน์แล้วได้อย่างมีนัยสำคัญ
การตรวจสอบทันทีมีต้นทุนต่ำ บนแต่ละโหนด ให้แสดงรายการ MPTCP listeners ด้วย `ss -Mltnp` ระบุไบนารี Go 1.24 หรือใหม่กว่า และนำ `GODEBUG=multipathtcp=0` (หรือคำสั่ง godebug ที่เทียบเท่า) ไปใช้ตามด้วยการรีสตาร์ท ในกรณีที่ไม่ใช้ MPTCP ให้ตั้งค่า `net.mptcp.enabled=0` และยืนยันว่าไม่มี listener ที่เหลือ บันทึกเวอร์ชันเคอร์เนลปัจจุบันและสถานะ advisory ของการแจกจ่ายเพื่อให้สามารถนำแพคเกจที่มาถึงในภายหลังไปใช้ได้โดยไม่ต้องค้นหาเพิ่มเติม การดำเนินการเหล่านี้สามารถทำเสร็จภายในไม่กี่ชั่วโมงบนฟลีตส่วนใหญ่และช่วยซื้อเวลาในขณะที่เคอร์เนลจากผู้จำหน่ายกำลังถูกเตรียม
สำหรับทีมที่รัน workload Go บน Kubernetes เหตุการณ์นี้เป็นเครื่องเตือนใจว่า node-kernel currency ยังคงเป็นความรับผิดชอบของผู้ปฏิบัติงาน แม้หลังจากติดตั้ง service mesh แล้ว การควบคุมของ mesh ยังคงมีความสำคัญต่อภัยคุกคามอื่น ๆ อีกมาก แต่ไม่สามารถแทนที่การอัปเดตเคอร์เนลหรือการลบ MPTCP surface ที่ถูกสาธิตในระยะสั้น องค์กรที่มอง lifecycle ของระบบปฏิบัติการโฮสต์เป็นความกังวลระดับแรกของแพลตฟอร์มจะสามารถดูดซับปัญหาในระดับนี้ได้ด้วยการรบกวนน้อยลง ผู้ที่ยังคงมองว่าเป็น dependency ภายนอกจะยังคงค้นพบหลังการเผยแพร่ว่า หน้าต่างสำหรับการแก้ไขอย่างเงียบ ๆ ได้แคบลงไปแล้ว ขั้นตอนปฏิบัติถัดไปคือการรันการสำรวจวันนี้และนำแพคเกจเคอร์เนลของ Ubuntu และ RHEL ไปไว้ใน critical path ทันทีที่มันปรากฏ
เอกสารอ้างอิง
The Hacker News, “Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions”, 29 ตุลาคม 2026.
Anthropic Frontier Red Team research disclosure (อ้างอิงในรายงานหลายฉบับในช่วงเวลาเดียวกัน), 27 ตุลาคม 2026.
ประกาศจากทีมความปลอดภัยของ Go บน golang-announce / oss-security เกี่ยวกับ CVE-2026-98432 และ MPTCP defaults, 29 ตุลาคม 2026.
Linux kernel CVE record สำหรับ CVE-2026-98432 (kernel.org CNA).
Ubuntu CVE tracker และหน้า Red Hat CVE สำหรับ CVE-2026-98432 (สถานะ ณ ต้นเดือนพฤศจิกายน 2026).
Distribution advisories จาก Debian, Oracle Linux, Amazon Linux และ SUSE สำหรับแพคเกจที่แก้ไขแล้ว