ผู้เขียน: Nitirat Salee

ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่งชาติ (ThaiCERT) ได้ติดตามสถานการณ์ภัยคุกคามทางไซเบอร์ พบรายงานช่องโหว่ใน PHP จำนวน 2 รายการ ได้แก่ CVE-2026-109618 และ CVE-2026-109619 หรือที่เรียกว่า PHP2Shell ซึ่งอาจเปิดโอกาสให้ผู้โจมตีที่ไม่มีบัญชีผู้ใช้ส่งคำขอที่สร้างขึ้นเป็นพิเศษ เพื่อรันคำสั่งบนเซิร์ฟเวอร์ด้วยสิทธิ์ของบัญชี Web Server และควบคุมระบบจากภายนอกได้ ช่องโหว่ส่งผลกระทบต่อระบบที่ใช้ PHP ให้บริการเว็บไซต์และ Web Application รวมถึง PHP-FPM, Apache mod_php, php-cgi, FrankenPHP และ LiteSpeed ปัจจุบันมีการเผยแพร่ Proof of Concept (PoC) สู่สาธารณะแล้ว และ PHP ได้เผยแพร่เวอร์ชันที่แก้ไขแล้ว [1]

1. รายละเอียดช่องโหว่
1.1 CVE-2026-109618 (CVSS v4.0: 9.2)[2] – Out-of-Memory State Corruption เป็นช่องโหว่จากการจัดการหน่วยความจำเมื่อระบบเกิดภาวะหน่วยความจำไม่เพียงพอ หรือ Out-of-Memory (OOM) ไม่เหมาะสม ในบางช่วง PHP อาจยุติการประมวลผลขณะที่ข้อมูลภายในของคำขอยังถูกเตรียมไม่สมบูรณ์ ทำให้ขั้นตอนปิดคำขอนำข้อมูลที่ไม่ถูกต้องไปประมวลผลต่อ ผู้โจมตีอาจส่งคำขอแบบ Multipart ที่ใช้หน่วยความจำจำนวนมาก เพื่อกระตุ้นเงื่อนไขดังกล่าวและรันคำสั่งบนเซิร์ฟเวอร์ด้วยสิทธิ์ของบัญชี Web Server ได้ โดย PHP ยืนยันผลกระทบกับ Apache mod_php แล้ว ส่วน PHP-FPM อาจได้รับผลกระทบภายใต้เงื่อนไขของ Web Application [3]
1.2 CVE-2026-109619 (CVSS v4.0: 9.2)[4] – Use-After-Free / Stale Global State เป็นช่องโหว่ที่เกิดจากสถานะส่วนกลางของ PHP ยังคงอ้างอิงข้อมูลของคำขอก่อนหน้า แม้ว่าหน่วยความจำดังกล่าวจะถูกคืนให้ระบบแล้ว เมื่อ Worker เดิมรับคำขอถัดไป อาจนำข้อมูลที่ค้างอยู่กลับมาใช้งานก่อนขั้นตอนเริ่มต้นตามปกติ ผู้โจมตีอาจจัดเตรียมคำขอหลายรายการให้ถูกประมวลผลโดย Worker เดียวกัน เพื่อนำไปสู่การรันคำสั่งบนระบบและควบคุมเซิร์ฟเวอร์จากภายนอก โดยพบช่องทางที่เกี่ยวข้องกับ Session Upload Progress, Fatal Error และสถานะภายในอื่นของ PHP และมีการยืนยันผลกระทบกับทั้ง Apache mod_php และ PHP-FPM ภายใต้เงื่อนไขที่เกี่ยวข้อง [5]

2. ผลิตภัณฑ์ที่ได้รับผลกระทบ [6]
– PHP 8.2 ที่ต่ำกว่า version 8.2.35
– PHP 8.3 ที่ต่ำกว่า version 8.3.36
– PHP 8.4 ที่ต่ำกว่า version 8.4.27
– PHP 8.5 ที่ต่ำกว่า version 8.5.12
– PHP 8.1 และเวอร์ชันเก่ากว่าที่สิ้นสุดการสนับสนุนและยังไม่ได้รับแพตช์จาก Linux Distribution หรือผู้ให้บริการ Extended Support

