CVE-2026-109618: PHP RCE via OOM corruption (PHP2Shell)

PHP aborts a request that exceeds memory_limit with longjmp(), jumping straight out of whatever native code was running. The advisory says some request memory is reachable before it is fully initialized. If an allocation fails at that moment, the jump skips the rest of the setup, and request shutdown later reads or branches on fields that were never written. The allocation that fails does not have to be related to the memory that ends up corrupted.

The attacker needs only network access to a PHP endpoint. The advisory lists ways to reach out-of-memory while staying under the limits PHP appears to enforce:

• a multipart body with no usable declared length, which slips past the first post_max_size check
• an unlimited number of headers inside one multipart part, which costs far more memory inside PHP than on the wire
• empty file controls, which do not count toward max_file_uploads but still build file metadata arrays, multiplied by nested field names

On Apache mod_php, shutdown runs even when request startup fails, so PHP's automatic body parsing reaches the bug before the application sees the request; the reporters validated full RCE over HTTP with default settings. PHP-FPM exits the child when startup fails, which narrows the path, but out-of-memory after normal startup is still reachable and no complete FPM exploit is public. FrankenPHP runs shutdown unconditionally and is likely susceptible; LSAPI is modeled on FPM.

The result is a shell as the web worker account: database credentials, application secrets and model API keys in the environment are all in reach. Exploitation is noisy. Reliability depends on the build, extensions, frontend and allocator layout, and reports describe thousands of requests per success, which suits automated scanning.

All PHP branches before the October 21, 2026 releases: 8.2 below 8.2.35, 8.3 below 8.3.36, 8.4 below 8.4.27 and 8.5 below 8.5.12. The reporters say the mechanism reaches back to PHP 5.4. PHP 8.1 and older are end of life and get no official release; the PHP team published minimal source backport branches for 7.4, 8.0 and 8.1.

Check the runtime that serves web traffic, not only the CLI, and check distribution package versions, because distributions keep the old upstream number on backported builds:

php -v
php-fpm -v 2>/dev/null || php-fpm8.3 -v
dpkg -l 'php*' | awk '/^ii/{print $2, $3}'
rpm -qa 'php*' | sort

To see which SAPI a site runs, look for libapache2-mod-php or mod_php in the Apache modules, a php-fpm pool, or a FrankenPHP or lsphp binary.

Install PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or the matching patched distribution package, then restart every process that runs PHP. Apache mod_php needs a full restart; a graceful reload keeps old code in memory.

The patch removes longjmp() for out-of-memory. PHP now raises a soft out-of-memory error at the next VM safe point and calls _exit() if memory reaches a higher hard threshold, so shutdown never sees half-built state.

If you cannot update yet, the advisory gives partial steps only:

• set memory_limit=-1 with php_admin_value so no pool or directory setting restores a finite limit, and cap memory with a container or cgroup limit that kills only the worker
• never use RLIMIT_AS or RLIMIT_DATA, which make mmap() fail and trigger the vulnerable path
• lower post_max_size and max_input_nesting_level, cap parts, headers per part and uploads at the frontend, and block multipart/form-data where the application takes no uploads

After patching, restore a real memory_limit.

The advisory gives no indicators; responders (Wiz, Sansec, Patchstack, Huntress) describe these signs:

• multipart requests followed by "Allowed memory size exhausted" fatal errors or repeated HTTP 500 responses from the same client
• bursts of thousands of near-identical multipart POSTs
• unexplained PHP worker restarts or segmentation faults in the PHP-FPM or Apache error log
• web worker processes (apache2, httpd, php-fpm) spawning sh, bash, curl, wget or nc, and new files in the web root

Application logs may show little, because the attack runs below the application. Their absence does not prove a host is clean; if you saw the signs, rotate the secrets the server held.

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. PHP uses longjmp() to abort a request on out-of-memory errors; when an allocation fails while request memory is reachable but not fully initialized, request shutdown reads or branches on invalid state. An unauthenticated attacker can push a request into out-of-memory within apparent PHP limits (for example multipart requests without a usable declared length, unbounded headers per multipart part, or empty file controls with nested field names) and gain remote code execution as the web worker account. Apache mod_php is affected before any application code runs. Affected: PHP below 8.2.35, 8.3.x below 8.3.36, 8.4.x below 8.4.27 and 8.5.x below 8.5.12. Fixed in 8.2.35, 8.3.36, 8.4.27 and 8.5.12.