ถ้าโรงพยาบาลมี Linux รับการเชื่อมต่อจากอินเทอร์เน็ต ให้เริ่มตรวจ CVE-2026-98432 ที่เครื่องรับ IPv4 TCP โดยตรง แล้วตามให้ถึงรุ่นเคอร์เนลที่กำลังรันจริง เครื่องที่ติดตั้งแพ็กเกจใหม่แต่ยังบูตอยู่บนเคอร์เนลเดิมอาจยังไม่ได้รับการแก้ไข
บทความนี้สรุปผลกระทบ วิธีจัดลำดับเครื่อง และแนวทางแพตช์โดยให้บริการรักษาเดินต่อได้ ตรวจสอบข้อมูลจากประกาศต้นทาง ณ 4 พฤศจิกายน 2569
- ช่องโหว่นี้คืออะไร และหลักฐานบอกอะไร
- เครื่องไหนควรเช็กก่อน
- สถานะแพตช์ ณ 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 หรือรีบูตผิดปกติ ให้เก็บเวลาเกิดเหตุ บันทึกเคอร์เนล และบันทึกจากอุปกรณ์เครือข่ายเพื่อสืบหาสาเหตุ อาการเดียวกันอาจเกิดจากปัญหาอื่นได้ หากมีหลักฐานบ่งชี้การบุกรุก ให้เข้าสู่แผนตอบสนองเหตุของโรงพยาบาลควบคู่กับงานแพตช์
แพตช์โดยให้บริการโรงพยาบาลเดินต่อ
- เก็บหลักฐานก่อนเปลี่ยน: จด OS และชนิดเคอร์เนลจาก
cat /etc/os-releaseกับuname -rดูพอร์ตที่ฟังด้วยss -lntแล้วเทียบกับกฎเครือข่ายและประกาศผู้จำหน่าย คำสั่งดูพอร์ตแสดงสิ่งที่ฟังบนเครื่อง ยังต้องตรวจว่าเข้าถึงได้จากเครือข่ายใด - เตรียมรอบอัปเดต: ตรวจระบบสำรองและขั้นตอนย้อนกลับ แจ้งหน่วยงานที่ใช้ระบบ และเริ่มจากเครื่องนำร่อง ในคลัสเตอร์ให้ย้ายงานตามแผนทีละโหนดโดยเช็กความจุและข้อจำกัดการหยุดของ workload ก่อน
- ทำให้แพตช์มีผล: ติดตั้งเคอร์เนลที่แก้แล้วและบูตเข้าเคอร์เนลนั้น หรือเปลี่ยนโหนดด้วยอิมเมจที่แก้แล้ว การอัปเดตคอนเทนเนอร์แอปเพียงอย่างเดียวไม่เปลี่ยนเคอร์เนล Linux ที่โหนดกำลังใช้ AWS Security Bulletin
- ตรวจหลังเปลี่ยน: ยืนยันเลขเคอร์เนลที่รันจริงหรือรุ่นเฟิร์มแวร์ เทียบกับ advisory และทดสอบงานสำคัญ เช่น ลงทะเบียน เปิดเวชระเบียน รับผลแล็บ สั่งยา และส่งข้อมูลกับระบบภายนอก ก่อนดำเนินการกับเครื่องถัดไป
- ปิดงานเป็นรายเครื่อง: บันทึกรุ่นที่แก้แล้ว เวลาอัปเดต ผลทดสอบ และเครื่องที่ยังรอแพตช์พร้อมเจ้าของงานกับวันทบทวน อย่าลืมอัปเดตอิมเมจต้นแบบและเครื่องสำรองที่จะเปิดใช้ในอนาคต
ตัวอย่าง: โรงพยาบาลติดตั้งแพ็กเกจเคอร์เนลใหม่บนเครื่องเว็บพอร์ทัลแล้ว แต่ uname -r ยังเป็นเคอร์เนลเดิมหลังติดตั้งแพ็กเกจ ให้ตรวจแผนรีบูตและเคอร์เนลที่ระบบเลือกบูต ก่อนรายงานว่าเครื่องนี้แก้แล้ว
แหล่งอ้างอิงและบทความที่เกี่ยวข้อง
- CVE Record จาก Linux CNA
- Red Hat Security Bulletin
- Red Hat CVE และรายการ Errata
- Ubuntu Security Tracker
- Debian Security Tracker
- AWS Security Bulletin
- MikroTik Security Advisory
- รายงานการทดสอบจาก Anthropic
อ่านต่อ: PHP2Shell และการตรวจแพตช์สำหรับโรงพยาบาล · BCP โรงพยาบาลเมื่อ HIS หยุดทำงาน
blog.ckdoctor.com