ช่องโหว่ PHP CVE-2026-109618·109619 และวิธีรับมือ

พบช่องโหว่ CVE-2026-109618 และ CVE-2026-109619 ในกระบวนการจัดการการสิ้นสุดการทำงานผิดปกติและสถานะคำขอของ PHP core engine ซึ่งเปิดให้รันโค้ดจากระยะไกล (RCE) ได้โดยไม่ต้องยืนยันตัวตน ปัญหานี้ไม่ได้เกิดจากเว็บแอปพลิเคชันอย่าง WordPress หรือ GNUBoard แต่เกิดจากข้อบกพร่องด้านหน่วยความจำเสียหายและการนำหน่วยความจำที่ถูกคืนไปแล้วกลับมาใช้ (Use-After-Free) ใน PHP execution engine เอง หากต้องการแก้ไข ควรอัปเกรดเป็น PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 หรือเวอร์ชันที่มี security patch โดยทันที และรีสตาร์ต worker process

ช่องโหว่ PHP engine ที่ไม่สามารถป้องกันได้ด้วยการอัปเดตเว็บแอปพลิเคชันเพียงอย่างเดียว

เมื่อวันที่ 21 ตุลาคม 2026 (UTC) ทีมพัฒนา PHP ประกาศช่องโหว่ด้านความปลอดภัย 2 รายการ ซึ่งมีระดับความรุนแรง 9.2 คะแนนตาม CVSS v4.0 ผู้โจมตีสามารถรันโค้ดใด ๆ บนเซิร์ฟเวอร์ได้เพียงส่ง HTTP request ที่ถูกสร้างขึ้นมาเป็นพิเศษ โดยไม่ต้องผ่านกระบวนการเข้าสู่ระบบ

ข้อบกพร่องนี้ทำงานใน PHP core layer ซึ่งใช้แยกวิเคราะห์เว็บ request และทำความสะอาดหน่วยความจำ ดังนั้น แม้จะอัปเดต CMS หรือปลั๊กอินของเว็บไซต์ให้เป็นเวอร์ชันล่าสุด หาก PHP runtime ยังเป็นเวอร์ชันเก่า ก็ยังมีความเสี่ยงต่อการโจมตี โดยเฉพาะสภาพแวดล้อมที่ใช้ค่าเริ่มต้นของ Apache mod_php ซึ่งพบว่าสามารถรันโค้ดได้จาก request เดียว ก่อนที่โค้ดของเว็บแอปพลิเคชันจะเริ่มทำงาน

หากการโจมตีสำเร็จ ผู้บุกรุกจะได้รับสิทธิ์ของ system account ที่ใช้รัน PHP process แม้จะยังไม่ได้สิทธิ์ root ในทันที แต่สามารถสร้าง web shell ใน web root directory หรืออ่านข้อมูลการเชื่อมต่อฐานข้อมูลที่บันทึกไว้ใน configuration file เพื่อลักลอบนำข้อมูลภายในออกไปหรือแก้ไขข้อมูลได้ หากหลายเว็บไซต์บนเซิร์ฟเวอร์เดียวกันใช้ PHP-FPM execution account ร่วมกัน การถูกเจาะเว็บไซต์หนึ่งอาจแพร่กระจายไปยังเว็บไซต์อื่นบนเซิร์ฟเวอร์ได้

หลักการของหน่วยความจำเสียหายและ Use-After-Free ที่เกิดขึ้นเมื่อการทำงานสิ้นสุดผิดปกติ

ช่องโหว่ทั้งสองรายการเกิดจากการไม่สามารถทำความสะอาดหน่วยความจำได้อย่างปลอดภัยเมื่อเกิดสถานการณ์ผิดปกติระหว่างประมวลผล request เงื่อนไขการเกิดและการทำงานภายในของแต่ละรายการแตกต่างกัน

CVE-2026-109618 (หน่วยความจำเสียหายระหว่างจัดการเมื่อใช้หน่วยความจำเกินขีดจำกัด): เมื่อ PHP ประมวลผล request แล้วใช้หน่วยความจำเกินขีดจำกัดที่อนุญาต (Out-Of-Memory) PHP จะเรียก longjmp() เพื่อหยุดการทำงานทันที หากการทำงานหยุดลงในขณะที่ internal request data structure ยังเริ่มต้นไม่สมบูรณ์ สถานะที่ไม่สมบูรณ์นั้นอาจไม่ถูก rollback และยังคงอยู่ จากนั้น cleanup routine ที่ทำงานภายหลังจะเชื่อว่าหน่วยความจำที่ยังไม่ได้เริ่มต้นดังกล่าวเป็นข้อมูลปกติและเข้าถึงหน่วยความจำนั้น จนนำไปสู่หน่วยความจำเสียหายและการรันโค้ดจากระยะไกล

