ความปลอดภัยและข้อมูลสุขภาพ

PHP2Shell: โรงพยาบาลต้องตรวจอะไร และแพตช์อย่างไรให้ครบ

เว็บไซต์โรงพยาบาล ระบบนัดหมาย หรือหน้าบริหารจัดการที่ใช้ PHP อาจมีความเสี่ยง แม้ผู้โจมตียังไม่ได้ล็อกอิน ข่าว PHP2Shell จึงเป็นเรื่องที่ทีม IT ควรตรวจทั้งแอปและซอฟต์แวร์ที่รันอยู่เบื้องหลัง

บทความนี้รวบรวมข้อมูลจากเจ้าของโครงการ PHP, Cloudflare, CERT-EU, NCSC-NL, Ubuntu และ Red Hat แล้วแปลงเป็นแนวทางสำรวจ แพตช์ และตรวจรับสำหรับโรงพยาบาล โดยแยกข้อเท็จจริงจากข่าวออกจากตัวอย่างการนำไปใช้งาน

สถานะข้อมูล: 23 ตุลาคม 2569 ประกาศและรายการผลิตภัณฑ์ยังอาจเปลี่ยนแปลง ให้ตรวจแหล่งต้นทางล่าสุดก่อนดำเนินงาน

PHP2Shell คืออะไร และข่าวยืนยันอะไรแล้วบ้าง

PHP2Shell เป็นชื่อที่ใช้เรียกช่องโหว่ PHP สองรายการ ได้แก่ CVE-2026-109618 และ CVE-2026-109619 ซึ่งอาจทำให้ผู้โจมตีรันโค้ดจากระยะไกลได้โดยไม่ต้องยืนยันตัวตน หรือ Unauthenticated Remote Code Execution — RCE

The PHP Foundation อธิบายว่าช่องโหว่เกี่ยวข้องกับการจัดการหน่วยความจำและข้อผิดพลาดในตัว PHP และยืนยันการออกแพตช์เมื่อวันที่ 21 ตุลาคม 2026 ส่วน CERT-EU ระบุคะแนน CVSS 4.0 เท่ากับ 9.2 ระดับ Critical สำหรับทั้งสองรายการ The PHP Foundation — ที่มาและการออกแพตช์ 21 ตุลาคม 2026 · CERT-EU — Security Advisory 2026-018: Critical Vulnerabilities in PHP

  • 20 ตุลาคม: โครงการ PHP แจ้งเตรียมออกแพตช์ หลังข้อมูลช่องโหว่เริ่มเผยแพร่ก่อนกำหนด
  • 21 ตุลาคม: PHP ออกรุ่นแก้ไขทั้งสี่สายที่ระบุในประกาศ และ Cloudflare รายงานว่าพบทราฟฟิกโจมตีลูกค้า
  • 23 ตุลาคม: บทความนี้ตรวจทานข้อมูลเพื่อสรุปสิ่งที่ทีม IT โรงพยาบาลควรนำไปดำเนินการ

Cloudflare รายงานทั้งการตรวจพบทิศทางโจมตีและความพยายามปรับรูปแบบทราฟฟิกเพื่อหลบการป้องกัน ข้อมูลนี้เป็นหลักฐานว่ามีกิจกรรมโจมตี ไม่ได้ยืนยันว่าทุกเป้าหมายถูกเจาะสำเร็จ Cloudflare — PHP2Shell: ทราฟฟิกโจมตีและการป้องกันด้วย WAF

สองช่องโหว่นี้ทำงานผิดพลาดตรงไหน

CVE-2026-109618 — RCE via OOM corruption: ระหว่างจัดการคำขอ หากเกิดภาวะหน่วยความจำไม่พอในจังหวะที่ข้อมูลภายในยังเตรียมไม่สมบูรณ์ กระบวนการเก็บกวาดหลังคำขออาจนำข้อมูลที่ไม่ถูกต้องไปใช้ และนำไปสู่การรันโค้ดได้ PHP Security Advisory — CVE-2026-109618: RCE via OOM corruption

