CVE-2026-98432: ช่องโหว่ Linux Kernel ที่ทีม IT โรงพยาบาลควรเช็ก

ถ้าโรงพยาบาลมี Linux รับการเชื่อมต่อจากอินเทอร์เน็ต ให้เริ่มตรวจ CVE-2026-98432 ที่เครื่องรับ IPv4 TCP โดยตรง แล้วตามให้ถึงรุ่นเคอร์เนลที่กำลังรันจริง เครื่องที่ติดตั้งแพ็กเกจใหม่แต่ยังบูตอยู่บนเคอร์เนลเดิมอาจยังไม่ได้รับการแก้ไข

บทความนี้สรุปผลกระทบ วิธีจัดลำดับเครื่อง และแนวทางแพตช์โดยให้บริการรักษาเดินต่อได้ ตรวจสอบข้อมูลจากประกาศต้นทาง ณ 4 พฤศจิกายน 2569

ช่องโหว่นี้คืออะไร และหลักฐานบอกอะไร

Linux kernel ประมวลผลข้อมูลตัวเลือกในส่วนหัว IPv4 ระหว่างเริ่มการเชื่อมต่อ TCP หากงานสองส่วนทำงานทับจังหวะกัน ส่วนหนึ่งอาจคืนพื้นที่หน่วยความจำขณะที่อีกส่วนยังใช้อยู่ เรียกว่า use-after-free ผลที่เป็นไปได้คือเครื่องล่ม ข้อมูลในหน่วยความจำรั่ว หรือหน่วยความจำเสียหาย ภายใต้เงื่อนไขที่เหมาะสมอาจนำไปสู่การรันโค้ดจากระยะไกล บันทึกของ Linux CNA เผยแพร่เมื่อ 15 ตุลาคม 2569 และให้คะแนน CVSS 3.1 ที่ 9.8 (Critical) CVE Record จาก Linux CNA · Red Hat Security Bulletin

Anthropic รายงานว่าสาธิตการรันคำสั่งด้วยสิทธิ์ root จากระยะไกลได้ในสภาพทดสอบที่เป้าหมายเปิดรับ Multipath TCP (MPTCP) นี่คือผลการสาธิต เงื่อนไขของการโจมตีจริงขึ้นกับระบบและเส้นทางเครือข่าย ขณะที่ Red Hat ระบุว่าต้นเหตุอยู่ใน IPv4 TCP ปกติด้วย จึงใช้การปิด MPTCP เป็นเหตุผลปิดงานแพตช์ไม่ได้ รายงานการทดสอบจาก Anthropic · Red Hat Security Bulletin

เครื่องไหนควรเช็กก่อน

ให้เริ่มจากเครื่องที่ใช้เคอร์เนลหรือเฟิร์มแวร์ที่ได้รับผลกระทบ และเปิดรับการเชื่อมต่อ IPv4 TCP จากเครือข่ายที่ไม่น่าเชื่อถือ ช่องโหว่อยู่ช่วงเริ่มสร้างการเชื่อมต่อก่อนถึงหน้าล็อกอิน การเปิด MFA หรือใช้ HTTPS จึงไม่ได้เปลี่ยนสถานะแพตช์ของเคอร์เนลที่รับ TCP CVE Record จาก Linux CNA · AWS Security Bulletin

  • เครื่องที่เข้าถึงจากอินเทอร์เน็ต: เว็บโรงพยาบาล พอร์ทัลผู้ป่วย API gateway และระบบเชื่อมต่อกับคู่ค้า ตรวจทั้ง public IP, port forwarding และกฎ firewall
  • เครื่องหลัง load balancer: ดูว่าอุปกรณ์ตัวไหนรับและจบการเชื่อมต่อ TCP จากผู้ใช้จริง ถ้ามีทางเข้าถึงเครื่องต้นทางโดยตรง ให้ปิดทางเลี่ยง การอยู่หลัง load balancer อย่างเดียวบอกไม่ได้ว่าทราฟฟิกแบบนี้ไปถึงเคอร์เนลใด AWS Security Bulletin
  • ระบบภายใน: ตรวจเส้นทางจาก VLAN ผู้มาติดต่อ อุปกรณ์ที่จัดการไม่ได้ เครือข่ายคู่ค้า และระบบที่เข้าถึงผ่าน VPN ตามสิทธิ์จริง
  • อุปกรณ์เครือข่าย: สำหรับ MikroTik ช่องทางที่ประกาศระบุคือ TCP service บน RouterOS เอง เช่น หน้าจัดการที่เปิดรับจากเครือข่ายที่ไม่น่าเชื่อถือ การส่งทราฟฟิกผ่านเราเตอร์ไปยังเครื่องอื่นเป็นคนละกรณี ให้ตรวจทั้งตัวเราเตอร์และเครื่องปลายทางแยกกัน MikroTik Security Advisory

สถานะแพตช์ ณ 4 พฤศจิกายน 2569

