PHP2Shell fix is out, and Cisco Talos expects half of PHP to miss it

The PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October, fixing two critical flaws, CVE-2026-109618 and CVE-2026-109619, which researchers have nicknamed PHP2Shell and which can let an attacker run code on a web server without logging in. Both are rated 9.2 out of 10. The release came a day earlier than planned, after the flaw identifiers leaked, and the security firm watchTowr said it was already seeing exploitation attempts in the wild, although none had yet succeeded.

The security firm Huntress says PHP “quietly powers WordPress, Drupal, Joomla, and Magento sites, shared hosting platforms, control panels” and software that does not say it runs PHP at all. The Record reported that hundreds of websites went offline on the day, with Nintendo among the large companies that took services down.

The project’s own advisory puts the risk highest for Apache with mod_php, where “an unauthenticated request can trigger the attack before any application code runs”. It also states that there are no complete mitigations and that updating is the only safe choice.

For a mid-market company, a patch helps only where someone knows PHP is running and the version is still supported. For many companies the website, the online shop, the customer portal and the appliance in the comms room run PHP that no one in the business has listed, much of it on branches the project stopped fixing.

Ten weeks from report to release

The PHP Foundation published an unusually frank account on 21 October. It says the first signs of the memory-handling problem behind CVE-2026-109618 surfaced during PHP’s first external security audit in years, carried out in 2024. On 11 August a researcher at the security firm Calif reported an unconditional remote code execution flaw with the same root cause.

The foundation says its security team developed several competing fixes for the memory problem, each with trade-offs, and that the team, “operating on consensus, struggled to choose between these and feared the repercussions of shipping the wrong choice”. It calls the delay “a structural failure, caused by both the security team’s decision process and its lack of resources”. Decisions can now be made by majority, and leadership will be brought in sooner when a fix is stuck.

The foundation says Chainguard published built images containing the fix at 07:41 UTC on 21 October, before the coordinated release, which it says “disregarded weeks of work by many parties”. Dan Lorenc, Chainguard’s chief executive, told The Record his company had seen exploitation attempts the night before, and called the move “all of us working together to minimize risk for the industry”.

The PHP nobody has on a list

John Hammond, senior principal security researcher at Huntress, writes that when the flaw is in PHP itself, “the number of places you have to go looking to identify vulnerable PHP versions gets very big, very fast”. Huntress lists vendor appliances, control panels such as cPanel and Plesk, and Windows software that bundles PHP among the places it turns up, and says that on Linux most internet-facing PHP sits on web servers and shared hosting that are “not closely monitored”.

In a mid-market company, a marketing site built by an agency often sits on a hosting plan outside IT’s view. An online store may run on a Magento or WordPress install looked after by a contractor. A ticketing or HR tool may be a vendor’s appliance with PHP inside it. None of these appears on an inventory of office servers, and a patching rate reported to the board can look complete without them.

VirusTotal says that turning off the PHP version header conceals the version but leaves the flaw in place.

Out of support, out of scope

On 21 October VirusTotal counted about 5.1 million internet-facing IP addresses running PHP. Of the roughly 1.1 million that announce a version, about 272,000 run the supported 8.2 to 8.5 branches, while about 758,000 run end-of-life branches from 5.4 to 8.1 and a further 88,000 run PHP 5.2 or 5.3. VirusTotal stresses that these figures describe the internet-facing footprint, not confirmed vulnerable hosts.

Cisco Talos, working from open-source intelligence, estimates “a significant corpus of PHP systems that will not receive a patch (~50%)”. PHP 8.1 and older no longer receive updates from the project. Its security team did publish minimal source backports for 7.4, 8.0 and 8.1, but those help only organizations that compile PHP themselves; everyone else depends on a Linux distribution or a paid long-term support vendor.

The release notes for 8.2.35 state that PHP 8.2 reaches end of life on 31 December 2026 and will get no further security fixes after that date. A server updated to 8.2.35 on 21 October is on a branch with 10 weeks of support left.

The PHP Foundation has changed how its security team decides. The servers that carry the risk belong to everyone else, and on VirusTotal’s count most of those that disclose a version are running branches the project no longer fixes.