Anyone running a PHP website has an update to install today. On October 21 the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to close two critical vulnerabilities, each scored 9.2 of 10 under CVSS v4, that let an unauthenticated attacker run code on the web server. The release notes are blunt: no workaround is complete, and updating is the only safe option.
The more alarming of the pair, tracked as CVE-2026-109618, needs no account, no application bug and no victim interaction. The advisory confirms full remote code execution over ordinary web requests against Apache's mod_php module with PHP's default input and memory limits, and the attack lands while PHP is still parsing the request, before any application code runs.
A crash path that leaves memory half built
When a request runs out of memory, PHP uses the C function longjmp() to abandon it. In certain contexts the request's memory is reachable before it is fully initialized, and should an allocation fail at that moment, the abrupt exit leaves it in an invalid state. The shutdown routine then reads or branches on garbage. Several ways of forcing the condition lead to code execution, though reliability varies by build and allocator layout.
Multipart form parsing offers several ways to force a worker out of memory. A request that lacks a usable content length can slip past the post_max_size check and keep feeding decoded body data. Each part may carry an unlimited number of headers, and representing them inside PHP costs far more memory than they take on the wire, so a request that stays under post_max_size can still blow through memory_limit. All of it happens during automatic body parsing.
The project's at risk list covers every installation serving web requests, FPM, mod_php, the CGI binary, FrankenPHP and LiteSpeed alike, with mod_php rated highest. mod_php runs its shutdown routine no matter how startup ended, which is why the exploit against it is complete. FPM, the FastCGI process manager, kills the child when startup fails, which blocks that route, but source analysis still points to FPM being susceptible after startup; no working FPM exploit has been shown. FrankenPHP is thought likely to be exposed like mod_php, and LSAPI, the LiteSpeed interface, is modeled on FPM. Injected code runs as the web worker account; more workers or traffic only raise the number of attempts needed.
The second flaw lives between requests
The companion vulnerability, CVE-2026-109619, is subtler. A PHP worker keeps global state for errors, sessions, objects and extensions pointing into memory owned by a single request, and that state must be cleared before the request's memory is freed. A fatal error or memory exhaustion can cut an operation short before that reset happens, and a late warning during shutdown can repopulate state that was already cleared. The next request on the same worker can then consume the stale pointer before normal initialization replaces it: a use after free that a crafted heap layout turns into code execution.
Two paths are confirmed. In PHP 8.5, the fatal error backtrace feature, when enabled, stores request owned state that shutdown never resets, and this underpins the working mod_php exploit. That path needs a reader for the stale value: under mod_php, Apache's per directory configuration is applied before request startup, so a deprecated or invalid directive there supplies the early warning that consumes it; FPM is exposed when nginx or Apache's FastCGI proxy module passes PHP_VALUE parameters that do the same. Hiding them with error_reporting, display_errors or the @ operator does not help. The other path is session upload progress, on by default and needing no call to session_start or any diagnostic; it was validated against both mod_php and FPM, although the FPM variant depends on a suitable application operation after startup.
What administrators should do
Update first. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and Linux distributions were given the fixes ahead of time, so check for vendor packages. PHP 8.1 and older are normally out of support, but given the severity the security team has provided minimal source backports for 7.4, 8.0 and 8.1. PHP 8.2 itself leaves support on 31 December 2026.
For servers that cannot update today, the maintainers list partial measures, none complete. Against the memory exhaustion flaw, set memory_limit to minus one, meaning no limit, where applications cannot override it, for instance via php_admin_value in the pool or Apache configuration, restart every worker, and make sure nothing at pool, directory or application level restores a finite limit. An allocation can still fail at the operating system level and reach the same code. Set a low post_max_size, 8M where uploads are not needed and 32M where they are, enforce decoded request size, field, part and header counts and nesting depth at the proxy, and use a container or cgroup cap that kills just the affected worker as the availability backstop. Do not reach for RLIMIT_AS or RLIMIT_DATA, which make memory mapping calls fail and trigger the vulnerable path.
Against the stale state flaw, set session.upload_progress.enabled to 0 on every version and, on PHP 8.5, fatal_error_backtraces to 0, then restart every worker. These settings belong in php.ini, the pool or the server configuration, because ini_set and .user.ini apply too late, and they block only the confirmed paths. Remove deprecated or invalid directives applied per request, since their diagnostics are what trigger the confirmed route, and fix fatal errors and execution timeouts an attacker can reach. Where throughput allows, pm.max_requests set to 1 recycles each FPM worker after one request, making it far harder for the two requests to hit the same process.
The patch retires the longjmp() escape in favor of a delayed soft failure at the next safe point, with a hard exit only past a second, higher threshold. The release went out on the day announced in advance, and now that a working exploit against default mod_php settings is confirmed, the only window that matters is the one between reading the advisory and updating.
