เว็บไซต์รับคำสั่งซื้อยังเปิดได้ตามปกติ ไม่ได้แปลว่า PHP ที่อยู่เบื้องหลังได้รับแพตช์แล้ว สำหรับเจ้าของธุรกิจ คำตอบที่ต้องขอจากทีมไอทีจึงควรระบุให้ได้ว่าระบบใดใช้ PHP ใครดูแล และมีหลักฐานอะไรยืนยันว่าแก้ช่องโหว่แล้ว
เมื่อวันที่ 21 ตุลาคม 2569 ทีมความปลอดภัยของ PHP ออกแพตช์สำหรับช่องโหว่ร้ายแรง 2 รายการ คือ CVE-2026-109618 และ CVE-2026-109619 ซึ่งอาจเปิดทางให้ผู้โจมตีรันโค้ดจากระยะไกลโดยไม่ต้องเข้าสู่ระบบ (unauthenticated remote code execution, RCE) รุ่นแก้ไขจากโครงการ PHP ได้แก่ 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 ทีม PHP แนะนำให้อัปเดตทันทีตาม ประกาศความปลอดภัยวันที่ 21 ตุลาคม
บทความนี้ตรวจแหล่งข้อมูล ณ วันที่ 22 ตุลาคม 2569 และเสนอวิธีจัดงานแพตช์สำหรับธุรกิจ ตัวอย่างระบบและการแบ่งหน้าที่ต่อไปนี้เป็นสถานการณ์สมมติ ไม่ใช่รายงานเหตุโจมตีหรือผลดำเนินงานของลูกค้า Enersys
ระบบเว็บที่ใช้ PHP ควรเริ่มตรวจจากจุดใด
ประกาศของ PHP ให้ตรวจการติดตั้งที่รับคำขอเว็บ รวมถึง PHP-FPM, Apache ที่ใช้ mod_php, php-cgi, FrankenPHP และ LiteSpeed โดยระบุว่าความเสี่ยงสูงสุดอยู่ที่ mod_php ซึ่งทีมมีตัวอย่างพิสูจน์การโจมตีที่เกิดก่อนโค้ดแอปพลิเคชันเริ่มทำงาน ข้อมูลนี้เป็นเหตุผลให้เร่งตรวจและแพตช์ ไม่ใช่หลักฐานว่าทุกเว็บไซต์ถูกโจมตีแล้ว ขอบเขตที่ทีม PHP ระบุ
ชื่อ CMS หรือหน้าตาเว็บไซต์เพียงอย่างเดียวตอบไม่ได้ว่าระบบได้รับผลกระทบหรือแก้แล้วหรือยัง ให้ผู้ดูแลตรวจ runtime ที่รับงานจริง รวมถึงสำเนาในคอนเทนเนอร์ เครื่องสำรอง และระบบที่ผู้ให้บริการโฮสต์ดูแล การตรวจ PHP ที่เรียกจาก command line อย่างเดียวอาจไม่ตรงกับ PHP ที่เว็บเซิร์ฟเวอร์ใช้อยู่
CVE-2026-109618 เกี่ยวกับการจัดการภาวะหน่วยความจำไม่พอ ขณะที่ข้อมูลภายในของคำขอยังเตรียมไม่เสร็จ ส่วน CVE-2026-109619 เกี่ยวกับสถานะภายในที่ค้างอยู่หลังคืนหน่วยความจำแล้ว และอาจถูกคำขอถัดไปนำมาใช้ รายละเอียดและเงื่อนไขอยู่ใน ประกาศ OOM corruption และ ประกาศ stale global state
รุ่นแก้ไขต้องดูคู่กับแหล่งแพ็กเกจ
สำหรับรุ่นที่รับจากโครงการ PHP โดยตรง ให้ตรวจรุ่นแก้ไขตามสาขาที่ใช้อยู่ในตารางนี้ แล้วตรวจบันทึกการออกรุ่นล่าสุดอีกครั้งก่อนติดตั้ง
| สาขา PHP |
รุ่นที่ออกแก้ช่องโหว่เมื่อ 21 ตุลาคม 2569 |
| 8.5 |
8.5.12 |
| 8.4 |
8.4.27 |
| 8.3 |
8.3.36 |
| 8.2 |
8.2.35 |
หากรับ PHP ผ่าน Linux distribution หรือผู้ขายที่ดูแลระยะยาว รุ่นแพ็กเกจอาจใช้เลขเดิมพร้อมนำแพตช์ใหม่กลับมาใส่ หรือ backport จึงต้องขอประกาศของผู้ขายที่ระบุ CVE ทั้ง 2 รายการและเลขแพ็กเกจที่แก้แล้วมาเทียบกับของที่ติดตั้งจริง อย่าตัดสินจากเลขเวอร์ชันต้นทางเพียงอย่างเดียว ทีม PHP ระบุให้ตรวจแพ็กเกจกับผู้ขายไว้ใน แนวทางอัปเดต
สำหรับระบบโฮสต์ที่บริษัทไม่ได้ติดตั้ง PHP เอง ให้เปิดคำขอถึงผู้ให้บริการ ระบุชื่อบริการและ CVE ทั้ง 2 รายการ แล้วขอคำยืนยันแพตช์ ขอบเขตเครื่องที่เปลี่ยน และเวลาที่เริ่มใช้จริง คำตอบว่า “อัปเดตระบบแล้ว” ยังควรตามด้วยข้อมูลที่ตรวจย้อนกลับได้
เปลี่ยนข่าวช่องโหว่ให้เป็นรายการงานที่ปิดได้
ลองสมมติว่าบริษัทขายส่งมีพอร์ทัลรับคำสั่งซื้อที่ใช้ PHP 8.2 และส่งคำสั่งซื้อต่อไปยัง ERP ฝ่ายปฏิบัติการทราบว่าหน้าเว็บยังรับออเดอร์ได้ แต่ไม่รู้ว่าผู้ให้บริการโฮสต์ใช้แพ็กเกจใด เป้าหมายของงานรอบนี้คือแก้ PHP โดยรักษาความถูกต้องของคำสั่งซื้อ ตั้งแต่ลูกค้ากดยืนยันจนระบบปลายทางรับรายการ
ผู้รับผิดชอบไอทีควรรวบรวมชื่อบริการ ตำแหน่งที่รัน PHP พร้อมรุ่นและเลขแพ็กเกจ แหล่งอัปเดต วิธีเชื่อมต่อกับเว็บเซิร์ฟเวอร์ และผู้ดูแลแต่ละระบบไว้ในรายการเดียว ระบุด้วยว่าระบบใดเปิดรับจากอินเทอร์เน็ตและระบบใดขาดข้อมูล เพื่อให้ผู้จัดการกำหนดลำดับงานและติดตามส่วนที่ยังตอบไม่ได้
จากนั้นให้ผู้ดูแลโฮสต์หรือผู้ขายยืนยันแพตช์ ผู้พัฒนาแอปเตรียมระบบทดสอบที่ใกล้เคียงระบบจริง และเจ้าของกระบวนการขายกำหนดผลลัพธ์ที่ยอมรับได้ การแบ่งหน้าที่ควรจบด้วยหลักฐาน เช่น
| ผู้รับผิดชอบในตัวอย่าง |
หลักฐานที่ใช้ตัดสินใจ |
| ผู้ดูแลโฮสต์หรือโครงสร้างพื้นฐาน |
ประกาศผู้ขายที่ครอบคลุม CVE ทั้งคู่ และเลขแพ็กเกจหรือ image ที่จะติดตั้ง |
| ผู้พัฒนาและผู้ทดสอบแอป |
ผลทดสอบการเข้าสู่ระบบ การส่งคำสั่งซื้อ การอัปโหลดเอกสาร และการส่งต่อไป ERP |
| เจ้าของกระบวนการขาย |
ยืนยันยอด รายการสินค้า และสถานะคำสั่งซื้อที่ปลายทางตรงกับข้อมูลทดสอบ |
| ผู้อนุมัติการเปลี่ยนระบบ |
ช่วงเวลาติดตั้ง เกณฑ์หยุดหรือย้อนกลับ และผู้ติดตามหลังเปลี่ยน |
รายการทดสอบข้างต้นเป็นข้อเสนอสำหรับพอร์ทัลสมมตินี้ แต่ละบริษัทควรเลือกงานตามระบบจริง รวมถึงงานตามเวลาและตัวเชื่อมต่อที่ไม่ปรากฏบนหน้าเว็บ การทดสอบธุรกิจผ่านช่วยตรวจผลข้างเคียงของการเปลี่ยนรุ่น ไม่ได้พิสูจน์ว่าระบบปลอดจากช่องโหว่ทั้งหมด
ทดสอบแพตช์และเตรียมทางกลับก่อนเปลี่ยนระบบจริง
ให้ติดตั้งแพตช์ในระบบทดสอบด้วยช่องทางเดียวกับที่จะใช้จริง ตรวจ extensions และค่าตั้งที่แอปต้องใช้ แล้วส่งคำสั่งซื้อทดสอบที่ไม่มีข้อมูลอ่อนไหว ตรวจให้ถึงปลายทางว่ารายการไม่หาย ไม่ซ้ำ และเมื่อส่งไม่สำเร็จ ระบบแจ้งหรือจัดการตามที่ออกแบบไว้
ก่อนเปลี่ยนระบบจริง ให้ยืนยันสำเนาสำรองและวิธีกู้คืนที่ใช้ได้ กำหนดเกณฑ์หยุด เช่น งานรับคำสั่งซื้อผิดพลาดหรือข้อมูลส่งต่อไม่ตรง พร้อมระบุคนตัดสินใจ หากต้องย้อนกลับไปใช้ PHP ที่ยังไม่แก้ช่องโหว่ ความเสี่ยงเดิมจะกลับมาด้วย จึงต้องกำหนดการจำกัดบริการที่เกี่ยวข้องและแผนแก้ต่อให้ชัดเจน
หลังติดตั้ง ผู้ดูแลต้องตรวจว่า worker และคอนเทนเนอร์ที่รับงานใช้แพ็กเกจใหม่จริงตามวิธีของระบบนั้น การวางไฟล์รุ่นใหม่ไว้บนดิสก์ยังไม่ยืนยันว่า process เดิมเลิกใช้งานแล้ว เก็บหลักฐานรุ่นที่รัน ผลตรวจบริการ และผลทดสอบคำสั่งซื้อหลังเปลี่ยนไว้ในรายการงานเดียวกัน
สำหรับการเฝ้าดูหลังเปลี่ยน ให้เลือกสัญญาณที่เชื่อมกับงาน เช่น อัตราข้อผิดพลาดเว็บ งานส่งข้อมูลค้าง หรือคำสั่งซื้อที่สถานะไม่ตรงกับ ERP พร้อมกำหนดผู้ติดตามและช่วงเวลาตรวจ ระบบที่ยังรอผู้ขายต้องมีเจ้าของงานและกำหนดติดตามครั้งถัดไป
ถ้ายังแพตช์ไม่ได้ ควรตัดสินใจอย่างไร
ทีม PHP ระบุชัดว่ามาตรการชั่วคราวลดความเสี่ยงได้เฉพาะบางเส้นทาง และมีเพียงการอัปเดตที่แก้ปัญหาได้ครบตามประกาศ ผู้ดูแลควรอ่าน ข้อจำกัดของมาตรการแต่ละข้อ ก่อนปรับค่าตั้ง ไม่ควรนำชุดคำสั่งจากบทความทั่วไปไปใช้กับทุกระบบ
ระหว่างรอแพตช์ ให้ผู้รับผิดชอบประเมินการจำกัดการเข้าถึงหรือหยุดบริการที่เกี่ยวข้องตามผลกระทบต่อธุรกิจ บันทึกสิ่งที่ทำ ขอบเขตที่ยังเหลือ ผู้ยอมรับความเสี่ยง และเวลาทบทวน การเปิด WAF หรือซ่อนข้อความผิดพลาดไม่ควรถูกใช้เป็นหลักฐานว่าติดตั้งแพตช์ PHP แล้ว
PHP 8.2 ยังต้องวางแผนย้ายรุ่น
PHP 8.2.35 แก้ช่องโหว่รอบนี้ แต่ไม่ได้ต่ออายุการสนับสนุนของสาขา PHP 8.2 ซึ่งสิ้นสุดการสนับสนุนด้านความปลอดภัยจากโครงการ PHP ในวันที่ 31 ธันวาคม 2569 ตาม ตารางรุ่นที่ยังได้รับการสนับสนุน จึงควรแยกงานแพตช์เร่งด่วนออกจากโครงการย้ายไปสาขาที่รองรับต่อ
สำหรับ PHP 8.1 และเก่ากว่า ต้องตรวจสิทธิ์และขอบเขตการดูแลจากผู้ขายเป็นรายกรณี อย่าถือว่าการมีแพตช์ย้อนกลับบางรายการทำให้กลับมาได้รับการสนับสนุนตามปกติจากโครงการ PHP วางวันทดสอบความเข้ากันได้ ผู้รับผิดชอบ และวันย้ายรุ่นให้เห็นเป็นงานที่ติดตามได้
คำถามที่ผู้จัดการควรถามก่อนปิดงาน
ต้องอัปเดต PHP เป็นรุ่นใด
รุ่นแก้ไขที่โครงการ PHP ออกเมื่อ 21 ตุลาคม 2569 คือ 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 สำหรับแพ็กเกจจาก distribution หรือผู้ขาย ให้ใช้ประกาศของผู้ขายยืนยัน CVE ทั้ง 2 รายการและเลขแพ็กเกจที่ติดตั้ง
หน้าเว็บยังใช้งานได้ แปลว่าแก้แล้วหรือไม่
ยังยืนยันไม่ได้ ต้องมีหลักฐาน runtime และแพตช์ที่ใช้งานจริง พร้อมผลทดสอบงานสำคัญหลังเปลี่ยนรุ่น การเปิดหน้าเว็บสำเร็จเป็นเพียงหนึ่งรายการตรวจบริการ
ข้อมูลอะไรควรอยู่ในรายงานปิดงาน
ชื่อบริการและผู้ดูแล หลักฐานแพตช์สำหรับ CVE ทั้งคู่ รุ่นที่รันจริง ผลทดสอบงานธุรกิจ แผนกู้คืน และรายการที่ยังค้างพร้อมวันติดตาม คือข้อมูลที่ช่วยให้ผู้อนุมัติตรวจได้ว่าระบบใดแก้แล้วและระบบใดยังต้องจัดการ
อ่านต่อ
ภาพประกอบสร้างด้วย AI สำหรับบทความนี้ ไม่ใช่ภาพเหตุโจมตีจริง