CVE-2026-109619 — RCE via stale global state: สถานะภายในบางส่วนอาจยังอ้างถึงหน่วยความจำของคำขอก่อนหน้าที่ถูกคืนไปแล้ว เมื่อ worker เดิมรับคำขอถัดไปจึงอาจใช้สถานะค้างนั้น เกิด Use-after-free และอาจนำไปสู่ RCE ตามเงื่อนไขที่เกี่ยวข้อง PHP Security Advisory — CVE-2026-109619: RCE via stale global state

สิ่งที่ทีมดูแลต้องเข้าใจคือปัญหาอยู่ใน PHP Runtime ซึ่งเป็นตัวที่ประมวลผลแอป PHP บนเซิร์ฟเวอร์ การอัปเดต WordPress ธีม หรือปลั๊กอินเพียงอย่างเดียวจึงยังต้องตามด้วยการแก้ PHP ที่ใช้งานจริง

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

โรงพยาบาลต้องค้นให้ครบ มากกว่าเว็บไซต์ประชาสัมพันธ์

ประกาศ PHP ระบุให้ตรวจ PHP ที่รับคำขอเว็บ รวมถึง PHP-FPM, Apache mod_php, php-cgi, FrankenPHP และ LiteSpeed โดยพิจารณา mod_php ว่ามีความเสี่ยงสูงเป็นพิเศษ เพราะมีการสาธิตโจมตีก่อนโค้ดแอปเริ่มทำงาน PHP.net — Security advisory และรุ่นแก้ไข 21 ตุลาคม 2026

ขณะเดียวกัน NCSC-NL ชี้ว่าควรตรวจผลิตภัณฑ์ที่ฝัง PHP มาด้วย เช่น อุปกรณ์ หน้าจัดการ และซอฟต์แวร์ของผู้จำหน่าย ซึ่งผู้ดูแลอาจอัปเดต PHP เองไม่ได้ NCSC-NL — ข้อมูลปฏิบัติการและรายการผลิตภัณฑ์ที่เกี่ยวข้องกับ PHP2Shell

เมื่อนำมาประยุกต์กับโรงพยาบาล รายการสำรวจควรครอบคลุม:

  • เว็บไซต์หลัก บล็อก Intranet และเว็บเอกสารที่พัฒนาด้วย PHP
  • ระบบนัดหมาย พอร์ทัลผู้ป่วย เว็บรับส่งเอกสาร หรือระบบเสริมที่ต้องถามผู้พัฒนาให้ชัด
  • หน้าบริหารจัดการเครื่องมือ โฮสติ้ง และผลิตภัณฑ์สำเร็จรูปที่อาจมี PHP ภายใน
  • Container Image, VM และสำเนาระบบสำรองที่อาจถูกนำกลับมาเปิดใช้ภายหลัง

ตัวอย่างข้างต้นเป็นแนวทางสำรวจ ไม่ใช่การยืนยันว่าระบบ HIS ทุกยี่ห้อหรือผลิตภัณฑ์ในรายการมีช่องโหว่ ให้ตรวจจากส่วนประกอบ รุ่น การตั้งค่า และประกาศผู้จำหน่ายจริง

ใช้ PHP-FPM อยู่ก็ยังควรตรวจและแพตช์ เงื่อนไขโจมตีต่างจาก mod_php และการประเมินความรุนแรงอาจต่างกันตามผลิตภัณฑ์ Red Hat อธิบายข้อจำกัดของการโจมตีในสภาพแวดล้อมของตนไว้โดยเฉพาะ จึงต้องอ่านประกาศที่ตรงกับระบบที่ติดตั้ง Red Hat — RHSB-2026-013: ผลกระทบตามผลิตภัณฑ์และสภาพแวดล้อม

PHP รุ่นใดแก้แล้ว และทำไมดูเลขเวอร์ชันอย่างเดียวไม่พอ

