CVE-2026-109618

Overview

PHP is a general-purpose scripting language used mostly for web development. It runs behind web servers through server APIs such as Apache mod_php and PHP-FPM, and powers content management systems and frameworks such as WordPress, Drupal, Moodle and Laravel.

A Remote Code Execution (RCE) vulnerability (CVE-2026-109618) has been identified in how PHP aborts a request when it runs out of memory, which allows an unauthenticated attacker to drive a request into an out-of-memory error at a point where request memory is not fully initialized, corrupt that memory, and execute code as the web server worker. The PHP project tracks this issue as GHSA-w8hw-w9fx-j79w.

Per MITRE CWE-755: The product does not handle or incorrectly handles an exceptional condition.

This issue affects all versions of PHP before 8.2.35, versions 8.3.0 through 8.3.35, versions 8.4.0 through 8.4.26, and versions 8.5.0 through 8.5.11, including End-of-Life release lines such as PHP 7.4, 8.0 and 8.1.

Details

Module Info

• Product: PHP
• Affected packages: php-src (PHP core)
• Affected versions: <8.2.35, >=8.3.0 <8.3.36, >=8.4.0 <8.4.27, >=8.5.0 <8.5.12
• GitHub repository: https://github.com/php/php-src
• Published packages: https://www.php.net/downloads
• Package manager: N/A
• Fixed in:
  • OSS PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12
  • ZendPHP through HeroDevs

Vulnerability Info

This Critical-severity vulnerability is found in PHP core in all versions before 8.2.35, 8.3.0 through 8.3.35, 8.4.0 through 8.4.26, and 8.5.0 through 8.5.11. The PHP project scores it 9.2 under CVSS 4.0 (CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N).

When a request exceeds memory_limit, PHP raises a fatal out-of-memory (OOM) error and uses longjmp() to leave the current code path and abort the request. Some code paths make request memory reachable before it is fully initialized. If any allocation fails at that moment, even one unrelated to that memory, the jump skips the rest of the initialization and leaves the memory in an invalid state. The request shutdown procedure then reads or branches on it.

An attacker can reach the OOM condition on purpose. The advisory describes several multipart form parsing behaviors that let a request exhaust memory while staying within its apparent limits:

• A multipart request without a usable declared content length can pass the initial post_max_size check and keep supplying body data.
• A single multipart part can carry an unlimited number of headers, and PHP's internal representation of them uses much more memory than their size on the wire.
• Empty file controls do not count toward max_file_uploads but still create file metadata arrays, and nested field names multiply that work.

Applications can also expose OOM in their own ways, whenever attacker-controlled input leads to a large allocation or repeated memory use.

Exposure depends on the server API. Apache mod_php always runs request shutdown, even when request startup failed, so automatic body parsing can exhaust memory and shutdown processes the invalid state before any application code runs. The advisory confirms unauthenticated remote code execution over HTTP against mod_php with default PHP input and memory limits. PHP-FPM ends the worker process when startup fails, which blocks that path, but an OOM later in the request can still leave invalid state for shutdown; FPM is assessed as susceptible by source analysis, without a complete demonstrated exploit. FrankenPHP calls shutdown unconditionally like mod_php and is likely susceptible, and LSAPI behaves like FPM. Code runs with the privileges of the web server worker account, and reliability depends on the PHP build, extensions, frontend and memory allocator layout.

The fix removes longjmp() from OOM handling. A request that crosses memory_limit now gets a delayed soft OOM that is raised at the next safe point in the virtual machine, and an immediate hard OOM that calls _exit() if memory use reaches a second, higher threshold. Request shutdown no longer sees partly initialized memory, and PHP keeps its ability to limit memory use.

Mitigation

The PHP project states that updating to a release containing the patch is the only complete mitigation. PHP 7.4, 8.0 and 8.1 are End-of-Life and do not receive community security updates.

Until an upgrade is possible, the advisory's primary configuration mitigation is to set and enforce memory_limit=-1 administratively and restart every PHP worker, confirming that no pool, directory or application setting restores a finite limit. This removes the predictable per-request limit the confirmed exploit relies on, but it is not complete: if mmap() or another underlying allocation fails, PHP can still take the vulnerable path. Do not use RLIMIT_AS or RLIMIT_DATA, which make allocations fail at the limit and trigger it.

Keep post_max_size conservative, enforce the decoded request size at the frontend, lower max_input_nesting_level, and limit the number of input variables, multipart parts, headers per part and uploads. If the application does not accept multipart form data, block it at the frontend. Also apply the mitigations for the related advisory, GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).

Users of the affected components should apply one of the following mitigations:

• Upgrade to PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12, or later.
• Leverage a commercial support partner like ZendPHP through HeroDevs for post-EOL security support.

Credits

• lcfr-hax (finder)
• sagitzadik-wiz (finder)
• tomash-areion (finder)
• amyb-oai (finder)
• arnaud-lb (remediation)
• iluuu1994 (remediation)
• bukka (remediation)
• ndossche (remediation)