PHP ออกแพตช์ฉุกเฉิน อุดช่องโหว่ร้ายแรง เปิดทางแฮกเกอร์รันโค้ดจากระยะไกล

ทีมพัฒนา PHP ออกแพตช์ความปลอดภัยฉุกเฉินเพื่อแก้ไขช่องโหว่ร้ายแรง 2 รายการ ได้แก่ CVE-2026-109618 และ CVE-2026-109619 ซึ่งถูกติดตามภายใต้ชื่อ PHP2Shell โดยช่องโหว่ทั้งสองเปิดทางให้ผู้โจมตีที่ไม่ต้องผ่านการยืนยันตัวตน สามารถสั่งรันโค้ดจากระยะไกล (Remote Code Execution: RCE) บนเซิร์ฟเวอร์ที่ใช้งาน PHP ได้ ส่งผลให้ระบบที่ให้บริการเว็บไซต์และแอปพลิเคชันบนเว็บมีความเสี่ยง หากยังไม่ได้ติดตั้งแพตช์ที่เกี่ยวข้อง

ช่องโหว่ดังกล่าวถูกค้นพบโดยนักวิจัยด้านความปลอดภัยจาก Calif, OpenAI และ Wiz และส่งผลกระทบต่อการติดตั้ง PHP ที่ให้บริการคำขอจากเว็บ รวมถึง PHP-FPM, Apache ที่ใช้ mod_php, php-cgi, FrankenPHP และ LiteSpeed

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

PHP หรือ Hypertext Preprocessor เป็นภาษาโปรแกรมฝั่งเซิร์ฟเวอร์ที่ใช้พัฒนาเว็บไซต์และเว็บแอปพลิเคชัน โดยเป็นเทคโนโลยีเบื้องหลังเว็บไซต์จำนวนมาก รวมถึงระบบจัดการเนื้อหา (CMS) อย่าง WordPress, Joomla และ Drupal ข้อมูลประมาณการจาก VirusTotal ระบุว่ามีโฮสต์ที่ใช้ PHP และเปิดให้เข้าถึงผ่านอินเทอร์เน็ตมากกว่า 5.1 ล้านโฮสต์ โดยประมาณ 3.8 ล้านโฮสต์มีพอร์ตอย่างน้อยหนึ่งพอร์ตเปิดอยู่

PHP2Shell เปิดทางรันโค้ดบนเซิร์ฟเวอร์โดยไม่ต้องล็อกอิน

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

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

ส่วน CVE-2026-109619 เกิดจากปัญหาสถานะข้อมูลส่วนกลางที่ค้างอยู่ (Stale Global State) ทำให้เกิดช่องโหว่แบบ Heap Use-After-Free ซึ่งเป็นกรณีที่โปรแกรมนำหน่วยความจำที่ถูกคืนหรือเลิกใช้งานแล้วกลับมาใช้งานอย่างไม่ถูกต้อง ผู้โจมตีอาจใช้ช่องโหว่นี้เพื่อเปิดเผยข้อมูลในหน่วยความจำและรันโค้ดจากระยะไกลได้ โดยใช้สิทธิ์ของบัญชีที่ให้บริการเว็บเช่นกัน

ทีมพัฒนาแนะนำให้ผู้ดูแลระบบอัปเดต PHP 8.x เป็นเวอร์ชันที่แก้ไขช่องโหว่แล้วโดยเร็ว ได้แก่ PHP 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 ขณะที่ระบบที่ใช้ PHP 7 หรือต่ำกว่าควรย้ายไปใช้เวอร์ชันที่ได้รับการแก้ไขและยังอยู่ในระยะสนับสนุน

สำหรับ PHP 8.1 และเวอร์ชันเก่ากว่านั้น ซึ่งไม่ได้รับอัปเดตจากโครงการ PHP โดยตรงแล้ว ผู้ดูแลระบบควรตรวจสอบกับผู้ให้บริการระบบปฏิบัติการหรือผู้ให้บริการสนับสนุนระยะยาว (LTS) ว่ามีแพตช์ที่นำกลับไปแก้ไขในเวอร์ชันเดิม (Backport) ให้หรือไม่ หรือพิจารณาอัปเกรดไปใช้เวอร์ชันที่ยังรองรับ