PHP.net ระบุ รุ่นแรกที่แก้ไขในแต่ละสาย ดังนี้ ให้ใช้รุ่นที่แก้แล้วหรือรุ่นใหม่กว่าที่ผู้ดูแลต้นทางรับรองสำหรับสายที่เลือก:

  • PHP 8.2 → 8.2.35
  • PHP 8.3 → 8.3.36
  • PHP 8.4 → 8.4.27
  • PHP 8.5 → 8.5.12

สำหรับ PHP 8.1 และเก่ากว่า ต้องตรวจผู้ให้บริการ LTS หรือผู้จำหน่าย โครงการ PHP มี minimal source backport สำหรับ 7.4, 8.0 และ 8.1 ในเหตุการณ์นี้ แต่ไม่ได้หมายถึงกลับมาเปิดการสนับสนุนรุ่นเก่าตามปกติ PHP.net — Security advisory และรุ่นแก้ไข 21 ตุลาคม 2026

แพ็กเกจ Linux อาจใช้ Backport: ผู้จำหน่ายนำแพตช์กลับไปใส่ในแพ็กเกจเดิม โดยเลข PHP หลักไม่เปลี่ยนตามรุ่น upstream ตัวอย่างที่ Ubuntu ประกาศคือ PHP ของ Ubuntu 24.04 ได้รับการแก้ในแพ็กเกจ 8.3.6-0ubuntu0.24.04.13 จึงต้องตรวจเลขแพ็กเกจเต็มและประกาศผู้จำหน่าย Ubuntu — แพ็กเกจที่แก้ไขและการนำแพตช์ไปใช้งาน

อีกจุดที่ทีมมักตรวจไม่ครบคือ PHP บน Command Line อาจเป็นคนละชุดกับ PHP ที่เว็บเซิร์ฟเวอร์เรียกใช้ ควรยืนยัน Runtime, package build หรือ image digest ที่รับทราฟฟิกจริง รวมถึงทุก worker และทุก replica โดยใช้ข้อมูลภายในที่ควบคุมสิทธิ์ ไม่เปิดหน้ารายละเอียดระบบให้สาธารณะเข้าดู

มี WAF แล้วต้องอัปเดต PHP อีกหรือไม่

ยังต้องอัปเดตครับ Cloudflare ระบุชัดให้แพตช์ PHP แม้มี WAF ช่วยป้องกัน โดยมีทั้งกฎตรวจคำขอและการตรวจสัญญาณจากคำขอร่วมกับคำตอบกลับ เพื่อเพิ่มชั้นป้องกัน Cloudflare — PHP2Shell: ทราฟฟิกโจมตีและการป้องกันด้วย WAF

ทีมควรตรวจว่าระบบที่ต้องการป้องกันผ่าน WAF จริง กฎที่เกี่ยวข้องทำงานตามนโยบาย และมีเส้นทางเข้า origin โดยตรงหรือไม่ การเปิดใช้บริการ WAF เพียงอย่างเดียวไม่ใช่หลักฐานว่าทุกโดเมนหรือทุก endpoint อยู่ในขอบเขตคุ้มครอง

หากยังแพตช์ไม่ได้ CERT-EU แนะนำให้พิจารณาแยกแอปที่เปิดสู่อินเทอร์เน็ตออกจากเครือข่ายสาธารณะจนแก้ไขและตรวจสอบแล้ว สำหรับโรงพยาบาลต้องประเมินผลกระทบ แจ้งเจ้าของบริการ และเปิดวิธีทำงานสำรองตามความจำเป็น CERT-EU — Security Advisory 2026-018: Critical Vulnerabilities in PHP