CVE-2026-109619 (Use-After-Free ที่อ้างอิงหน่วยความจำของ request ก่อนหน้าซึ่งถูกคืนไปแล้ว): global state หรือ error handling state บางส่วนภายใน PHP จะชี้ไปยังพื้นที่หน่วยความจำที่ request เดียวเป็นเจ้าของชั่วคราว เมื่อ request สิ้นสุดผิดปกติจาก fatal error หรือหน่วยความจำไม่เพียงพอ หน่วยความจำจริงอาจถูกคืนไปแล้ว แต่ internal pointer reference ที่ชี้ไปยังหน่วยความจำนั้นอาจไม่ได้ถูกรีเซ็ต ในสภาพแวดล้อมที่นำ worker process กลับมาใช้ซ้ำ เช่น PHP-FPM หรือ mod_php เมื่อ worker เดิมรับ HTTP request ถัดไปและเริ่มประมวลผล การอ่านพื้นที่หน่วยความจำที่ถูกคืนไปแล้วอีกครั้ง (Use-After-Free) จะสร้างเส้นทางไปสู่การรันโค้ด

ประกาศด้านความปลอดภัยอย่างเป็นทางการระบุเส้นทางที่ยืนยันแล้วของ CVE-2026-109619 ได้แก่ฟังก์ชัน session upload progress (session.upload_progress), configuration warning ที่แสดงก่อนการเริ่มต้น request และ fatal error backtrace ของ PHP 8.5 (fatal_error_backtraces) อย่างไรก็ตาม ประกาศระบุว่าการปิดกั้นเส้นทางเหล่านี้ยังไม่สามารถกำจัดเส้นทางดัดแปลงอื่น ๆ ได้ทั้งหมด

สถานะ patch แยกตาม PHP version และขอบเขตผลกระทบตามสภาพแวดล้อมการทำงาน

PHP 8.2~8.5 ที่ต่ำกว่าเวอร์ชันที่แก้ไขแล้วได้รับผลกระทบ ส่วน 8.1 และเก่ากว่าซึ่งสิ้นสุดการสนับสนุนแล้ว ไม่ได้อยู่ในขอบเขตการอัปเดตอย่างเป็นทางการของ PHP project รูปแบบการทำงานที่ได้รับผลกระทบครอบคลุมการติดตั้งทั้งหมดที่ประมวลผลเว็บ request เช่น PHP-FPM, mod_php, php-cgi, FrankenPHP และ LiteSpeed โดยประกาศอย่างเป็นทางการประเมินว่า mod_php มีความเสี่ยงสูงที่สุด Red Hat จัดประเภทว่า PHP-FPM อาจได้รับผลกระทบแบบมีเงื่อนไขผ่านเส้นทางในระดับแอปพลิเคชัน

สภาพแวดล้อมที่ตรวจสอบ: ณ วันที่ 22 ตุลาคม 2026 ได้อัปเกรด PHP 8.4.26 เป็น 8.4.27 บน Linux server environment ที่ใช้ Remi repository พร้อมตรวจสอบการรีสตาร์ต PHP-FPM worker และการมีผลกับเว็บ request แล้ว

ขั้นตอนการอัปเดตแพ็กเกจและใช้การตั้งค่าเพื่อบรรเทาผลกระทบของ PHP-FPM

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

1. ติดตั้งการอัปเดต PHP package
   อัปเกรดแพ็กเกจผ่าน package manager ของระบบปฏิบัติการไปเป็น patch version ของ PHP ตระกูลที่ใช้งานอยู่ (สำหรับตระกูล 8.4 คือ 8.4.27) หลังติดตั้ง ให้ตรวจสอบ CLI version ใน terminal ก่อน

   php -v

   เมื่อรันคำสั่ง หน้าจอจะแสดง version number และ build date ที่อัปเดตแล้ว เช่น PHP 8.4.27 (cli) อย่างไรก็ตาม CLI version กับ version ของ PHP process ที่เว็บเซิร์ฟเวอร์เชื่อมต่อจริงอาจแตกต่างกัน จึงต้องดำเนินการขั้นตอนถัดไปด้วย

