สรุปสั้น
โครงการ PHP ออกประกาศแจ้งเตือนแบบสั้นเมื่อวันที่ 23 ตุลาคม 2569 ถึงช่องโหว่ใหม่ CVE-2026-115560 ที่อาจเปิดทางให้ผู้โจมตีรันโค้ดบนเว็บเซิร์ฟเวอร์ได้ ประกาศนี้ออกมาเพียงสองวันหลังแพตช์ฉุกเฉินเมื่อ 21 ตุลาคมที่แก้ช่องโหว่วิกฤต PHP2Shell สองตัว คือ CVE-2026-109618 และ CVE-2026-109619 (2026/10/215 ) จุดสำคัญ คือ ช่องโหว่ใหม่เป็นคนละตัวกัน และไม่ได้รับการแก้ใน PHP 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 ที่เพิ่งออกไป ผู้ดูแลที่อัปเกรดเพื่อปิด PHP2Shell แล้วจึงยังไม่ได้ปิดเส้นทางนี้
อย่างไรก็ตาม ช่องโหว่นี้เกิดได้เฉพาะแอปพลิเคชันที่ตั้งค่าในลักษณะที่ไม่ค่อยพบ คือ ตั้ง session.serialize_handler เป็น php_binary หรือ php_serialize แล้วเปลี่ยนกลับเป็น php ด้วย ini_set() ระหว่างรัน ก่อนเรียก session_start() โดยที่ฟีเจอร์ session upload progress ยังเปิดอยู่ (พูดง่าย ๆ คือ สลับรูปแบบการเก็บข้อมูล session กลางคันระหว่างรัน) PHP จึงประเมินว่าความเสี่ยงต่ำ ไม่ออกแพตช์ฉุกเฉิน แต่จะแก้ในรอบ bugfix ปกติถัดไป ระหว่างนี้แนะนำให้ตั้ง session.upload_progress.enabled=0 ซึ่งเป็นค่าเดียวกับที่ PHP เคยแนะนำเป็นมาตรการบรรเทาของ CVE-2026-109619 ไว้แล้ว ยังไม่มีรายงานการโจมตี CVE-2026-115560 ขณะที่การสแกนหา PHP2Shell สองตัวแรกยังพุ่งสูงต่อเนื่อง
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 23 ตุลาคม 2569 ว่า PHP เผยแพร่ประกาศเชิงข้อมูล (informational advisory) สั้น ๆ เตือนถึงอีกเส้นทางหนึ่งที่ผู้โจมตีอาจใช้รันโค้ดบนเว็บเซิร์ฟเวอร์ได้ ช่องโหว่ได้หมายเลข CVE-2026-115560 และกระทบเฉพาะเว็บแอปพลิเคชันที่ตั้งค่าแบบผิดปกติ PHP เองระบุว่าการตั้งค่าแบบนี้ “ไม่น่าจะพบในทางปฏิบัติ”
ประกาศนี้ตามหลังการออกเวอร์ชันฉุกเฉินเมื่อวันที่ 21 ตุลาคม ที่แก้ PHP2Shell สองตัว ซึ่งเปิดให้ผู้โจมตีที่ไม่มีบัญชีรันโค้ดบนเซิร์ฟเวอร์ได้ แต่ CVE-2026-115560 เป็นปัญหาแยกต่างหาก และเวอร์ชันที่ออกไปเมื่อ 21 ตุลาคมไม่ได้แก้ไว้ PHP จึงไม่ออกแพตช์ฉุกเฉินรอบที่สอง แต่จะจัดการในรอบปกติ และจะเผยแพร่ประกาศฉบับเต็มของ CVE-2026-115560 พร้อมเวอร์ชันถัดไป
ข้อจำกัดของข้อมูลตอนนี้มีหลายจุด PHP ยังไม่ระบุว่าเวอร์ชันใดได้รับผลกระทบ เวอร์ชันใดจะมีแพตช์ คะแนนความรุนแรงเท่าใด และยังไม่บอกว่าช่องโหว่ใหม่มีต้นเหตุร่วมกับ CVE-2026-109619 หรือไม่ ข้อสังเกตเดียวที่ชี้ความเชื่อมโยง คือ มาตรการบรรเทาเป็นค่าเดียวกัน
ส่วน PHP2Shell สองตัวแรก ความพยายามโจมตีเพิ่มขึ้นอย่างรวดเร็ว บริษัท Amazon ระบุว่า honeypot บันทึกความพยายามโจมตี CVE-2026-109618 และ CVE-2026-109619 ได้ตั้งแต่ 17 ตุลาคม หรือ 4 วันก่อนเปิดเผยช่องโหว่ ขณะที่บริษัท Cloudflare พบความพยายามเพิ่มจากหลักหมื่นครั้งภายใน 45 นาทีหลังประกาศเมื่อ 21 ตุลาคม เป็นหลักล้านครั้งในเช้าวันที่ 22 ตุลาคม บริษัท Sophos และ Arctic Wolf รายงานความพยายามใช้ช่องโหว่ติดตั้งบอตเน็ต Mirai สายพันธุ์หนึ่ง แต่จนถึงตอนนี้ยังไม่สำเร็จ Previdian, Wordfence และรายอื่นพบเพียงการสแกนและการหยั่งเชิง ยังไม่มีการยืนยันว่ารันโค้ดได้จริง และนักวิจัยระบุว่าการสร้างโค้ดโจมตีที่เชื่อถือได้ยากกว่าที่คาด กิจกรรมทั้งหมดนี้เล็ง PHP2Shell สองตัวแรก ไม่ใช่ CVE-2026-115560
รายละเอียดช่องโหว่
PHP ระบุว่าปัญหาจะเกิดได้เมื่อเว็บแอปพลิเคชันทำครบทุกข้อต่อไปนี้
- ตั้ง
session.serialize_handlerเป็นphp_binaryหรือphp_serializeในคอนฟิก - เปลี่ยนค่านั้นกลับเป็น
phpระหว่างรันด้วยการเรียกini_set() - เปลี่ยนค่าดังกล่าวก่อนเรียก
session_start() - ฟีเจอร์ session upload progress (
session.upload_progress.enabled) ยังเปิดอยู่ ซึ่งเป็นค่าเริ่มต้นของ PHP
session upload progress เป็นฟีเจอร์ที่ให้แอปติดตามความคืบหน้าของการอัปโหลดไฟล์ โดย PHP จะเขียนข้อมูลความคืบหน้าลงใน session ระหว่างที่คำขออัปโหลดยังส่งอยู่ ประกาศของ PHP ไม่ได้ลงรายละเอียดกลไก แต่เงื่อนไขข้างต้นบ่งชี้ว่าปัญหาอยู่ที่ช่วงที่รูปแบบ serialize ของข้อมูล session ไม่ตรงกันระหว่างตอนเขียนกับตอนอ่าน
แอปที่ไม่เคยเปลี่ยน serialize handler ระหว่างรันไม่ได้รับผลกระทบผ่านเส้นทางนี้ และเปิด session upload progress ต่อได้ ส่วนผู้ที่ตั้ง session.upload_progress.enabled=0 ไว้แล้วตามคำแนะนำของประกาศ CVE-2026-109619 เมื่อ 21 ตุลาคม และยังคงค่านั้นอยู่ ไม่ต้องทำอะไรเพิ่ม
ผลกระทบ
ความเสี่ยงในวงกว้างของ CVE-2026-115560 ต่ำกว่า PHP2Shell มาก เพราะต้องอาศัยแอปที่เขียนโค้ดสลับ serialize handler เอง ซึ่ง PHP ยืนยันว่าพบได้ยาก ผู้ที่ควรตรวจ คือ เจ้าของแอป PHP ที่พัฒนาเองหรือเฟรมเวิร์กเก่าที่จัดการ session ด้วยตัวเอง และผู้ให้บริการโฮสติ้งที่ต้องรองรับแอปของลูกค้าหลายแบบ ซึ่งไม่อาจรู้ได้ว่าแอปใดเรียก ini_set() แบบนี้บ้าง
ผลกระทบที่ใหญ่กว่า คือ ความเข้าใจผิดว่า “อัปเกรดแล้วจบ” หน่วยงานที่เพิ่งเร่งอัปเกรดเป็น 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 เพื่อปิด PHP2Shell รวมถึงหน่วยงานไทยที่ทำตามข้อสั่งการของ อว. และ สกมช. (2026/10/215 ) ต้องรู้ว่าเวอร์ชันเหล่านั้นยังไม่ปิด CVE-2026-115560 ขณะเดียวกัน PHP ยังไม่ประกาศเวอร์ชันที่กระทบและคะแนนความรุนแรง การประเมินความเสี่ยงจึงต้องอิงเงื่อนไขการตั้งค่าเป็นหลักไปจนกว่าจะมีประกาศฉบับเต็ม
คำแนะนำ
- ตั้ง
session.upload_progress.enabled=0ในphp.ini(หรือคอนฟิกของ PHP-FPM แต่ละ pool) จนกว่าจะมีรอบ bugfix ถัดไป เว้นแต่แอปต้องใช้แถบแสดงความคืบหน้าการอัปโหลดจริง - ตรวจซอร์สโค้ดหาการเรียก
ini_set('session.serialize_handler', ...)โดยเฉพาะที่อยู่ก่อนsession_start()และเทียบกับค่าsession.serialize_handlerในคอนฟิกหลัก - ถ้าเคยตั้ง
session.upload_progress.enabled=0ตามประกาศ CVE-2026-109619 ไปแล้ว ให้ยืนยันว่าค่านั้นยังอยู่หลังอัปเกรดเวอร์ชัน เพราะการติดตั้งแพ็กเกจใหม่อาจเขียนทับคอนฟิกได้ (ตรวจด้วยphp -i | grep upload_progressหรือphpinfo()บนเว็บเซิร์ฟเวอร์จริง) - อัปเกรดเป็น PHP 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 ต่อไปเพื่อปิด PHP2Shell สองตัวแรกซึ่งถูกสแกนหนักอยู่ตอนนี้
- ติดตามประกาศฉบับเต็มของ CVE-2026-115560 และรอบ bugfix ถัดไปจาก php.net เพื่อดูเวอร์ชันที่กระทบ เวอร์ชันที่แก้ และคะแนนความรุนแรง
- ผู้ให้บริการโฮสติ้งควรพิจารณาปิด session upload progress เป็นค่าเริ่มต้นทั้งระบบ แล้วเปิดเฉพาะลูกค้าที่ร้องขอ