เนื่องจากช่องโหว่มีความรุนแรงสูง ทีมพัฒนา PHP ยังจัดทำแพตช์ซอร์สโค้ดขั้นต่ำสำหรับ PHP 7.4, 8.0 และ 8.1 เพื่อช่วยผู้ที่คอมไพล์ PHP จากซอร์สโค้ดเอง หรือไม่มีช่องทางรับแพตช์จากผู้ให้บริการ LTS

พบสัญญาณโจมตีแล้ว ย้ำมาตรการชั่วคราวใช้แทนแพตช์ไม่ได้

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

Gina Peter Banyard นักพัฒนาหลักของ PHP เตือนว่า ไม่มีมาตรการลดความเสี่ยงใดที่สามารถป้องกันการโจมตี PHP2Shell ได้อย่างสมบูรณ์ การติดตั้งแพตช์ความปลอดภัยอย่างเป็นทางการจึงเป็นแนวทางแก้ไขถาวรที่จำเป็น

ด้าน Dane Knecht ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยี (CTO) ของ Cloudflare เปิดเผยว่า บริษัทพบความพยายามโจมตีช่องโหว่ทั้งสองแล้ว แม้จะนำกฎของ Web Application Firewall (WAF) ซึ่งช่วยกรองคำขอเว็บที่มีลักษณะเป็นอันตราย มาใช้สกัดกั้นรูปแบบการโจมตี PHP2Shell ที่ทราบอยู่ก่อนหน้านี้แล้วก็ตาม อย่างไรก็ตาม มาตรการดังกล่าวเป็นเพียงการป้องกันชั่วคราว และไม่สามารถทดแทนการติดตั้งแพตช์ได้

ขณะที่ศูนย์ความมั่นคงปลอดภัยไซเบอร์แห่งชาติของสหราชอาณาจักร (NCSC) เตือนให้องค์กรในประเทศเร่งอัปเดตระบบที่ใช้ PHP ทันที หรือถอดระบบออกจากเครือข่ายจนกว่าจะสามารถติดตั้งแพตช์ได้

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

ในกรณี CVE-2026-109618 ผู้ดูแลระบบอาจกำหนดค่า memory_limit=-1 ในระดับที่แอปพลิเคชันไม่สามารถเปลี่ยนแปลงได้ เช่น ผ่าน php_admin_value ในการตั้งค่า FPM Pool หรือ Apache พร้อมกำหนดค่า post_max_size ให้ต่ำ เช่น 8MB สำหรับแอปพลิเคชันที่ไม่ต้องอัปโหลดไฟล์ หรือ 32MB สำหรับระบบที่จำเป็นต้องรองรับการอัปโหลด รวมถึงใช้ Container หรือ cgroup จำกัดทรัพยากร เพื่อช่วยควบคุมผลกระทบต่อความพร้อมใช้งานของระบบ

ส่วน CVE-2026-109619 แนะนำให้ปิด session.upload_progress.enabled และรีสตาร์ต Worker ทุกตัว สำหรับ PHP 8.5 สามารถตั้งค่า fatal_error_backtraces=0 และรีสตาร์ต Worker เพื่อปิดช่องทางที่เกี่ยวข้องกับ Fatal Backtrace ซึ่งได้รับการยืนยันแล้ว นอกจากนี้ ควรแก้ไขการตั้งค่าที่ไม่ถูกต้องหรือล้าสมัยซึ่งทำให้เกิดข้อความแจ้งเตือนก่อนการเริ่มต้นระบบ ตลอดจนแก้ไขข้อผิดพลาดร้ายแรงและปัญหาหมดเวลาการทำงานที่ผู้โจมตีสามารถกระตุ้นได้

ทีมพัฒนายังเตือนว่า การซ่อนข้อความแจ้งเตือนด้วย error_reporting, display_errors หรือเครื่องหมาย @ ไม่ได้ช่วยแก้ไขต้นเหตุของช่องโหว่

ที่มา