2. ปรับ PHP-FPM setting เพื่อลด attack surface (ตัวเลือกและการบรรเทาผลกระทบชั่วคราว)
   หากยังไม่สามารถใช้การอัปเดตได้ทันที หรือต้องการเพิ่มชั้นการป้องกัน ให้สำรองข้อมูล php.ini หรือ PHP-FPM pool configuration file (เช่น /etc/php-fpm.d/www.conf) แล้วปรับรายการต่อไปนี้

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   การปิดใช้งาน session.upload_progress.enabled จะปิดกั้นเส้นทางการโจมตีที่ยืนยันแล้วซึ่งอาศัย session ได้ การลดค่า post_max_size (เช่น 8M สำหรับสภาพแวดล้อมที่ไม่จำเป็นต้องอัปโหลดไฟล์ หรือ 32M สำหรับสภาพแวดล้อมที่จำเป็น) จะทำให้การพยายามทำให้หน่วยความจำหมดด้วย request ขนาดใหญ่ทำได้ยากขึ้น ในกรณีนี้ ควรกำหนด upload_max_filesize ให้เล็กกว่า post_max_size เล็กน้อย โดยคำนึงถึงขนาด multipart auxiliary header ด้วย หากเป็นสภาพแวดล้อม PHP 8.5 ให้ใช้การตั้งค่า fatal_error_backtraces = 0 ร่วมด้วย

3. ตรวจสอบไวยากรณ์ PHP-FPM setting และรีสตาร์ต process
   หลังบันทึกการตั้งค่า ให้ทดสอบว่าไม่มี syntax error และรีสตาร์ต PHP-FPM service

   php-fpm -t
   systemctl restart php-fpm

   เมื่อรัน php-fpm -t หากการตั้งค่าไม่มีปัญหา หน้าจอจะแสดงข้อความ NOTICE: configuration file ... test is successful ต้องรีสตาร์ต worker process เพื่อให้ worker รุ่นเก่าที่ค้างอยู่ในหน่วยความจำสิ้นสุดการทำงาน และให้ patch กับการตั้งค่าใหม่มีผล

4. ตรวจสอบ version ที่มีผลจริงผ่านเว็บ request
   เรียกดูแท็บข้อมูล 'Site Health' ของ WordPress หรือหน้าเว็บสำหรับวินิจฉัยการเชื่อมต่อกับเว็บเซิร์ฟเวอร์ เพื่อตรวจสอบว่า PHP-FPM worker ที่ประมวลผลเว็บ request ตอบกลับด้วย patch version เช่น 8.4.27 หรือไม่ หากมีไฟล์ PHP สำหรับการวินิจฉัยที่สร้างขึ้นชั่วคราวเพื่อการตรวจสอบ ให้ลบทันทีหลังตรวจเสร็จ เพื่อไม่ให้ข้อมูลระบบถูกเปิดเผยต่อภายนอก

แนวทางรับมือเมื่อการอัปเดตล่าช้าหรือเกิดผลข้างเคียงจากการเปลี่ยนการตั้งค่า

เมื่อ mirror ของ third-party repository (เช่น Remi) ซิงค์ล่าช้า ทำให้ดาวน์โหลดแพ็กเกจไม่ได้

หลัง security patch ฉุกเฉินเผยแพร่ไม่นาน อาจเกิดการเข้าชมหนาแน่นหรือการซิงค์ล่าช้า ทำให้ไม่พบ update package ทันทีจาก third-party repository (เช่น rpms.remirepo.net) หรือดาวน์โหลดได้ช้า ประกาศอย่างเป็นทางการระบุว่า update อาจยังไม่ถูกเผยแพร่ใน repository ที่อาสาสมัครดูแลภายในวันที่ประกาศ และแนะนำให้เปลี่ยนไปใช้ distribution package หรือ build จาก source

ในกรณีนี้ สามารถระบุที่อยู่ของ mirror server ที่ซิงค์เสร็จและมีความเร็วปกติด้วยตนเองใน repository setting แล้วดำเนินการอัปเดต แม้จะเปลี่ยน mirror ด้วยตนเอง ก็ควรเปิดใช้การตรวจสอบ GPG signature (gpgcheck=1) ต่อไปเพื่อป้องกันการปลอมแปลงแพ็กเกจ หากไม่สามารถใช้ mirror ได้ ให้ใช้ official backport package ของ OS distribution หรือคอมไพล์ source code โดยตรง

เมื่อกังวลว่าจะเกิดหน่วยความจำไม่เพียงพอ (OOM) หรือการปฏิเสธการอัปโหลดจากการใช้การตั้งค่าบรรเทาผลกระทบ

ประกาศอย่างเป็นทางการเสนอ memory_limit = -1 (ไม่จำกัด) เป็นมาตรการบรรเทาผลกระทบของ CVE-2026-109618 เมื่อยังไม่สามารถอัปเดตได้ทันที และแนะนำให้กำหนด container หรือ cgroup memory limit ร่วมด้วย อย่างไรก็ตาม หากยกเลิก memory limit บนเซิร์ฟเวอร์ที่มี physical memory ไม่มาก request เดียวอาจใช้หน่วยความจำของเซิร์ฟเวอร์ทั้งหมด จนทำให้ OS OOM Killer บังคับยุติ daemon สำคัญและเกิด service outage ได้ การตั้งค่านี้เป็นเพียงมาตรการชั่วคราวก่อนอัปเดต และหลังอัปเดตเป็น patch version แล้ว ควรคืนค่า memory limit เดิมเพื่อความปลอดภัย