PHP เผยแพร่มาตรการชั่วคราวที่มีข้อจำกัดตามเส้นทางโจมตี การตั้งค่าหน่วยความจำ ขนาดคำขอ และ session ต้องอ่านจากประกาศล่าสุดให้ตรงกับสภาพแวดล้อม การคัดลอกค่ามาใช้โดยไม่ประเมินอาจกระทบความพร้อมใช้งาน และมาตรการเหล่านี้ยังไม่แทนแพตช์ถาวร

แผนแพตช์สำหรับโรงพยาบาล: เร่งแก้ พร้อมตรวจว่าบริการยังเดินต่อ

แนวทางต่อไปนี้เป็นข้อเสนอสำหรับประสานทีม IT ผู้พัฒนา ผู้จำหน่าย และเจ้าของงานของโรงพยาบาล โดยให้ระบบที่เปิดรับจากอินเทอร์เน็ตและเข้าถึงข้อมูลสำคัญได้รับการจัดลำดับเร่งด่วน:

  1. ระบุขอบเขต: เจ้าของบริการ โดเมน เครื่องหรือ Container วิธีรัน PHP รุ่นแพ็กเกจ และเส้นทางรับทราฟฟิก
  2. เลือกแพตช์ที่ตรง: ใช้แพ็กเกจหรืออัปเดตผลิตภัณฑ์จากผู้จำหน่าย ตรวจส่วนขยาย PHP และความเข้ากันได้ของแอป
  3. เตรียมคืนบริการ: ตรวจสำรองและวิธีกู้คืน รวมถึงมาตรการควบคุมการเข้าถึงหากจำเป็นต้องย้อนกลับชั่วคราว เพื่อไม่เปิดรุ่นที่ยังมีช่องโหว่สู่ภายนอก
  4. ทดสอบงานสำคัญ: การลงชื่อเข้าใช้ อัปโหลดเอกสาร สร้างรายงาน และจุดเชื่อมต่อที่ระบบนั้นใช้งานจริง
  5. นำแพตช์ขึ้นใช้งาน: รีสตาร์ตบริการหรือเปลี่ยน worker ตามคำแนะนำผู้จำหน่าย หากใช้ Container ให้สร้างและนำ Image ที่แก้แล้วขึ้นใช้งานครบทุก replica
  6. ตรวจหลังเปลี่ยน: ยืนยัน Runtime ที่รับคำขอจริง ทดสอบเส้นทางงาน ตรวจข้อผิดพลาดและประสิทธิภาพ แล้วเก็บหลักฐานผู้รับรองผล

Ubuntu เน้นว่าหลังอัปเดตแพ็กเกจ แอปที่ใช้ PHP อาจยังต้องรีสตาร์ต ส่วน Red Hat ระบุให้ดูแล Container ที่สร้างจาก Base Image ที่ได้รับผลกระทบด้วย การดาวน์โหลดแพตช์หรือเปลี่ยนไฟล์จึงยังต้องตามด้วยการยืนยันว่ากระบวนการที่ทำงานอยู่ใช้ส่วนที่แก้แล้ว Ubuntu — แพ็กเกจที่แก้ไขและการนำแพตช์ไปใช้งาน · Red Hat — RHSB-2026-013: ผลกระทบตามผลิตภัณฑ์และสภาพแวดล้อม

งานที่กระทบการให้บริการควรเชื่อมกับ แผน BCP โรงพยาบาล เพื่อให้ทุกหน่วยงานรู้เวลาที่เปลี่ยนระบบ วิธีทำงานสำรอง และเกณฑ์กลับมาใช้งานตามปกติ

ถ้าพบร่องรอยผิดปกติ การลงแพตช์อย่างเดียวอาจยังไม่จบ

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

