Two Critical PHP Bugs Leaked Early, and Four Branches Now Carry the Fix

TL;DR

• PHP is the scripting language that runs a large share of the web, and on 21 October 2026 two critical remote code execution vulnerabilities in it were fixed in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• The pair is known as php2shell, both identifiers score 9.2, and the bugs sit in memory management and error handling, code that nearly every request touches.
• The first bug interrupts a request at the memory limit and turns that interruption into code execution; the second leaves stale state in a worker that a later request reuses.
• The embargo broke about two days before the planned 22 October release: the CVE identifiers circulated at around 15:00 UTC on 20 October with a wrong 10.0 score, PHP moved its release forward by one day, and a distributor published fix images at 07:41 UTC on 21 October.
• Four versions carry the fix, released at 13:30 UTC on 21 October, and distribution packages follow on each distributor's own schedule.
• Where the update waits, PHP's own advice is to remove the memory limit through php_admin_value, lower post_max_size and enforce request limits at the proxy.
• The first signs of the memory bug surfaced during a 2024 external audit, its full impact became clear only in August 2026, and the PHP Foundation calls the delay a structural failure caused by the security team's decision process and its lack of resources.

What php2shell breaks

CISA calls the pair php2shell. Both vulnerabilities end in the same place, which is arbitrary code running inside a PHP worker with the permissions that worker already holds, reached by a request that carries no credentials at all. Every PHP installation that answers web requests is exposed, and that set includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

PHP's own notice ranks mod_php as the highest risk. Under mod_php a demonstrated exploit fires before any application code runs, so a framework patch, an application firewall rule inside the app, or a hardened CMS plugin never gets the chance to look at the request. AWS described the blast radius as bounded to the affected worker and its application permissions, with no cross-customer propagation established at the time of its bulletin, which is the reassuring half of the statement and also its limit.

A memory limit that turns into code execution

CVE-2026-109618 is remote code execution through out-of-memory handling. PHP enforces the memory_limit setting by aborting a request that exceeds it, and that abort can arrive while internal request data is only partially initialised, for example during the parsing of a form-based file upload. PHP can later treat that partially initialised data as valid, which corrupts memory.

The interesting part for anyone running shared hosting or a multi-tenant platform is that the trigger is a resource limit, where a limit normally exists to protect the server from a greedy script. Here the path that enforces it becomes the attack surface itself, which is why PHP's first mitigation for organisations that cannot update immediately is to remove the trigger by setting memory_limit to -1 through php_admin_value in the pool or the Apache configuration.

That mitigation buys time and carries its own cost. An unlimited memory limit on a PHP worker means one badly written request can consume the machine, so the second half of PHP's advice matters as much as the first: set post_max_size to 8M where uploads are unnecessary or 32M where they are needed, keep upload_max_filesize below it, and enforce decoded request size, field count, multipart part count, header count and nesting depth at the web server or the proxy.

Stale state in the same worker

CVE-2026-109619 is remote code execution through stale global state, and its shape is different. Internal state owned by one request survives after the memory behind it has been freed, which PHP names as happening after a fatal error. The worker that handled the failed request goes on to serve the next one, and that later request can use the stale state before normal initialisation resets it.

The PHP Foundation's post reports that a use-after-free and a worker crash were confirmed, and that the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php. The detail that matters operationally is the word worker: the Foundation writes that a later request handled by the same worker could then use the freed memory, and that remote code execution was also confirmed on PHP-FPM through application-level code paths.

The embargo broke two days early

Coordinated disclosure works on a timetable that distributors need in order to have packages ready on the day. Here the identifiers leaked about two days before the planned release date, and the release itself moved forward by one day. The PHP Foundation's account places the first break at around 15:00 UTC on 20 October, when the two CVE identifiers began circulating on forums and social media with a wrong release time and a wrong CVSS score of 10.0. The real score is 9.2.

The project responded by publishing its pre-announcement at 19:30 UTC and by moving the release from 22 October to 21 October at 14:00 UTC, because distributors were still packaging the fix and an immediate release would have left users without an update path. The second break followed right after the pre-announcement, when Calif, one of the reporting firms, published a proof-of-concept video by mistake at around 20:00 UTC on 20 October and copies spread on social media.