นอกจากนี้ เมื่อปรับลด post_max_size จากค่าเดิม (เช่น 64MB) ควรตรวจสอบรูปแบบการส่งไฟล์ของเว็บไซต์ก่อน เว็บไซต์ที่อัปโหลดไฟล์ backup ขนาดใหญ่หรือปลั๊กอินโดยตรงผ่านหน้าเว็บผู้ดูแลระบบอาจถูกปฏิเสธ request ได้ ในทางกลับกัน หากสภาพแวดล้อมส่งไฟล์ขนาดใหญ่ผ่าน SFTP หรือ rsync หรือแอปพลิเคชันมีข้อจำกัดอยู่ที่ 30MB หรือต่ำกว่าแล้ว การลด upload limit ของ PHP เหลือ 32MB จะไม่กระทบต่อบริการ

หากหลังอัปเกรด PHP version แล้ว PHP-FPM worker สิ้นสุดการทำงานผิดปกติเป็นครั้งคราว อาจตรวจสอบการตั้งค่า JIT (Just-In-Time) compilation ของ OPcache ได้ ฟังก์ชัน JIT (เช่น opcache.jit=1255) ไม่ได้เกี่ยวข้องโดยตรงกับช่องโหว่ด้านความปลอดภัยครั้งนี้ แต่หากเคยมีปัญหาด้านเสถียรภาพเมื่อเปลี่ยนเวอร์ชัน สามารถปิดใช้งานด้วย opcache.jit=off ใน configuration file เพื่อป้องกันการชนกัน

คำถามที่พบบ่อย

การอัปเดต WordPress หรือปลั๊กอินเป็นเวอร์ชันล่าสุดจะแก้ปัญหาได้หรือไม่?

แก้ไม่ได้ ช่องโหว่นี้เกิดขึ้นใน PHP core engine ซึ่งทำงานก่อนที่ WordPress หรือ security plugin จะเริ่มทำงาน แม้จะสามารถใช้ web firewall (เช่น Cloudflare หรือ AWS WAF) เพื่อปิดกั้น attack pattern ที่ทราบเป็นการชั่วคราวได้ แต่การแก้ไขที่ต้นเหตุคือต้องอัปเดต PHP version ของเซิร์ฟเวอร์ผ่านผู้ให้บริการโฮสติ้งหรือผู้ดูแลเซิร์ฟเวอร์

หากปิดการตั้งค่า session.upload_progress.enabled แล้ว จะปลอดภัยโดยไม่ต้องอัปเดตหรือไม่?

ไม่ปลอดภัย ประกาศอย่างเป็นทางการระบุว่าการตั้งค่านี้ปิดกั้นได้เฉพาะ session path ที่ยืนยันแล้ว แต่ไม่สามารถปิดกั้นเส้นทางดัดแปลงอื่น ๆ ได้ นอกจากนี้ ควรกำหนดการตั้งค่าไว้ในจุดที่มีผลก่อนการแปลความหมาย request เช่น php.ini, FPM pool หรือ server setting ไม่ใช่ ini_set() หรือ FPM .user.ini และต้องรีสตาร์ต worker ทั้งหมด การแก้ไขอย่างสมบูรณ์มีเพียงการติดตั้ง patch เท่านั้น

หากติดตั้ง patch เสร็จแล้ว สามารถใช้งานจริงได้ทันทีโดยไม่ต้องตรวจสอบเพิ่มเติมหรือไม่?

การอัปเดตช่วยป้องกันการโจมตีในอนาคตเท่านั้น ไม่ได้บอกว่าเคยถูกเจาะระบบแล้วหรือไม่ หลังอัปเดตเสร็จควรตรวจสอบประวัติการถูกเจาะระบบแยกต่างหากด้วย ควรตรวจสอบว่ามี PHP file ที่ถูกสร้างหรือแก้ไขผิดปกติเมื่อไม่นานมานี้ เช่น web shell ใน web directory หรือไม่ และตรวจสอบ web server access log กับ PHP error log ว่ามีบันทึกขนาดใหญ่ผิดปกติของ POST request หรือ memory error ซ้ำ ๆ หรือไม่

ควรรับมืออย่างไรในสภาพแวดล้อม container หรือ cloud image?

แม้จะอัปเดตแพ็กเกจบน host server แล้ว PHP runtime ที่อยู่ภายใน container จะไม่เปลี่ยนแปลงโดยอัตโนมัติ ดังนั้นต้องใช้ base image ที่มีเวอร์ชัน patch แล้ว (8.5.12, 8.4.27, 8.3.36, 8.2.35) เพื่อ build container image ใหม่และ deploy อีกครั้ง

แหล่งที่มา

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 (ภาษาเกาหลี)