PHP fixes two critical remote execution vulnerabilities in 8.5.12, 8.4.27, 8.3.36, and 8.2.35

The advisory that led the PHP Foundation to call for immediate updates

On October 21, 2026, the PHP Foundation published a security advisory describing two critical vulnerabilities that allow unauthenticated remote code execution (RCE). The fixes shipped in four versions simultaneously: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The security team's recommendation is direct: update immediately, without waiting for the next maintenance window.

The advisory classifies the risk as highest for installations running mod_php on Apache, where an exploit was demonstrated in which an unauthenticated request triggers the attack before any application code even runs. This means a WAF, the application's own authentication, or input validation in PHP code can't act in time to block the attack: the flaw happens at the interpreter layer, below your code.

The two flaws: mishandled memory release and contaminated global state

CVE-2026-109618 (RCE via out-of-memory corruption, GHSA-w8hw-w9fx-j79w): when PHP runs out of memory while processing a request, the error handling can interrupt the initialization of internal data midway through. During post-request cleanup, PHP treats this partially initialized data as valid, opening the door to arbitrary code execution.

CVE-2026-109619 (RCE via stale global state, GHSA-6wmf-4rv5-p3rp): internal state belonging to one request can survive after the memory backing it has already been freed. A PHP-FPM worker that handles multiple requests in sequence can, on a subsequent request, use this stale state before normal initialization clears it.

What the two flaws share is that they exploit the internal lifecycle of the PHP interpreter (memory allocation and release per request), not an application logic bug. That's why no fix at the framework or application code level solves it: the only complete solution is updating the PHP binary.

Who's exposed

The advisory lists every PHP installation that serves web requests as at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. In practice, that covers virtually any PHP stack in production, from WordPress on shared hosting to Laravel or Symfony APIs running behind Nginx with PHP-FPM.

For those who maintain infrastructure in Brazil, it's worth mapping three common scenarios:

• Shared hosting with cPanel: usually runs mod_php or php-cgi, exactly the highest-risk scenario cited in the advisory. The update depends on the hosting provider, so it's worth checking the control panel or opening a support ticket.
• VPS or dedicated server with PHP-FPM + Nginx: depends on the distribution's package (apt, dnf) or a manual build. If the server runs Ubuntu, Debian, RHEL, or Alma, the advisory confirms that Linux distributions and LTS vendors already received the patches before the public announcement.
• Docker containers: official images such as php:8.4-fpm or php:8.3-cli need to be rebuilt from an updated tag; simply restarting the container with the old image doesn't apply the patch.

How to update

The recommended path depends on how PHP got onto your server:

1. If you compile from source, download PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 from the project's official downloads page.
2. If you use Linux distribution packages (apt, dnf, yum) or an LTS vendor, check whether the package has already been updated, since those channels received the patches in advance.
3. If the project runs on PHP 8.1 or earlier, there's no more official update from the PHP project for those versions. Some distributions and LTS vendors maintain backports, so it's worth checking with the vendor, or planning a migration to a supported version.

One point that trips up a lot of people who run PHP servers in Brazil: those who depend on the rpms.remirepo.net repository, maintained by volunteers and widely used to get recent PHP versions on CentOS, RHEL, and Alma Linux, won't find the updates there on the day of the advisory. The recommendation is to migrate to the distribution's own packages or compile from source in the meantime.

For those still on PHP 7.4, 8.0, or 8.1, the PHP security team released minimal source-code backports, an exception given the severity of the case, for those who compile from scratch or don't have access to an LTS vendor.

If you can't update right now: mitigations, not a solution

The advisory itself is emphatic: the measures below reduce exposure to specific attack paths, but they don't make the installation secure. Only updating actually fixes it.

Two caveats from the advisory itself deserve attention. First, for the OOM flaw, using RLIMIT_AS or RLIMIT_DATA instead of a container limit can make the problem worse, because those limits can themselves cause the allocation failure that triggers the vulnerability. Second, for the stale-state flaw, hiding diagnostics with error_reporting, display_errors, or @ doesn't help at all: you need to fix the fatal errors reachable by an attacker, including failures in callbacks, upload or import processing, and execution timeouts.

What the advisory doesn't answer

The material doesn't detail a complete exploit or a public proof of concept, which is expected in a recently published advisory: the PHP Foundation typically releases full technical details (payload field, exact race condition) only after most of the production install base has already updated. The advisory also doesn't give a set timeline for when the linked GHSA advisories will bring those details, nor an estimate of how many installations remain vulnerable.

For teams running PHP in production, the practical action now is simple: check the running version (php -v), confirm whether the operating system package or Docker image has already been updated, and, until that happens, apply the mitigations from the table above knowing they're a stopgap, not a solution.