โครงการ Linux ใส่การแก้ไขในสาย upstream แล้ว เช่น 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 และ 7.2.10 ตัวเลขนี้ใช้กับสาย upstream สำหรับเครื่องที่ใช้เคอร์เนลของดิสโทร ให้เทียบเลขแพ็กเกจเต็มกับประกาศผู้จำหน่าย เพราะผู้จำหน่ายอาจนำแพตช์ไปใส่ในรุ่นเดิม (backport) CVE Record จาก Linux CNA · Red Hat CVE และรายการ Errata

  • Debian: Tracker ระบุแพ็กเกจที่แก้แล้วสำหรับ Debian 13 (trixie) และ Debian 12 (bookworm) ให้เช็กแถวของแพ็กเกจที่เครื่องใช้ โดยเฉพาะเมื่อใช้เคอร์เนลคนละสายกับค่าเริ่มต้น Debian Security Tracker
  • Red Hat / OpenShift: มี Errata สำหรับ RHEL บางสายแล้ว ให้ตรวจตามผลิตภัณฑ์ รุ่นย่อย และสายอัปเดตที่ใช้งาน ส่วน OpenShift ให้ตามคำแนะนำและรุ่นอัปเดตของแพลตฟอร์ม Red Hat CVE และรายการ Errata · Red Hat Security Bulletin
  • Ubuntu: Tracker ที่ตรวจยังระบุแพ็กเกจ linux ของ 22.04, 24.04 และ 26.04 LTS ว่าอยู่ระหว่างดำเนินการ ให้ตรวจสถานะใหม่ตามชนิดเคอร์เนลของเครื่อง เช่น generic, HWE หรือ cloud kernel ก่อนเปลี่ยนแพ็กเกจบน production Ubuntu Security Tracker
  • AWS: มีแพตช์สำหรับ Amazon Linux 2 และ Amazon Linux 2023 แล้ว และมีอิมเมจ Amazon Linux 2023 สำหรับ EKS ที่แก้แล้วตั้งแต่ v20261031 วิธีอัปเดตต่างกันตามชนิดโหนดและบริการ ให้ใช้หัวข้อที่ตรงกับระบบจริง AWS Security Bulletin
  • MikroTik: RouterOS 7 แก้แล้วตั้งแต่ 7.25.1 (stable) และ 7.24.6 (long-term) ตามประกาศที่ตรวจ ส่วน RouterOS 6 ผู้ผลิตระบุว่าไม่ได้รับผลกระทบจาก CVE นี้ MikroTik Security Advisory

ถ้ายังแพตช์ไม่ได้ ให้ลดการเข้าถึงก่อน

จำกัดพอร์ต TCP ที่จำเป็นให้รับเฉพาะต้นทางที่อนุญาต ปิดทางเข้าเครื่องต้นทางที่ข้าม proxy และแยกเครือข่ายบริหารอุปกรณ์จากเครือข่ายผู้ใช้ สำหรับกฎกรองทราฟฟิกชั่วคราว Red Hat และ Ubuntu มีแนวทางกรอง IPv4 TCP ขาเข้าที่มี IPv4 options ซึ่งเป็นคนละส่วนกับ TCP options ให้ทดสอบกับระบบเชื่อมต่อโรงพยาบาลก่อนใช้ ตรวจว่ากฎครอบคลุมเส้นทางจริงรวมถึงเครือข่ายของคอนเทนเนอร์ที่แยกออกมา และตรวจว่ากฎยังอยู่หลังรีบูตหากยังรอแพตช์ มาตรการนี้ลดการสัมผัสช่องโหว่ระหว่างรออัปเดต Red Hat Security Bulletin · Ubuntu Security Tracker

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

แพตช์โดยให้บริการโรงพยาบาลเดินต่อ

  1. เก็บหลักฐานก่อนเปลี่ยน: จด OS และชนิดเคอร์เนลจาก cat /etc/os-release กับ uname -r ดูพอร์ตที่ฟังด้วย ss -lnt แล้วเทียบกับกฎเครือข่ายและประกาศผู้จำหน่าย คำสั่งดูพอร์ตแสดงสิ่งที่ฟังบนเครื่อง ยังต้องตรวจว่าเข้าถึงได้จากเครือข่ายใด
  2. เตรียมรอบอัปเดต: ตรวจระบบสำรองและขั้นตอนย้อนกลับ แจ้งหน่วยงานที่ใช้ระบบ และเริ่มจากเครื่องนำร่อง ในคลัสเตอร์ให้ย้ายงานตามแผนทีละโหนดโดยเช็กความจุและข้อจำกัดการหยุดของ workload ก่อน
  3. ทำให้แพตช์มีผล: ติดตั้งเคอร์เนลที่แก้แล้วและบูตเข้าเคอร์เนลนั้น หรือเปลี่ยนโหนดด้วยอิมเมจที่แก้แล้ว การอัปเดตคอนเทนเนอร์แอปเพียงอย่างเดียวไม่เปลี่ยนเคอร์เนล Linux ที่โหนดกำลังใช้ AWS Security Bulletin
  4. ตรวจหลังเปลี่ยน: ยืนยันเลขเคอร์เนลที่รันจริงหรือรุ่นเฟิร์มแวร์ เทียบกับ advisory และทดสอบงานสำคัญ เช่น ลงทะเบียน เปิดเวชระเบียน รับผลแล็บ สั่งยา และส่งข้อมูลกับระบบภายนอก ก่อนดำเนินการกับเครื่องถัดไป
  5. ปิดงานเป็นรายเครื่อง: บันทึกรุ่นที่แก้แล้ว เวลาอัปเดต ผลทดสอบ และเครื่องที่ยังรอแพตช์พร้อมเจ้าของงานกับวันทบทวน อย่าลืมอัปเดตอิมเมจต้นแบบและเครื่องสำรองที่จะเปิดใช้ในอนาคต

ตัวอย่าง: โรงพยาบาลติดตั้งแพ็กเกจเคอร์เนลใหม่บนเครื่องเว็บพอร์ทัลแล้ว แต่ uname -r ยังเป็นเคอร์เนลเดิมหลังติดตั้งแพ็กเกจ ให้ตรวจแผนรีบูตและเคอร์เนลที่ระบบเลือกบูต ก่อนรายงานว่าเครื่องนี้แก้แล้ว

แหล่งอ้างอิงและบทความที่เกี่ยวข้อง

อ่านต่อ: PHP2Shell และการตรวจแพตช์สำหรับโรงพยาบาล · BCP โรงพยาบาลเมื่อ HIS หยุดทำงาน