The third break came from inside the process: at 07:41 UTC on 21 October, more than six hours before the coordinated release, Chainguard published built images containing the fix. Anyone could study the fix in binary form while every other PHP user was still waiting. PHP monitored the proofs of concept that appeared and reported no functional exploit at the moment of release, which is a narrow statement covering a short window. The case for publishing minor vulnerabilities in the open is covered in a separate Netics article. Both policies share the same scarce input, which is a maintainer with enough hours to answer.

What to patch today, and the four versions that fix it

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released at 13:30 UTC on 21 October 2026 according to CERT-EU, half an hour before the 14:00 UTC slot the PHP Foundation had announced. 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. Distribution packages follow on each distributor's own schedule, so the package on a managed server can trail the upstream release, as the AWS timeline below shows.

PHP 8.1 and older sit outside every one of those ranges because the project stopped supporting them. AWS lists PHP 5.4 to 8.1 as having no upstream fix and requiring migration, and notes that its own Amazon Linux packages and WorkMail upgrade were targeted for 22 October while Elastic Beanstalk platform version v4.13.12 shipped on 21 October. PHP also published minimal source backports for 7.4, 8.0 and 8.1 for teams that build from source or have no access to a long-term support vendor.

CERT-EU points at one more category that inventories usually miss: third-party software that embeds PHP and never exposes it as a package, which the NCSC-NL repository tracks. That is the same problem CISA named in its alert, where PHP is often a component of other software and its prevalence may not be directly observable.

What to do when the update waits

Some systems cannot take an update the same day, and the interim advice is specific enough to act on. Removing the memory limit through php_admin_value closes the trigger for CVE-2026-109618, and PHP notes that an underlying allocation failure can still reach the vulnerable path, so the mitigation reduces exposure and the installation stays vulnerable until it is patched. PHP also recommends a container or cgroup limit as an availability boundary, and warns against substituting RLIMIT_AS or RLIMIT_DATA, which can cause the vulnerable allocation failure.

The second layer sits in front of PHP. A web application firewall may provide some protection until systems are updated, according to CISA, and PHP's own guidance pushes request limits to the server or the proxy. Both reduce the space an attacker has to work in until the patch is applied.

The third layer is detection, and it is the one that tells you whether the day went badly. CISA asks defenders to watch for PHP worker processes launching shells or downloading tools, which is a short rule to write into whatever monitoring already exists and a reliable signal that a worker crossed from parsing requests into running commands.

Why the engine fix shipped in October 2026

The disclosure history explains the delay better than any severity score. In 2024 PHP went through its first external security audit in years, funded by the Sovereign Tech Agency, organised through OSTIF and carried out by Quarkslab. While fixing one of the issues that audit reported, a core developer contracted by the PHP Foundation found the first signs of the out-of-memory problem. A potential exploit was theorised in 2024, no concrete vector was found at the time, and other issues with clearer impact took the attention.

The picture sharpened through 2026. On 11 August a researcher at Calif reported an unconditional remote code execution, and OpenAI independently reported the same root cause. Further attack vectors came from Wiz on 24 August and from OpenAI on 18 September, and from 11 August the fix became the team's top priority. The Foundation writes that the bugs were hard to fix without breaking compatibility, hurting performance or forcing changes on the large ecosystem of third-party extensions, and it calls the delay a structural failure caused by the security team's decision process and its lack of resources.

The volume is the part that shapes the next year. The security team has published 15 CVEs since 1 July and worked through more than 100 reports that turned out to be invalid, duplicates or not reproducible. AI tooling helps validate reports and group the ones that share a root cause, and a person still makes every call and writes every patch. For an operator the lesson is unglamorous: the runtime under a large share of the web rests on a small team of core developers, several of whom could work on this issue full time only because of Foundation funding, and the day the embargo breaks is a bad day to discover that nobody knows how many PHP installs the company runs.

Sources

