PHP patches two critical RCE flaws across four branches after early disclosure

Two critical flaws, four patch releases

PHP shipped fixes on 21 October 2026 for a pair of unauthenticated remote code execution vulnerabilities, releasing versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 simultaneously. Both vulnerabilities score 9.2 on CVSS, and CISA refers to the pair as php2shell. According to the Netics report on dev.to, the release was originally planned for 22 October but was pulled forward after the coordinated disclosure began to fall apart roughly two days ahead of schedule.

How each bug works

The first issue, CVE-2026-109618, sits in how PHP handles out-of-memory conditions. When a request exceeds the configured memory_limit, PHP aborts it, but that abort can occur while internal request data is only partly set up, for example midway through parsing a form-based file upload. PHP can later treat that incomplete data as valid, which corrupts memory. The awkward part is that the trigger is a protective limit: the safeguard meant to stop a greedy script from exhausting the server becomes the entry point for the attack.

The second, CVE-2026-109619, involves state that outlives its memory. After a fatal error, internal data belonging to the failed request is freed, but references to it persist. The worker carries on serving, and the next request it handles can act on that leftover state before normal initialisation clears it. The PHP Foundation says a use-after-free and a worker crash were confirmed, and that the reporter demonstrated remote code execution against a real application running Apache with mod_php. Execution was also confirmed on PHP-FPM through application-level code paths.

Both flaws let an unauthenticated request end up running arbitrary code inside a PHP worker, with whatever permissions that worker already holds. Every setup that answers web requests is exposed, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP's own notice ranks mod_php as the highest risk, because in that configuration a demonstrated exploit runs before any application code executes, so application-side patches and firewall rules never see the attack. AWS, in its bulletin, described the impact as confined to the affected worker and its application permissions, with no cross-customer propagation established at the time.

A disclosure that unravelled

The timeline, as reconstructed by Netics: at around 15:00 UTC on 20 October the two CVE identifiers began circulating on forums and social media, attached to an incorrect 10.0 score (the real figure is 9.2) and a wrong release time. PHP responded with a pre-announcement at 19:30 UTC and moved the release forward by a day, reasoning that distributors were still packaging fixes and that an immediate release would leave users with no update path. Around 20:00 UTC, Calif, one of the reporting firms, accidentally published a proof-of-concept video that then spread. At 07:41 UTC on 21 October, more than six hours before the coordinated slot, Chainguard published built images containing the fix, letting anyone study the patch in binary form while other users waited. CERT-EU records the actual release at 13:30 UTC, half an hour before the announced 14:00 slot. PHP says it saw no functional exploit at the moment of release, a narrow claim covering a short window.

Patching and interim mitigations

The affected ranges are 8.5.0 to 8.5.11, 8.4.0 to 8.4.26, 8.3.0 to 8.3.35 and 8.2.0 to 8.2.34; anything older than 8.2 is out of support. AWS lists PHP 5.4 through 8.1 as having no upstream fix and requiring migration, though PHP published minimal source backports for 7.4, 8.0 and 8.1 for teams building from source. Distribution packages follow each distributor's own schedule, so managed servers can lag the upstream release. CERT-EU also points to third-party products that embed PHP without ever exposing it as an installable package, a category tracked in the NCSC-NL repository that standard inventories tend to miss.

Where updating must wait, PHP advises removing the attack's trigger: set memory_limit to -1 through php_admin_value, cap post_max_size at 8M where uploads are unnecessary or 32M where they are needed, keep upload_max_filesize below that, and enforce limits on decoded request size, field counts, multipart parts, headers and nesting depth at the web server or proxy. Those proxy rules matter as much as the memory change, since an unlimited memory limit means one careless request can consume the machine.

Why it matters

PHP runs a large share of the web, and these flaws sit in memory management and error handling code that nearly every request touches, reachable without credentials. The history of the memory bug is also a warning: the earliest signs came from a 2024 external audit, yet the full impact was only understood in August 2026, a gap the PHP Foundation attributes to structural problems in how its security team makes decisions and a chronic shortage of resources. The disclosure itself shows how fragile embargo coordination becomes once identifiers leak, since one vendor's early binary publication effectively shortened everyone else's window. And for operators, the buried task is finding embedded PHP inside appliances and third-party software, which no package-based inventory will surface on its own.