A pair of decade-old bugs in the language behind most of the web, found by AI and leaked before the fix was ready, has triggered one of the internet’s largest precautionary shutdowns.
For two days this week, parts of the internet went dark on purpose. Government departments in Britain, Germany, France, and Finland switched off their own websites, Japanese banks suspended online services, and the US National Security Agency told any organisation that could not patch at once to take its servers offline.
The trigger was a pair of flaws in PHP, the programming language that quietly runs most of the web.
The vulnerabilities, dubbed PHP2Shell, let an attacker take control of a web server without a password. They had sat in PHP’s code for more than a decade, were uncovered with the help of AI, and leaked before the fix was ready, which meant attacks were already underway by the time the patch arrived. With PHP behind 69.3% of websites whose server-side language is known, the exposure stretches from national government portals to the smallest WordPress shop.
The fix is now out, but for most organisations the harder work has only started. Here is what happened, who is most at risk, and why installing an update will not be enough.
-
The flaws let attackers take over servers without logging in
The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, can allow unauthenticated remote code execution and each carries a CVSS v4.0 score of 9.2. Both stem from how PHP handles memory and internal request state, according to an analysis by Saeed Abbasi, head of the Threat Research Unit at Qualys. In the first, an out-of-memory error leaves request data half-built, and PHP’s cleanup routines then process that broken state, opening a path to code execution.
In the second, PHP keeps references to request data after the memory behind it has been freed, so a later request on the same worker can hit those stale references before they are reset. Because the problem sits in the PHP interpreter itself rather than any single application, sites built on WordPress, Drupal, Magento, Joomla or Laravel are exposed if they run a vulnerable version.
-
Some servers are more exposed than others, and data can leak too
PHP lists PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as at risk, though how exploitable each one is depends on configuration and application behaviour. Qualys singles out Apache mod_php as the priority, since PHP has demonstrated an exploit there that can fire before any application code runs. PHP-FPM is not off the hook: its startup behaviour blocks one out-of-memory route, but PHP has validated code execution against FPM through the session lifecycle under suitable conditions.
Researchers have also shown that attackers can read PHP worker memory without logging in, and that memory can hold passwords, authentication tokens and API keys. That widens the risk from a server takeover to quiet credential theft.
-
The scale of exposure is enormous, and much of it sits on old software
Estimates of how many systems are at risk vary widely depending on what is being counted, but every one of them is large. Palo Alto Networks said it had identified more than 22.6 million exposed instances, a count that includes servers, databases and applications, with its chief product and technology officer describing the exposure as massive.
Narrower counts of internet-facing hosts are still striking: researchers estimated more than 1.3 million could be vulnerable, and a Shodan search found about 1.9 million. Calif, one of the firms that found the bugs, said it confirmed pre-authentication code execution against specific versions of WordPress, Drupal, Joomla and Magento, and traced the earliest affected code back to PHP 5.4.0.
Part of what makes the exposure so hard to measure is that PHP often runs out of sight; security firm Huntress pointed out that it sits inside software that never advertises using it.
The long tail of outdated installs makes matters worse. Even before this week, PHP 7.4, which stopped receiving updates in 2022, was still running on 16.7% of WordPress sites reporting to WordPress.org.
-
Governments chose to go dark rather than risk it
The response from the public sector was unusually blunt. In the UK, 32 government services were unavailable and four partially unavailable, a minister told the House of Lords, with the Office for Budget Responsibility among those offline just before next week’s Budget. Germany’s federal IT provider ITZBund removed several websites as a precaution and said no security incidents were known, while France’s Interior Ministry took down prefecture websites until a patch was available.
The Czech government took its site down on the advice of its cyber watchdog, Finland’s state IT centre Valtori shut public services despite finding no exploitation attempts, and Belgium’s foreign ministry pulled its sites even though the national cybersecurity centre had recorded no attacks. In Berlin, the Charité hospital took its websites fully offline and the city portal berlin.de partly shut down.
Australia’s own cybersecurity agency website, cyber.gov.au, was among those affected, and in Nepal, sites linked to the President’s and Prime Minister’s offices went down. The private sector followed: Mizuho, Shizuoka Bank and Mitsubishi UFJ companies in Japan halted some online services, and Orange suspended access to some of its websites and apps. Every government shutdown reported so far has been described as precautionary.
-
Attacks started before the fix was public
The window defenders normally rely on never opened. Cloudflare CEO Matthew Prince said his company saw thousands of exploitation attempts 10 hours before the announcement, rising to hundreds of thousands within two hours and millions afterwards. Amazon’s threat intelligence team said it detected an exploit attempt on 17 October, four days before disclosure, from an IP address linked to a commercial anonymisation network, and it remains unclear how the attacker obtained the information.
Security firm watchTowr, which had seen nothing earlier in the day, reported active exploitation attempts against both flaws minutes after the release, and code claiming to exploit PHP2Shell on any server had already appeared on GitHub.
Qualys notes that Cloudflare has also seen attackers trying to evade its protections, and that Patchstack has received exploitation reports from hosting partners. How much of this has turned into real breaches is still unclear.
CISA said it had not observed exploitation at the time of its alert, and researchers told CyberScoop most activity looked like reconnaissance. NCC Group’s Matt Hull warned that vulnerable systems may already have been compromised, including through backdoors, which is why the UK’s National Cyber Security Centre has urged organisations to check for them after patching.
-
A row has broken out over who broke the embargo
PHP had planned a tightly coordinated release, sharing fixes in advance with distributors so their users could update the moment details went public, with an embargo set for 22 October at 14:00 UTC. That plan held until 20 October, when the two CVE identifiers began circulating online through an anonymous Hacker News post that also wrongly claimed a maximum severity score. PHP responded by publishing an advance notice that evening and bringing the release forward by a day.
The Foundation then accused security firm Chainguard of publishing built images containing the fix at 07:41 UTC on 21 October, roughly six hours before the agreed time, saying it disregarded weeks of coordinated work and gave attackers a patch to study. Chainguard CEO Dan Lorenc responded that the decision followed disclosure guidelines, citing how easily his team built an exploit independently and evidence of attacks already under way.
Calif also mistakenly published a video showing a proof-of-concept exploit, which was deleted but had already spread on social media. Analyst Frank Dickson of Dickson Research said Chainguard acted too soon but that the race had already begun, while Beauceron Security CEO David Shipley noted that the more people who know a secret, and the longer they hold it, the more likely it leaks.
-
AI found the bugs, and AI is shrinking the time to patch
The flaws came to light after the PHP Foundation joined OpenAI’s Patch the Planet programme, which gave AI tools to researchers hunting for and fixing PHP flaws. Researchers from Calif, OpenAI and Wiz made the full impact clear from late July, after the bugs had gone unnoticed for over a decade. A Foundation contractor had in fact spotted early signs of the memory problem during a 2024 audit, but no concrete attack route was found and other issues took priority.
Wiz has described the findings as the most severe vulnerabilities AI has ever discovered, and said frontier models let its team build and adapt working exploits across several applications in hours. It also said a single researcher completed in a week what would previously have taken a world-class team months. That speed cuts both ways.
Shipley warned that with AI agents and a little knowledge of how a flaw works, anyone can point a tool at software and work out the exploit, which is exactly why a leaked CVE number now carries far more risk than it once did.
-
Installing the patch is not the same as being safe
Fixed releases are out as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Qualys cautions that distribution-managed installs may carry the fix under an older version number, so teams should check vendor advisories rather than version strings. PHP 8.1 and earlier sit outside regular support, with only limited source backports for 7.4, 8.0 and 8.1, so those users need a fixed build from their vendor, the backport, or an upgrade. Qualys’ bigger warning is about verification.
The version a command-line check reports may belong to a different installation from the one actually serving web pages, and parallel PHP branches, containers, hosting panels and PHP bundled inside appliances can all be missed. After updating, every worker needs restarting or redeploying, and teams should confirm nothing is still running the old build.
PHP has published temporary mitigations, such as disabling session upload progress and tightening request limits, but Qualys stresses they only close specific attack paths. As its advisory puts it, “updating is the only complete fix.” Where a patched build cannot go in quickly, the firm advises restricting public access or isolating the service, with a named owner and deadline for each system still waiting.
What it means
PHP2Shell is already being compared to Log4j, and Shipley expects its effects to be felt for years as it works its way from the largest websites down to IoT devices and other connected hardware. The immediate risk is not only unpatched servers but forgotten ones: a second copy of PHP inside a container, a hosting panel or a vendor appliance that nobody thought to check.
Organisations that cannot say where every PHP runtime in their estate lives will struggle to say with confidence that they are safe, which is why Shipley calls an accurate software inventory the unglamorous grunt work that can make or break a response.
The episode also exposes how fragile the old rhythm of disclosure has become. Even a carefully coordinated embargo, with patches shared quietly with distributors in advance, unravelled within hours once the CVE numbers leaked. Dickson argues embargoes are still worth keeping, but that security leaders should now plan for exploitation to begin before an advisory is published, because in this case it did.
His practical advice is to decide in advance who has the authority to take a service offline, so that call is made calmly rather than argued over in a crisis, and to invest in detection based on suspicious behaviour, such as unexpected processes or new files on a web server, since no signature for a specific flaw exists on day zero.
The deeper shift is that AI has made both finding and exploiting bugs faster. The same tools that surfaced a decade-old flaw in weeks can help attackers turn a leaked hint into a working exploit in hours, compressing the window defenders once relied on.
For a language as widely deployed as PHP, that changes the economics of maintenance: running an old version is no longer a slow-burning risk but an immediate one. With PHP 8.2 reaching end of life on 31 December 2026, the businesses that treat this week as a one-off scramble rather than a prompt to clean up their stack are likely to be the ones caught out next time.