รูปแบบการติดตั้งที่ต้องตรวจสอบประกอบด้วย PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed หรือ LSAPI รวมถึง PHP ภายใน Container, Docker Image, Hosting Control Panel และผลิตภัณฑ์สำเร็จรูปที่มี PHP เป็นส่วนประกอบ

3. แนวทางการแก้ไข [4]
3.1 ตรวจสอบเวอร์ชัน PHP ทุกระบบภายในหน่วยงาน รวมถึง Web Server, Application Server, Container, Hosting Control Panel ระบบสำรอง และผลิตภัณฑ์ที่มี PHP รวมอยู่ภายใน โดยสามารถใช้คำสั่ง php -v เพื่อตรวจสอบเวอร์ชัน
3.2 เร่งอัปเดตเป็นเวอร์ชันที่ได้รับการแก้ไข ดังนี้
– สำหรับ PHP 8.2 ให้อัปเดตเป็น version 8.2.35 หรือใหม่กว่า
– สำหรับ PHP 8.3 ให้อัปเดตเป็น version 8.3.36 หรือใหม่กว่า
– สำหรับ PHP 8.4 ให้อัปเดตเป็น version 8.4.27 หรือใหม่กว่า
– สำหรับ PHP 8.5 ให้อัปเดตเป็น version 8.5.12 หรือใหม่กว่า
3.3 สำหรับระบบที่ติดตั้ง PHP ผ่าน Linux Distribution, Hosting Provider หรือ Control Panel ให้ตรวจสอบและติดตั้งแพ็กเกจที่ผู้ให้บริการรับรอง เนื่องจากบางแพ็กเกจอาจใช้หมายเลขเวอร์ชันเดิม แต่มีการนำแพตช์ความปลอดภัยกลับมาติดตั้งแล้ว
3.4 ระบบที่ใช้ PHP 8.1 หรือต่ำกว่า ควรย้ายไปใช้ PHP เวอร์ชันที่ยังได้รับการสนับสนุน หากยังไม่สามารถย้ายได้ ให้ตรวจสอบแพตช์จาก Linux Distribution หรือผู้ให้บริการ Extended Support โดยตรง ทั้งนี้ PHP ได้จัดเตรียม Source Backport ขั้นต่ำสำหรับ PHP 7.4, 8.0 และ 8.1 สำหรับผู้ดูแลระบบที่คอมไพล์ PHP เอง
3.5 หลังอัปเดต ให้ Restart PHP Worker และ Web Server ที่เกี่ยวข้อง เช่น PHP-FPM, Apache หรือ LiteSpeed เพื่อให้ระบบโหลด Binary และ Library ที่ได้รับการแก้ไขแล้ว
3.6 สำหรับระบบที่ใช้ Container ให้สร้าง Image ใหม่จาก Base Image ที่ได้รับการแก้ไข จากนั้น Deploy Container ใหม่ และตรวจสอบว่า Container ที่กำลังให้บริการไม่ได้ใช้ PHP เวอร์ชันเดิม
3.7 ตรวจสอบ Apache, PHP-FPM, Reverse Proxy และ Application Log เพื่อค้นหาเหตุการณ์ผิดปกติ เช่น Out-of-Memory, Fatal Error, Parse Error, Uncaught Error, ข้อความ Maximum execution time exceeded และ Worker ที่หยุดทำงานหรือ Restart บ่อยผิดปกติ
3.8 ตรวจสอบคำขอแบบ Multipart/Form-Data ที่มีขนาดใหญ่ ไม่มีค่า Content-Length ที่ใช้งานได้ มี Header หรือ Input Field จำนวนมาก รวมถึงการอัปโหลดไฟล์และ Session Upload Progress ที่เกิดขึ้นต่อเนื่องจากแหล่งที่ไม่รู้จัก
3.9 ตรวจสอบ Process และ Network Connection ที่เกิดจากบัญชี Web Server เช่น www-data, apache หรือ nginx รวมถึงไฟล์ที่ถูกสร้างหรือแก้ไขใน Web Root, Temporary Directory และ Upload Directory โดยไม่ทราบที่มา
3.10 หากพบหลักฐานการเข้าถึงโดยไม่ได้รับอนุญาต ให้แยกระบบออกจากเครือข่ายส่วนที่ไม่จำเป็น เก็บรักษา Log และหลักฐานที่เกี่ยวข้อง และดำเนินการตามกระบวนการตอบสนองเหตุการณ์ทันที