NIST SP 800-61 Rev. 3 วางการตอบสนองเหตุให้เชื่อมกับการบริหารความเสี่ยง ตั้งแต่เตรียมพร้อม ตรวจจับ ตอบสนอง และฟื้นตัว เมื่อนำมาประยุกต์กับกรณีนี้ โรงพยาบาลควรมีผู้รับผิดชอบประเมินเหตุและตัดสินใจตามหลักฐาน NIST SP 800-61 Rev. 3 — การตรวจจับ ตอบสนอง และฟื้นตัวจากเหตุไซเบอร์ (2025)

  • เก็บ Log จาก WAF, Proxy, เว็บเซิร์ฟเวอร์ PHP ระบบปฏิบัติการ และเครื่องมือเฝ้าระวัง พร้อมช่วงเวลาและเขตเวลา
  • ตรวจร่วมกันทั้งคำขอผิดปกติ worker crash การเปลี่ยนไฟล์ กระบวนการแปลก และการเชื่อมต่อออกที่ไม่สอดคล้องกับงาน
  • หากมีเหตุสงสัย ให้ทีมตอบสนองควบคุมขอบเขต เก็บหลักฐาน และประเมินระบบหรือข้อมูลที่อาจเกี่ยวข้องก่อนฟื้นกลับ
  • พิจารณาเปลี่ยนข้อมูลลับหรือสร้างระบบใหม่จากต้นฉบับที่เชื่อถือได้ตามผลสอบสวน และทดสอบก่อนนำกลับให้บริการ

รายการนี้เป็นแนวทางตรวจสอบทั่วไป ไม่ใช่ IOC เฉพาะที่ยืนยันการโจมตี PHP2Shell การพบข้อความ OOM, HTTP 500 หรือ WAF block เพียงรายการเดียว ยังต้องตรวจบริบทก่อนสรุปว่าถูกยึดระบบ อ่านต่อเรื่อง Audit Log และหลักฐานที่ตามเหตุการณ์ได้

Checklist ปิดงาน PHP2Shell ให้ครบ

  • สำรวจระบบ PHP และผลิตภัณฑ์ที่ฝัง PHP ครบ พร้อมเจ้าของระบบแล้วหรือยัง?
  • แยกระบบเปิดสู่อินเทอร์เน็ต เส้นทาง origin และระบบที่เข้าถึงข้อมูลสำคัญแล้วหรือยัง?
  • ตรวจประกาศทั้ง CVE-2026-109618 และ CVE-2026-109619 ของผู้จำหน่ายแล้วหรือยัง?
  • มีหลักฐานแพ็กเกจหรือ Image ที่แก้แล้ว และยืนยัน Runtime ทุก instance หรือยัง?
  • บริการหรือ worker ที่ต้องรีสตาร์ตถูกเปลี่ยนไปใช้ส่วนที่แก้แล้วครบหรือยัง?
  • ทดสอบงานสำคัญและการเชื่อมต่อหลังแพตช์ พร้อมผู้รับรองผลแล้วหรือยัง?
  • ตรวจเหตุผิดปกติและกำหนดผู้ติดตาม ไม่ได้ใช้ WAF block เป็นหลักฐานเดียวแล้วหรือยัง?
  • อัปเดต Image ต้นทาง แม่แบบระบบ และแผนกู้คืนเพื่อไม่ให้รุ่นที่มีช่องโหว่กลับมาเปิดใช้แล้วหรือยัง?

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

แหล่งอ้างอิงต่างประเทศ

แหล่งอ้างอิงข่าวและช่องโหว่เป็นประกาศจากเจ้าของโครงการ ผู้ให้บริการ หรือหน่วยงานความมั่นคงปลอดภัยโดยตรง ส่วน NIST ใช้อ้างกรอบตอบสนองเหตุทั่วไป ตัวอย่างการทำงานในโรงพยาบาลและ Checklist เป็นข้อเสนอของผู้เขียน ไม่ใช่การยืนยันว่ามีโรงพยาบาลใดถูกโจมตีจากช่องโหว่นี้

Published by

CK Doctor

บทความจาก CK Doctor ว่าด้วยระบบสารสนเทศโรงพยาบาล กระบวนการทำงาน การเชื่อมต่อข้อมูล และการดูแลระบบสำหรับทีม IT และบุคลากรโรงพยาบาล