เนื่องจากช่องโหว่ PHP2Shell เกิดขึ้นใน PHP ซึ่งเป็นองค์ประกอบพื้นฐานที่ใช้ประมวลผลเว็บไซต์และระบบสารสนเทศอย่างแพร่หลาย จึงอาจส่งผลกระทบต่อระบบหลายประเภท และเปิดโอกาสให้ผู้โจมตีสั่งรันโค้ดจากระยะไกลโดยไม่ต้องยืนยันตัวตน ทั้งนี้ ความสำเร็จของการโจมตีขึ้นอยู่กับรูปแบบการติดตั้ง การตั้งค่า และเงื่อนไขของแต่ละระบบ
เพื่อสนับสนุนให้หน่วยงานสามารถตรวจสอบและแก้ไขได้อย่างครอบคลุม ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่งชาติ (ThaiCERT) จึงได้รวบรวมแนวทางตรวจสอบและอัปเดต PHP สำหรับระบบแต่ละประเภท โดยขอให้หน่วยงานสำรวจทั้งเว็บไซต์ ระบบภายในองค์กร และระบบที่ผู้ให้บริการภายนอกดูแล โดยเฉพาะ PHP ที่ติดตั้งแยกหลายเวอร์ชัน หรือเป็นองค์ประกอบภายในซอฟต์แวร์และอุปกรณ์หลายรุ่น ซึ่งการอัปเดตตัวแอปพลิเคชัน เครื่องโฮสต์ หรือระบบบริหารจัดการเพียงอย่างเดียว อาจไม่ครอบคลุม PHP ที่เป็นส่วนประกอบของแพลตฟอร์มที่ใช้งานอยู่ หน่วยงานจึงควรตรวจสอบ PHP ที่แต่ละบริการเรียกใช้จริง และยืนยันผลหลังอัปเดตให้ครบทุกระบบ ตามแนวทางต่อไปนี้ [1][2][3]
1. สิ่งที่หน่วยงานควรดำเนินการทันที
1.1 สำรวจการใช้งาน PHP
ตรวจสอบว่าแต่ละเว็บไซต์และบริการใช้ PHP ชุดใด รวมถึงระบบภายในและระบบที่ผู้ให้บริการภายนอกดูแล
1.2 เตรียมการและดำเนินการอัปเดต
สำรองข้อมูล ทดสอบความเข้ากันได้ และอัปเดต PHP ผ่านช่องทางที่ผู้ผลิตหรือผู้ดูแลแพ็กเกจรองรับ
1.3 เริ่มบริการใหม่และยืนยันผล
เริ่มกระบวนการให้บริการใหม่ และยืนยันว่าทุกเครื่องใช้ PHP ที่ได้รับการแก้ไขแล้ว
1.4 เก็บหลักฐานและปรับปรุงระบบสำรอง
บันทึกผลการแก้ไข และตรวจแพตช์ก่อนนำระบบสำรองหรืออิมเมจเก่ากลับมาให้บริการ
การอัปเดตเว็บไซต์ แอปพลิเคชัน เครื่องโฮสต์ หรือ Control Panel เพียงอย่างเดียว ไม่ได้ยืนยันว่า PHP ทุกชุดได้รับการแก้ไขแล้ว
2. สำรวจการใช้งาน PHP ให้ครอบคลุม 8 กลุ่มระบบ
รายการต่อไปนี้ใช้เป็นแนวทางสำรวจ โดยแต่ละระบบอาจอยู่ในหลายกลุ่ม และ ไม่ได้หมายความว่าทุกผลิตภัณฑ์ได้รับผลกระทบ ต้องตรวจสอบเวอร์ชัน สถานะแพตช์ และประกาศของผู้ผลิตประกอบ
เว็บไซต์ เว็บแอปพลิเคชัน และระบบภายในองค์กร
ตรวจสอบเว็บไซต์สาธารณะ ระบบ CMS, Intranet, HR, ERP, CRM, Helpdesk ระบบจัดซื้อ และพอร์ทัลพนักงานที่ใช้งาน PHP แม้ไม่ได้เปิดสู่อินเทอร์เน็ต โดยระบุ PHP ที่แต่ละบริการเรียกใช้ ตำแหน่งติดตั้ง และไฟล์ตั้งค่าให้ชัดเจน
หากให้บริการหลายเครื่อง ต้องตรวจสอบและอัปเดตให้ครบทุกเครื่อง
ระบบหลังบ้านแอปมือถือและ API
ตรวจสอบเซิร์ฟเวอร์ API และบริการหลังบ้านที่ประมวลผลด้วย PHP การอัปเดตแอปบนโทรศัพท์ไม่ได้ยืนยันว่า PHP ฝั่งเซิร์ฟเวอร์ได้รับการแก้ไขแล้ว
หากมีหลายเครื่องอยู่หลัง Load Balancer หรือมีหลายชุดให้บริการ ต้องอัปเดตและยืนยันผลให้ครบทุกชุด
ระบบบริหารจัดการและ Hosting Control Panel
ตรวจสอบทั้ง PHP ที่ตัวระบบบริหารจัดการใช้ หากมี และ PHP ที่กำหนดให้แต่ละเว็บไซต์ ซึ่งอาจเป็นคนละชุดกัน
สำหรับ cPanel ให้ตรวจสอบ PHP รายโดเมนผ่าน MultiPHP Manager และติดตั้งหรืออัปเดตแพ็กเกจผ่าน EasyApache 4 ระบบจัดการแพ็กเกจ หรือช่องทางของผู้จำหน่ายตามประเภทแพ็กเกจ ส่วน Plesk ให้ตรวจสอบเวอร์ชันและ PHP Handler ของแต่ละเว็บไซต์ผ่าน PHP Settings [4][5]
การเปลี่ยน PHP ค่าเริ่มต้นของเครื่องอาจไม่เปลี่ยน PHP ของเว็บไซต์เดิมทุกแห่ง จึงต้องตรวจสอบรายเว็บไซต์และทุกเวอร์ชันที่ยังใช้งาน
ซอฟต์แวร์หรืออุปกรณ์สำเร็จรูปจากผู้ขาย
ตรวจสอบผลิตภัณฑ์ที่มีหน้าเว็บบริหารจัดการหรืออาจมี PHP เป็นส่วนประกอบ โดยแจ้งชื่อผลิตภัณฑ์ รุ่น และเวอร์ชันให้ผู้ผลิตยืนยันผลกระทบ พร้อมขอแพตช์หรือเฟิร์มแวร์ที่เกี่ยวข้อง
ใช้วิธีอัปเดตที่ผู้ผลิตรองรับ ไม่ควรนำ PHP รุ่นใหม่ไปแทนที่ไฟล์ภายในผลิตภัณฑ์เองโดยไม่มีคำแนะนำจากผู้ผลิต
Container และ Docker Image
ตรวจสอบ PHP ภายในคอนเทนเนอร์ที่กำลังทำงาน และอิมเมจที่เตรียมไว้สำหรับนำกลับมาใช้งาน จากนั้นปรับปรุง Base Image หรือแพ็กเกจ สร้างอิมเมจใหม่ ทดสอบ และนำคอนเทนเนอร์จากอิมเมจที่แก้ไขแล้วขึ้นให้บริการ [6]
การอัปเดตเครื่องโฮสต์หรือดาวน์โหลดอิมเมจใหม่เพียงอย่างเดียวยังไม่ครอบคลุมคอนเทนเนอร์เดิม หากกำหนด Image Digest ไว้ ต้องปรับให้ชี้ไปยังอิมเมจที่แก้ไขแล้วด้วย
เครื่อง Windows ที่ติดตั้ง PHP หรือมี PHP มากับซอฟต์แวร์
ตรวจสอบไฟล์ เช่น php.exe, php-cgi.exe และโมดูล PHP ที่เว็บเซิร์ฟเวอร์โหลด พร้อมระบุตำแหน่งติดตั้ง เวอร์ชัน และบริการที่เรียกใช้ รวมถึงตำแหน่งที่อยู่นอกเส้นทางติดตั้งมาตรฐาน
การพบไฟล์ PHP เพียงอย่างเดียวยังไม่ยืนยันว่าถูกใช้ให้บริการเว็บ หากเป็นส่วนประกอบของซอฟต์แวร์สำเร็จรูป ให้ใช้แพ็กเกจอัปเดตจากผู้ผลิต
ระบบทดสอบ ระบบเก่า และระบบสำรอง
ตรวจสอบ Development, UAT, Staging และ DR รวมถึงเครื่องเสมือน อิมเมจต้นแบบ และชุดติดตั้งที่เตรียมนำกลับมาใช้ ให้ปรับปรุงชุดที่พร้อมเปิดบริการและกำหนดขั้นตอนตรวจแพตช์ก่อนนำระบบเก่ากลับมาใช้งาน
หากกู้คืนจากข้อมูลสำรองหรือ Snapshot เก่า ให้ ตรวจสอบและแก้ไข PHP ในเครือข่ายที่แยกไว้ ก่อนเชื่อมต่อกลับเข้าเครือข่ายให้บริการ
ระบบที่ผู้ให้บริการภายนอกดูแล
ประสานผู้ให้บริการ Shared Hosting, Managed Hosting และผู้รับจ้างดูแลระบบ เพื่อขอผลตรวจสอบ PHP ที่แต่ละเว็บไซต์หรือบริการใช้จริง
หลักฐานควรระบุชื่อระบบ เวอร์ชันหรือหมายเลขแพ็กเกจ หมายเลข CVE ที่แก้ไข วันที่ดำเนินการ ผลตรวจสอบหลังอัปเดต และเอกสารของผู้จำหน่ายที่เกี่ยวข้อง
คำยืนยันว่า “อัปเดตเว็บไซต์แล้ว” เพียงอย่างเดียวยังไม่เพียงพอ
3. ขั้นตอนตรวจสอบและอัปเดต PHP
ตรวจสอบ PHP ให้ตรงกับบริการจริง
ใช้ php -v ตรวจสอบเวอร์ชัน และ php –ini ตรวจสอบไฟล์ตั้งค่าได้ แต่ผลเป็นของ PHP ที่คำสั่งนั้นเรียกใช้ ซึ่ง อาจต่างจาก PHP ของเว็บไซต์หรือ PHP-FPM จึงต้องตรวจสอบการตั้งค่าเว็บเซิร์ฟเวอร์ บริการ และ Control Panel ประกอบ [7][8]
หากจำเป็นต้องสร้างหน้าตรวจสอบข้อมูล PHP ผ่านเว็บ ให้แสดงข้อมูลเท่าที่จำเป็น จำกัดการเข้าถึงเฉพาะผู้ดูแล และลบออกหลังตรวจสอบ เลือกรุ่นหรือแพ็กเกจที่มีแพตช์ครอบคลุมทั้งสอง CVE
รุ่น PHP ที่แก้ไข CVE-2026-109618 และ CVE-2026-109619 ได้แก่ 8.2.35, 8.3.36, 8.4.27 และ 8.5.12 หรือรุ่นใหม่กว่าที่มีแพตช์และยังได้รับการสนับสนุน [1]
หากใช้แพ็กเกจจากผู้จำหน่ายระบบปฏิบัติการหรือผู้ให้บริการสนับสนุนระยะยาว ให้ตรวจสอบประกาศและหมายเลขแพ็กเกจ เพราะอาจมีการนำแพตช์กลับมาใช้โดยหมายเลขเวอร์ชัน PHP หลักไม่เปลี่ยน
สำหรับ PHP 8.1 หรือต่ำกว่า ให้ตรวจสอบกับผู้จำหน่ายว่ามีแพตช์ครอบคลุมหรือไม่ และวางแผนย้ายไปยังรุ่นที่ยังได้รับการสนับสนุน ไม่ควรถือว่ารุ่นเก่าปลอดภัยเพียงเพราะไม่มีรายการอัปเดต [1] สำรองข้อมูลทดสอบและข้อมูลอัปเดต
สำรองฐานข้อมูล ไฟล์แอปพลิเคชัน และไฟล์ตั้งค่า พร้อมเตรียมแผนกู้คืน ทดสอบฟังก์ชันสำคัญและส่วนขยาย โดยเฉพาะเมื่อย้ายข้ามสายเวอร์ชัน แล้วอัปเดตผ่านช่องทางที่ผู้ผลิตหรือผู้ดูแลแพ็กเกจรองรับ เริ่มบริการใหม่และยืนยันผลอัปเดตของ PHP
เริ่มบริการ PHP หรือเว็บเซิร์ฟเวอร์ที่เกี่ยวข้องใหม่ตามรูปแบบการติดตั้ง โดยตรวจให้แน่ใจว่ากระบวนการเดิมถูกแทนที่ทั้งหมด สำหรับคอนเทนเนอร์ ให้นำชุดจากอิมเมจที่แก้ไขแล้วขึ้นให้บริการ
ตรวจยืนยันผ่านบริการจริงให้ครบทุกเว็บไซต์ ทุกเครื่อง และทุกคอนเทนเนอร์ พร้อมทดสอบการเข้าสู่ระบบ การเชื่อมต่อฐานข้อมูล และฟังก์ชันสำคัญ เก็บหลักฐานสถานะแพตช์ วันที่ดำเนินการ และผู้รับผิดชอบไว้ตรวจสอบย้อนหลัง
หากพบสัญญาณผิดปกติ ให้ตรวจสอบร่องรอยการบุกรุกเพิ่มเติม เพราะการอัปเดตไม่ได้ลบมัลแวร์หรือช่องทางเข้าถึงที่ผู้โจมตีอาจติดตั้งไว้ก่อนหน้า
4. มาตรการชั่วคราวเมื่อยังไม่สามารถอัปเดตได้
มาตรการต่อไปนี้ลดความเสี่ยงเฉพาะบางเส้นทาง และไม่ทดแทนการติดตั้งแพตช์ ให้ผู้ดูแลประเมินผลกระทบ ทดสอบ และกำหนดกรอบเวลาแก้ไขให้ชัดเจน
จำกัดการเข้าถึงระบบ
จำกัดการเข้าถึงเฉพาะผู้ใช้และเครือข่ายที่จำเป็น ปิดบริการที่ไม่ได้ใช้งาน และประสานผู้ดูแลหรือผู้ผลิตเพื่อกำหนดกรอบเวลาการแก้ไข พร้อมพิจารณามาตรการตั้งค่า PHP ตามประกาศทางการ โดยทดสอบผลกระทบก่อนใช้งาน มาตรการสำหรับ CVE-2026-109618
การกำหนด memory_limit=-1 ในระดับผู้ดูแลช่วยลดเส้นทางโจมตีที่อาศัยขีดจำกัดหน่วยความจำของ PHP โดยต้องตรวจสอบว่าไม่มีการตั้งค่าใน Pool, Directory หรือแอปพลิเคชันเปลี่ยนกลับไปใช้ค่าจำกัดหน่วยความจำ และเริ่ม PHP workers ใหม่ทั้งหมด [2]
ข้อควรระวัง: การตั้งค่านี้เป็นการยกเลิกขีดจำกัดหน่วยความจำต่อคำขอ จึงต้องจำกัดขนาดคำขอที่เว็บเซิร์ฟเวอร์หรือ Reverse Proxy และพิจารณาควบคุมหน่วยความจำด้วย Container หรือ cgroup ตามความเหมาะสม ไม่ควรใช้ RLIMIT_AS หรือ RLIMIT_DATA ทดแทน เนื่องจากอาจกระตุ้นเงื่อนไขที่มีช่องโหว่ ทั้งนี้ มาตรการดังกล่าวยังไม่ป้องกันทุกกรณี [2] มาตรการสำหรับ CVE-2026-109619
กำหนด session.upload_progress.enabled=0 และสำหรับ PHP 8.5 ให้กำหนด fatal_error_backtraces=0 เพิ่มเติม โดยใช้ไฟล์ตั้งค่าที่มีผลก่อนประมวลผลคำขอ และเริ่ม PHP workers ใหม่ทั้งหมด ไม่ควรอาศัยการตั้งค่าผ่าน ini_set() ภายในแอป [3]
มาตรการชั่วคราวลดความเสี่ยงได้เฉพาะบางเส้นทางการโจมตี ไม่สามารถทดแทนการอัปเดตได้อย่างสมบูรณ์
5. ข้อควรทราบเพิ่มเติมหลังอัปเดต
คำแนะนำเพิ่มเติมสำหรับช่องโหว่ CVE-2026-115560
ประกาศ PHP วันที่ 23 ตุลาคม 2569 แนะนำให้ปิด session.upload_progress.enabled = 0 เพื่อป้องกันเส้นทาง RCE อีกกรณีหนึ่งที่เกี่ยวข้องกับ CVE-2026-115560 ซึ่งเกิดภายใต้เงื่อนไขเฉพาะของการตั้งค่าและการเปลี่ยนวิธีจัดการข้อมูล Session ระหว่างการทำงานของแอปพลิเคชัน [1]
หน่วยงานที่ปิดค่านี้ไว้แล้วควรคงค่าไว้ และติดตามประกาศ PHP ก่อนเปิดกลับ โดยประเด็นนี้เป็นข้อมูลเพิ่มเติมแยกจากสอง CVE หลักข้างต้น
ThaiCERT ขอให้หน่วยงานสำรวจ PHP ตามสภาพแวดล้อมจริง โดยใช้ทั้ง 8 กลุ่มระบบเป็นแนวทาง ตรวจยืนยันแพตช์ให้ครบทุกบริการ และปรับปรุงชุดติดตั้งสำรอง เพื่อป้องกันการนำรุ่นที่มีช่องโหว่กลับมาใช้งาน
แหล่งอ้างอิง
[1] https://dg.th/pj91vekmw0
[2] https://dg.th/b41ya7tsqp
[3] https://dg.th/bejakg93lh
[4] https://dg.th/gshnfzpewr
[5] https://dg.th/nvcs0i4kdo
[6] https://dg.th/mdoear7nh3
[7] https://dg.th/vdyjgxk72e2
[8] https://dg.th/sr1k6hji0a