4. แนวทางปฏิบัติกรณีไม่สามารถอัปเดตได้ทันที
4.1 สำหรับ CVE-2026-109618 ให้กำหนด memory_limit=-1 ในระดับผู้ดูแลระบบ และตรวจสอบว่า PHP-FPM Pool, Directory หรือ Web Application ไม่สามารถเปลี่ยนกลับไปใช้ค่าจำกัดหน่วยความจำได้ จากนั้น Restart PHP Worker ทุก Process
4.2 กำหนดค่า post_max_size ให้อยู่ในระดับต่ำและเหมาะสมกับการใช้งาน โดย PHP แนะนำให้พิจารณากำหนดเป็น 8M สำหรับระบบที่ไม่ต้องอัปโหลดไฟล์ หรือ 32M สำหรับระบบที่จำเป็นต้องอัปโหลดไฟล์ พร้อมกำหนด upload_max_filesize ให้ต่ำกว่า post_max_size
4.3 จำกัดขนาดคำขอ จำนวน Input Field, Multipart Part, Header, ไฟล์อัปโหลด และระดับการซ้อนของข้อมูลที่ Web Server, Reverse Proxy หรือ Web Application Firewall หากระบบไม่ใช้งาน Multipart/Form-Data หรือการอัปโหลดไฟล์ ให้พิจารณาปิดกั้นคำขอดังกล่าวก่อนส่งต่อไปยัง PHP
4.4 สำหรับ CVE-2026-109619 ให้กำหนด session.upload_progress.enabled=0 ใน php.ini, PHP-FPM Pool หรือ Server Configuration และ Restart PHP Worker ทุก Process
4.5 สำหรับ PHP 8.5 ที่ยังไม่สามารถอัปเดต ให้กำหนด fatal_error_backtraces=0 เพิ่มเติมและ Restart PHP Worker ทุก Process
4.6 แก้ไข Fatal Error, Warning, Deprecated Setting และ Execution Timeout ที่ผู้โจมตีสามารถกระตุ้นผ่าน Web Request ได้ รวมถึงตรวจสอบขั้นตอนอัปโหลด การนำเข้าข้อมูล Serialization, Destructor, Callback และ Extension
4.7 หากไม่สามารถดำเนินการตามมาตรการข้างต้นได้ ให้พิจารณาแยกระบบที่ได้รับผลกระทบออกจากอินเทอร์เน็ต หรือจำกัดการเข้าถึงให้เฉพาะเครือข่ายและ IP Address ที่ได้รับอนุญาตจนกว่าจะติดตั้งแพตช์แล้วเสร็จ
4.8 เพิ่มการเฝ้าระวังเหตุการณ์ผิดปกติและจัดเก็บ Log ให้เพียงพอต่อการตรวจสอบย้อนหลัง โดยการไม่พบข้อผิดพลาดใน Log ไม่สามารถใช้ยืนยันได้ว่าระบบปลอดภัย เนื่องจากบางกรณีอาจเกิดขึ้นก่อนที่ PHP จะบันทึกเหตุการณ์

อ้างอิง https://www.thaicert.or.th/2026/10/22/%E0%B9%81%E0%B8%88%E0%B9%89%E0%B8%87%E0%B9%80%E0%B8%95%E0%B8%B7%E0%B8%AD%E0%B8%99-%E0%B8%9E%E0%B8%9A%E0%B8%8A%E0%B9%88%E0%B8%AD%E0%B8%87%E0%B9%82%E0%B8%AB%E0%B8%A7%E0%B9%88-php2shell-%E0%B9%80/