The critical PHP RCEs are out, with fixes for every supported branch

The release we flagged yesterday is out, and every bit as serious as the notice suggested. 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”, and the project says to update immediately. The pair is CVE-2026-109618, an out-of-memory corruption bug, and CVE-2026-109619, a stale-state bug. Both GitHub advisories are rated critical, and both list the same four patched versions, with the affected ranges running below each of them.

The two bugs

CVE-2026-109618 is “RCE via OOM corruption” in the advisory’s title, and the mechanism is a timing problem in PHP’s bookkeeping: “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.” A request that exhausts memory at the wrong moment leaves half-built structures that later cleanup trusts.

CVE-2026-109619 is “RCE via stale global state”: “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.” One request’s leftovers become the next one’s starting state on the same worker.

Neither needs an account. Both live in the engine underneath the application, which is why the fix is a PHP package, not an app update. Wiz Research, in its write-up, says “every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4”, and describes a memory-disclosure component alongside the code execution. That disclosure is the finders’ account; the advisory centers on the RCEs. Wiz also credits AI assistance, writing that “frontier AI models substantially reduced that barrier”, and its headline puts the exposure at “70% of the Internet”, which is the firm’s characterization, not a verified figure.

Who has to move first

The advisory’s risk statement is worth reading as written. It covers “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed”, and then singles one out: “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.”

That last clause is the operational point. On mod_php the attack can fire before any application code runs, which puts application-level defenses behind the engine, not in front; the web server and any proxy or edge control in front are what can act. The finders say they worked with Cloudflare, AWS, Akamai, Imperva and Fastly to prepare “customer guidance, detections and out-of-the-box mitigations” for those who cannot update immediately. FPM, php-cgi, FrankenPHP and LiteSpeed are exposed too; the difference is degree and applicable mitigations, not safety.

Updating

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads and Windows binaries are on the project’s downloads page. For packaged installs, “Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.” For PHP 8.1 and older there is no upstream fix: those branches “no longer receive updates from the PHP project”, though some distributions and LTS vendors backport, and the team published minimal source backports for 7.4, 8.0 and 8.1.

One caveat is explicit. 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.”

If you cannot patch today

PHP is direct about the limits of its workaround list: these measures “reduce exposure to specific attack paths but do not make an installation safe”, and “there are no complete mitigations, updating is the only safe choice.”

For CVE-2026-109618, the aim is to keep the out-of-memory condition out of reach. Set memory_limit=-1, preferably through php_admin_value in the FPM pool or Apache configuration so applications cannot override it, and check that no pool, directory or application setting puts a finite limit back. Keep post_max_size low, at 8M where uploads are not needed and 32M where they are, with upload_max_filesize below it. Enforce decoded request size, field count, multipart part count, header count and nesting depth at the web server or proxy, including for requests without a usable Content-Length. A container or cgroup limit helps as an availability boundary, ideally killing only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, because those can cause the vulnerable allocation failure themselves.

For CVE-2026-109619, set session.upload_progress.enabled=0 and restart every worker, through php.ini, an FPM pool or server configuration that applies before request parsing, not through ini_set() or .user.ini; that blocks the confirmed session paths, not every variant. On PHP 8.5, set fatal_error_backtraces=0 and restart every worker, which covers the confirmed fatal-backtrace path only. Remove invalid or deprecated per-request settings that emit diagnostics before initialization, since hiding them with error_reporting, display_errors or @ does not help, and fix attacker-reachable fatal errors and execution timeouts, including in callbacks and upload or import processing.

Patch first. The mitigation list is for the hours between reading this and getting the package onto the host, and on mod_php those hours matter most.

Sources: the PHP security advisory, the GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, and Wiz Research’s write-up.