Source: Today's PHP Security Release, and How We're Strengthening PHP Security — The PHP Foundation, thephp.foundation, 21 October 2026, retrieved 2026-10-21 (the two vulnerabilities, CVE-2026-109618 as remote code execution via out-of-memory corruption and CVE-2026-109619 as remote code execution via stale global state, both sitting in memory management and error handling; the identifiers circulating at around 15:00 UTC on 20 October with a wrong release time and a wrong CVSS score of 10.0 against an actual 9.2; the pre-announcement at 19:30 UTC; the release moved from 22 October 14:00 UTC to 21 October 14:00 UTC; Chainguard publishing built images containing the fix at 07:41 UTC on 21 October, more than six hours before the coordinated release; the 2024 audit funded by the Sovereign Tech Agency, organised through OSTIF and carried out by Quarkslab; the reports from Calif on 11 August, Wiz on 24 August and OpenAI, with further OpenAI vectors on 18 September, and the proof-of-concept video Calif published by mistake at around 20:00 UTC on 20 October; a use-after-free and worker crash confirmed for CVE-2026-109619, with remote code execution demonstrated against a real-world application running on Apache with mod_php; a later request handled by the same worker able to use the freed memory, and remote code execution also confirmed on PHP-FPM through application-level code paths; the fix described as hard to ship without breaking compatibility, hurting performance or forcing changes on third-party extensions; the delay described as a structural failure caused by the security team's decision process and its lack of resources; the small team of core developers, and Foundation funding that let multiple people work on the issue full time; the full impact becoming clear in August 2026; the proofs of concept monitored after the leak, with no functional exploit identified at release; fixing becoming the top priority from 11 August; 15 CVEs published since 1 July and more than 100 invalid, duplicate or non-reproducible reports).

Source: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 — php.net archive, 21 October 2026, retrieved 2026-10-21 (all PHP installations serving web requests at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed; the highest risk on mod_php with a demonstrated exploit reachable before any application code runs; memory_limit set to -1 through php_admin_value, post_max_size at 8M or 32M with upload_max_filesize kept below it, and request limits enforced at the web server or proxy on decoded request size, input field count, multipart part count, header count and nesting depth; PHP 8.1 and older no longer receiving updates; minimal source backports for PHP 7.4, 8.0 and 8.1 for people building from source or without access to a long-term support vendor).

Source: Critical Vulnerabilities in PHP Require Immediate Patching — CISA alert, cisa.gov, 21 October 2026, retrieved 2026-10-21 (the php2shell name; all PHP installations serving web requests affected; no exploitation observed as of publication; identify and inventory systems running any version of PHP, with PHP often a component of other software and prevalence not directly observable; a web application firewall may provide some protection until systems are updated; monitoring for PHP worker processes launching shells or downloading tools).

Source: Security Advisory 2026-018, Critical Vulnerabilities in PHP — CERT-EU, cert.europa.eu, version 1.1 of 21 October 2026, retrieved 2026-10-21 (fixes released at 13:30 UTC on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; both vulnerabilities at CVSS 9.2; the longjmp() path in the memory_limit handling and the interruption while internal request data is only partially initialised, for example when parsing a form-based file upload; stale global state surviving after its backing memory has been freed, for example after a fatal error; proofs of concept beginning to circulate; end-of-life branches without updates; the NCSC-NL repository of third-party software embedding PHP).

Source: PHP web runtimes (CVE-2026-109618 and CVE-2026-109619), bulletin 2026-143-AWS — AWS, aws.amazon.com, 21 October 2026, retrieved 2026-10-21 (affected ranges 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; PHP 5.4 to 8.1 with no upstream fix and requiring migration; the issue bounded to the affected worker and its application-level permissions with no cross-customer propagation established; Elastic Beanstalk platform version v4.13.12 released on 21 October with a follow-on release targeted for 22 October; Amazon WorkMail and Amazon Linux targeted for 22 October).

Source: the PHP Foundation account, the php.net release notice, the CISA alert, the CERT-EU advisory and the AWS bulletin, all of 21 October 2026 and all retrieved 2026-10-21 — every number, timestamp and version above traces to one of those five pages. Images are captures of the php.net release archive and the PHP Foundation post, plus two Netics editorial diagrams. Netics runs security audit and hardening engagements that start with the runtime inventory this release made urgent.