- ปักหมุดในสถิติ
- #1
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.
Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.
The vulnerabilities:
- RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
- RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
- Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our downloads page. Windows source and binaries are on the same page.
- Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
- PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
- If you rely on the volunteer-maintained rpms.remirepo.net, we urge you to switch to distribution packages or build from source, so you can immediately apply updates. The repo will not have updates today.
- Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
RCE via OOM corruption (CVE-2026-109618):
- Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
- Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
- Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.
- Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
- On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
- Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
- Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.
PHP 8.5.12, 8.4.27, 8.3.36 และ 8.2.35 ได้แก้ไขช่องโหว่ระดับวิกฤตสองรายการที่อาจอนุญาตให้มีการรันโค้ดจากระยะไกลโดยไม่ต้องผ่านการตรวจสอบสิทธิ์ (unauthenticated remote code execution) ขอแนะนำให้ผู้ใช้ PHP ทุกท่านอัปเดตทันที
ใครที่มีความเสี่ยง: การติดตั้ง PHP ทั้งหมดที่ให้บริการคำขอผ่านเว็บ รวมถึง PHP-FPM, Apache ที่มี mod_php, php-cgi, FrankenPHP และ LiteSpeed เราถือว่าความเสี่ยงสูงสุดอยู่ที่ mod_php โดยมีการสาธิตการโจมตีที่คำขอซึ่งไม่มีการตรวจสอบสิทธิ์สามารถกระตุ้นการโจมตีได้ก่อนที่โค้ดของแอปพลิเคชันจะทำงาน
ช่องโหว่ต่างๆ:
- RCE ผ่านความเสียหายของ OOM, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): การจัดการหน่วยความจำไม่เพียงพอ (out-of-memory) สามารถขัดจังหวะ PHP ในขณะที่ข้อมูลคำขอภายในถูกกำหนดค่าเพียงบางส่วนเท่านั้น จากนั้นการล้างข้อมูลคำขอ (Request cleanup) อาจถือว่าข้อมูลที่ไม่ถูกต้องนั้นเป็นข้อมูลที่ถูกต้อง
- RCE ผ่านสถานะโกลบอลที่ล้าสมัย, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): สถานะภายในที่เป็นของคำขอสามารถคงอยู่ได้หลังจากหน่วยความจำที่รองรับถูกคืนไปแล้ว (freed) คำขอในภายหลังที่ถูกจัดการโดยเวิร์กเกอร์ (worker) เดียวกันอาจใช้สถานะที่ล้าสมัยนั้นก่อนที่การเริ่มต้นระบบตามปกติจะรีเซ็ตมัน
- อัปเดตเป็น PHP 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 ดาวน์โหลดซอร์สโค้ดได้ที่ downloads page สำหรับซอร์สโค้ดและไฟล์ไบนารีของ Windows อยู่ที่ on the same page
- การแจกจ่าย Linux (Linux distributions) และผู้จำหน่าย LTS ได้รับแพตช์ล่วงหน้าแล้ว ดังนั้นโปรดตรวจสอบแพ็คเกจที่อัปเดตจากผู้จำหน่ายของคุณ
- PHP 8.1 และรุ่นเก่ากว่า จะไม่ได้รับการอัปเดตจากโปรเจกต์ PHP อีกต่อไป การแจกจ่ายบางรุ่นและผู้จำหน่าย LTS อาจมีการจัดทำแพตช์ย้อนหลัง (backported fixes) ให้ ดังนั้นโปรดติดต่อผู้จำหน่ายของคุณเพื่อขอรายละเอียด หรืออัปเกรดเป็นเวอร์ชันที่ยังได้รับการสนับสนุน
- หากคุณพึ่งพา rpms.remirepo.net ที่ดูแลโดยอาสาสมัคร เราขอแนะนำให้คุณเปลี่ยนไปใช้แพ็คเกจจากการแจกจ่ายหลักหรือสร้างจากซอร์สโค้ด เพื่อให้คุณสามารถใช้การอัปเดตได้ทันที โดยในวันนี้ที่เก็บข้อมูล (repo) ดังกล่าวจะยังไม่มีการอัปเดต
- เนื่องจากความรุนแรงของช่องโหว่เหล่านี้ ทีมรักษาความปลอดภัยของ PHP จึงได้จัดเตรียมการพอร์ตโค้ดย้อนหลัง (source-backports) ขั้นต่ำสำหรับ PHP 7.4, PHP 8.0, และ PHP 8.1 เพื่อช่วยเหลือผู้ที่สร้างจากซอร์สโค้ดหรือผู้ที่ไม่สามารถเข้าถึงผู้จำหน่าย LTS ได้
RCE ผ่านความเสียหายของ OOM (CVE-2026-109618):
- ตั้งค่า memory_limit=-1 โดยควรทำในลักษณะที่แอปพลิเคชันไม่สามารถเขียนทับได้ เช่น การใช้ php_admin_value ใน FPM pool หรือการตั้งค่า Apache และตรวจสอบว่าไม่มีการตั้งค่า pool, ไดเรกทอรี หรือแอปพลิเคชันใดๆ ที่กำหนดขีดจำกัดกลับมาอีก วิธีนี้จะช่วยขจัดความล้มเหลวของขีดจำกัดหน่วยความจำ PHP ที่ควบคุมได้ แต่ความล้มเหลวในการจัดสรรหน่วยความจำพื้นฐานก็ยังอาจเข้าสู่เส้นทางที่มีช่องโหว่ได้
- ตั้งค่า post_max_size ให้ต่ำ สำหรับแอปพลิเคชันที่ไม่จำเป็นต้องอัปโหลดไฟล์ ให้ตั้งค่า post_max_size = 8M หากจำเป็นต้องอัปโหลดไฟล์ ให้ตั้งค่า post_max_size = 32M และกำหนดให้ upload_max_filesize ต่ำกว่า post_max_size พิจารณาการบังคับใช้ขีดจำกัดที่ระดับเว็บเซิร์ฟเวอร์หรือพร็อกซีสำหรับขนาดคำขอที่ถอดรหัสแล้ว, จำนวนฟิลด์อินพุต, จำนวนส่วนของ multipart, จำนวนส่วนหัว (header count) และระดับความลึกในการซ้อนกัน (nesting depth) ขีดจำกัดเหล่านี้ต้องครอบคลุมถึงคำขอที่ไม่มี Content-Length ที่ใช้งานได้ด้วย
- ใช้ขีดจำกัดคอนเทนเนอร์หรือ cgroup เป็นขอบเขตความพร้อมใช้งาน โดยควรใช้นโยบายที่ระงับ (kill) เฉพาะเวิร์กเกอร์ที่ได้รับผลกระทบ ห้ามใช้ RLIMIT_AS หรือ RLIMIT_DATA ทดแทน เนื่องจากสิ่งเหล่านี้อาจทำให้เกิดความล้มเหลวในการจัดสรรหน่วยความจำที่มีช่องโหว่ได้
- ตั้งค่า session.upload_progress.enabled=0 และรีสตาร์ทเวิร์กเกอร์ทุกตัว ใช้ php.ini, FPM pool หรือการตั้งค่าเซิร์ฟเวอร์ที่ทำงานก่อนการวิเคราะห์คำขอ (request parsing) อย่าพึ่งพา ini_set() หรือ FPM .user.ini วิธีนี้จะบล็อกเส้นทางเซสชันที่ได้รับการยืนยันแล้ว แต่ไม่รวมถึงรูปแบบอื่นๆ
- สำหรับ PHP 8.5 ให้ตั้งค่า fatal_error_backtraces=0 และรีสตาร์ทเวิร์กเกอร์ทุกตัว วิธีนี้จะบล็อกเฉพาะเส้นทาง fatal backtrace ที่ได้รับการยืนยันแล้วเท่านั้น
- ลบการตั้งค่าที่ไม่ถูกต้องหรือถูกยกเลิกการใช้งานแล้ว (deprecated) ที่ใช้ต่อคำขอซึ่งมีการส่งการวินิจฉัย (diagnostics) ออกมาก่อนการเริ่มต้นระบบ การซ่อนการวินิจฉัยด้วย error_reporting, display_errors หรือ @ ไม่ได้ช่วยแก้ปัญหา
- แก้ไขข้อผิดพลาดร้ายแรง (fatal errors) และการหมดเวลาการทำงาน (execution timeouts) ที่ผู้โจมตีสามารถเข้าถึงได้ รวมถึงความล้มเหลวใน callbacks, การประมวลผลการอัปโหลดหรือนำเข้า และการล้างข้อมูล
