"PHP แก้ RCE ร้ายแรง CVE-2026-109618 และ CVE-2026-109619"

พอดีเห็น PHP ออกประกาศวันที่ 21 ตุลาคม 2026 เตือนช่องโหว่รันโค้ดจากระยะไกลโดยไม่ต้องยืนยันตัวตนสองรายการ กระทบ PHP ที่รับคำขอเว็บ รวมถึง PHP-FPM, Apache mod_php, php-cgi, FrankenPHP และ LiteSpeed โครงการแนะนำให้อัปเดตทันที โดย mod_php มีการสาธิตโจมตีสำเร็จก่อนโค้ดแอปเริ่มทำงาน ประกาศ PHP

เกิดอะไรขึ้น

CVE-2026-109618: RCE via OOM corruption เกิดเมื่อหน่วยความจำไม่พอ หรือ OOM ขณะ PHP ยังเตรียมข้อมูลคำขอไม่เสร็จ PHP หยุดงาน แต่ขั้นตอนเก็บกวาดคำขอยังนำข้อมูลที่ไม่สมบูรณ์ไปใช้ ผู้พัฒนาทดสอบแล้วว่ารันโค้ดด้วยสิทธิ์บัญชี web worker ได้บน mod_php รายละเอียด OOM

CVE-2026-109619: RCE via stale global state เกิดเมื่อ worker ยังเก็บตัวชี้ไปยังหน่วยความจำของคำขอที่คืนไปแล้ว คำขอถัดไปที่เข้า worker เดิมอาจใช้ข้อมูลเก่านั้น เกิด use-after-free และนำไปสู่ RCE กรณีที่ทดสอบยืนยันแล้วเกี่ยวข้องกับ session upload progress และ fatal error backtrace ใน PHP 8.5 เงื่อนไขขึ้นกับแอปและการตั้งค่า ทั้งสองรายการอยู่ระดับ Critical คะแนน CVSS v4.0 9.2 รายละเอียด stale state

ใครโดนและรุ่นที่แก้

ผู้ดูแลเว็บควรตรวจทุกสายรุ่น ตารางนี้เป็นรุ่นที่โครงการ PHP แก้ช่องโหว่ทั้งสองรายการ

PHP 8.1 และเก่ากว่าไม่ได้รับอัปเดตตามปกติจากโครงการแล้ว ผู้ใช้ Linux distribution หรือ LTS ต้องตรวจแพตช์ backport กับผู้จัดทำแพ็กเกจ ทีม PHP ให้ minimal source-backport สำหรับ 7.4, 8.0 และ 8.1 เป็นกรณีพิเศษ รุ่นแก้และแนวทางอัปเดต

ต้องทำอะไร

อัปเดตตามตาราง หรือใช้แพ็กเกจที่ distribution ยืนยันว่ารวมแพตช์ ตรวจ runtime ของเว็บและเปลี่ยน worker ให้ใช้ไบนารีใหม่ อย่าตรวจเฉพาะ CLI

ถ้ายังอัปเดตไม่ได้ ผู้พัฒนาแนะนำชั่วคราวดังนี้

• สำหรับ OOM บังคับ memory_limit=-1 ผ่านค่าระดับผู้ดูแลและตรวจว่าไม่มีค่าระดับอื่นกำหนดเพดานกลับมา วิธีนี้ตัดเส้นทางจาก PHP memory limit แต่ allocation ของระบบยังล้มเหลวได้
• ตั้ง post_max_size เป็น 8M เมื่อไม่ต้องอัปโหลด หรือ 32M เมื่อต้องอัปโหลด โดยให้ upload_max_filesize ต่ำกว่า ที่เว็บเซิร์ฟเวอร์หรือ proxy ให้จำกัดขนาดคำขอหลังถอดรหัส จำนวน field, multipart part, header และความลึกของข้อมูลด้วย ข้อจำกัดต้องครอบคลุมคำขอที่ไม่มี Content-Length ที่ใช้งานได้
• ใช้ container หรือ cgroup จำกัดหน่วยความจำ โดยควรหยุดเฉพาะ worker ที่มีปัญหา ห้ามใช้ RLIMIT_AS หรือ RLIMIT_DATA แทน เพราะอาจทำให้เกิด allocation failure ที่เข้าเส้นทางช่องโหว่ ข้อจำกัดของมาตรการ OOM
• สำหรับ stale state ตั้ง session.upload_progress.enabled=0 ใน php.ini, FPM pool หรือ server configuration ที่มีผลก่อน PHP อ่านคำขอ แล้วรีสตาร์ตทุก worker อย่าพึ่งพา ini_set() หรือ FPM .user.ini ส่วน PHP 8.5 ให้ตั้ง fatal_error_backtraces=0 และรีสตาร์ตทุก worker เช่นกัน
• แก้ค่าตั้งที่ถูกนำมาใช้ต่อคำขอแล้วเกิด warning, notice หรือ deprecation ก่อนเริ่มต้นระบบตามปกติ พร้อมแก้จุดที่ผู้โจมตีทำให้เกิด fatal error หรือ timeout ได้ การซ่อนข้อความด้วย error_reporting, display_errors หรือ @ ไม่แก้ปัญหา ข้อจำกัดของมาตรการ stale state

ส่วนตัวผมให้เรื่องนี้เป็นงานแพตช์ทันทีสำหรับระบบที่รับคำขอเว็บ โดยจัด mod_php ไว้ลำดับแรก ที่มา: Security advisory: Critical remote code execution vulnerabilities, update now (https://www.php.net/index.php#2026-10-21-5) หากมีรายละเอียดที่ต้องขยาย เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