Why governments and companies on four continents switched off their websites over PHP2Shell

When the Netherlands' DigiD login service, Finland's public government websites and Australia's cyber.gov.au stopped answering on Wednesday 21 October 2026, no attacker was responsible. Their operators had taken them down, as France's Interior Ministry did with its prefecture websites, mostly hours before the PHP project shipped fixes for two critical flaws now known as PHP2Shell. Japan's National Tax Agency followed the next morning.

Governments and companies on four continents cutting off their citizens and customers at the same moment, as a precaution and often on the advice of their cyber security agencies, is what sets PHP2Shell apart from other critical vulnerabilities. How it unfolded also reflects changes in the way software flaws are found, disclosed and fixed.

What is PHP2Shell, and why did it cause so much alarm?

PHP2Shell covers two vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, each scored 9.2 under CVSS v4.0. They let an attacker run code without credentials and read server memory, which can hold other users' passwords, session tokens and API keys, as The Hacker News sets out. Because the weakness sits in the engine, a well-maintained site is just as exposed as a neglected one if it runs an affected build.

Scale did the rest. PHP powers 69.3% of websites whose server-side language is known, according to W3Techs figures cited by Tenable. Palo Alto Networks estimated more than 22.6 million exposed and potentially vulnerable instances, TechTarget reported, although other server counts are far lower. Tenable cites estimates of 1.3 to 1.9 million, and CybelAngel puts hosts advertising PHP at 2.24 million. Nearly every release since PHP 5.4 is affected, and only the 8.2 to 8.5 branches have official fixed versions (8.2.35, 8.3.36, 8.4.27 and 8.5.12); 7.4, 8.0 and 8.1 get source backports only.

Timing piled on the pressure. The CVE identifiers leaked on 20 October, PHP brought its release forward by a day, and patches landed shortly before 14:00 UTC on the 21st. By then attempts had already begun: Amazon Threat Intelligence logged the first one on its honeypots on 17 October, four days before the fix, although it cannot say whether any would have worked against production systems.

Who switched off their services on 21 and 22 October?

Several agencies advised at once that anything that could not be updated should be disconnected. They included the UK NCSC, CERT-EU, INCIBE-CERT, Spain's CCN-CERT and, in the United States, CISA and the NSA. A Reuters factbox, in its version updated on 22 October, and national press reports show who switched off what. Almost all the organisations listed presented the move as preventive, and Belgium's foreign ministry also cited reports of cyber attacks, although Belgium's cyber security centre had recorded no attacks.

The table is only a sample. Many more administrations, companies and other organisations went offline, and The Record counted hundreds of sites down that Wednesday.

In the UK, the Office for Budget Responsibility withdrew its websites days before the Budget, and peers cited disruption at the DVLA, police services and councils including Edinburgh, Oxford and Bristol, The Register reported. On the Thursday, NL Times found the RIVM public health institute, the police's anonymous crime tip line and several branches of the domestic abuse service Veilig Thuis still without a website.

A spokesperson for Australia's Home Affairs Minister, Tony Burke, told the ABC, as iTWire reported, that "some websites are temporarily unavailable as work is undertaken to mitigate risks arising from this vulnerability". In Canada, minister Evan Solomon said some Government of Canada sites had been taken offline as a precaution on the guidance of the Canadian Centre for Cyber Security, according to BetaKit.

Spain stayed largely out of the spotlight. Escudo Digital reported no large-scale blackout of the main ministry portals, although some local authorities, research bodies and universities ran overnight maintenance windows. INCIBE-CERT rated the issue critical on 21 October and advised isolating from public networks anything that could not be updated, and CCN-CERT asked for PHP applications to be updated urgently or non-essential services disconnected.

How big was the impact?

UptimeRobot, which monitors availability for its customers' websites, saw roughly 37,000 downtime alerts per minute at the peak on 21 October, about eleven times the usual rate and twenty times in Europe. Among the sites it monitors, unreachable .nl domains climbed from 4,356 to 14,682 in a day, and .de domains from 8,660 to 18,422. The curve began rising before the patch, in the European late morning, and at 09:00 UTC on the 22nd alerts were still about 30% above normal.

No confirmed compromise of a major public administration has come to light. The UK tech minister, Baroness Lloyd of Effra, said she was not aware of any compromise of central government systems, the Dutch NCSC saw no active exploitation in the Netherlands and Valtori had not found any attempts in Finland. Attackers were busy all the same. Cloudflare went from thousands of attempts in the hours before disclosure to millions afterwards, according to The Register.

watchTowr's head of threat intelligence, Jake Knott, told The Record on 21 October: "Whilst nobody has been successful to date, we don't expect that will last long." The next day VulnCheck announced an exploit, available only to its customers, that defeats ASLR on x86-64 servers running PHP's recommended production configuration, according to The Register. As of 22 October, CISA had not added the flaws to its Known Exploited Vulnerabilities (KEV) catalogue.

So the blackout's cost fell mainly on service, with paperwork that could not be filed, warnings of payroll disruption at one or more HR software providers and helplines without a website for hours. That price was accepted to avoid a mass compromise with credentials scraped from server memory. So far there is no sign the caution was misplaced, and attacks on unpatched servers are likely to continue for weeks.

What does PHP2Shell reveal about where technology stands?

How did AI speed up discovery and exploitation?

According to the PHP Foundation, Calif and OpenAI independently reported the same root cause on 11 August, and Wiz Research found the first of the flaws independently on 19 August using Google and OpenAI models. Wiz credits those models with much of the exploit development and says one researcher did in a week what would have taken a world-class team months.

OpenAI says it led a coalition for two months to prepare fixes ahead of disclosure, and acknowledged, according to The Record, that AI "can also help attackers exploit" the flaws. The UK's NCSC, the minister told the Lords, had been briefed by OpenAI the week before.

Why did coordinated disclosure break down?

The more parties know about a flaw, the harder an embargo is to hold. The identifiers leaked two days before the planned disclosure date, a video of the exploit chain appeared online, and a container image vendor published patched builds roughly six hours before the agreed time, The Hacker News reports. In Amazon's view, defenders should not assume the disclosure date is the earliest exploitation date.

Why do patch deadlines fall short?

Amazon writes that, in patch management, a 7-day or 30-day SLA assumes a grace period that has disappeared. CISA's BOD 26-04 had already set a three-day deadline for KEV-listed flaws that grant full control of a system, and even that falls short for a flaw attacked before it is published, which as of 23 October had yet to enter that catalogue.

Why does open source rest on such small teams?

A core developer spotted signs of the memory flaw in 2024 while fixing another issue from PHP's external audit, but no exploit path was found at the time and competing fix proposals then stalled for months. The PHP Foundation has called that a "structural failure", pinning it on the security team's decision-making and lack of resources. Much of the world's web depends on a handful of people maintaining the engine, and that dependency seldom appears in a contract.

What should organisations review after patching?

Patching web servers comes first, and for many it is already done. At Hard2bit we updated our own systems and our clients' on Wednesday 21 October, the day the fixes were published. What remains is harder to see.

• PHP embedded in devices that are not web servers needs a separate review. Palo Alto Networks has confirmed that the management interface of specific PAN-OS releases in the 10.2 to 12.2 branches is affected, as is that of Panorama and the WildFire WF-500 appliances. PAN-OS hotfixes are expected between 26 and 30 October, and Panorama and WF-500 have no date yet. As of 22 October, Help Net Security reported that Fortinet was checking 12 products and Cisco 31 products and cloud services, with no vulnerable product confirmed.
• The Dutch NCSC keeps a list on GitHub of products that embed PHP, and an attack surface management review helps find consoles, embedded kit and legacy portals running PHP.
• Branches 7.4, 8.0 and 8.1 have no official releases, but the PHP security team published source backports and some distributions and LTS vendors ship backported fixes. For anything older than 7.4 the project publishes no fix, and 8.2 reaches end of life on 31 December 2026. Where no patch applies and migration is not possible, isolation is the safest option.
• Traces from 17 October onwards need reviewing. Amazon advises looking for POST requests containing PHP_SESSION_UPLOAD_PROGRESS, unexpected processes and modified files on web servers, and Wiz adds unusual multipart requests followed by memory-limit errors or repeated 500 responses. Any sign of tampering makes it an incident response case, including rotation of secrets that sat in memory, because, as with NetScaler, the patch does not remove anything an intruder planted beforehand.
• Suppliers that run PHP on systems holding your data count too. Ask them for written confirmation of patching and log review as part of third-party risk management.

The WAF rules that Cloudflare and AWS, among others, released bought hours, yet they only cover traffic routed through them, and attackers are already reshaping payloads to slip past.

Which controls still hold, and which have expired?

The basics remain valid with a new demand for speed. They include a reliable inventory of where each component runs, including whatever ships inside a purchased appliance, a vulnerability management programme that ranks by exposure and exploitation as well as CVSS, and logs kept long enough to look back and investigate. What has expired is patch deadlines measured in weeks for internet-facing systems, the belief that a WAF can replace a patch, and the assumption that risk begins on advisory day.

A new control takes their place. Disconnecting used to be a reaction to an incident, and on 21 October agencies in several countries recommended it as a precaution. "If you can't patch it, protect it. If you can't upgrade it, pull it down," said Tenable's Gavin Millard, as quoted by iTWire. To work, the shutdown has to be pre-authorised, and knowing in advance which services can be switched off, who makes that call, how customers and citizens are told and how everything is brought back belongs in the business continuity plan and the incident response plan.

If AI can surface in a week what once took months, the next PHP2Shell may arrive with less warning, or with no embargo at all. Nobody yet knows whether defenders, armed with the same models, can shorten their own timelines at the same pace. What every board can do now is put in writing, before the next Wednesday like this one, which services may be switched off without asking anyone and which may not.

Sources and attribution: an analysis built on public statements reported by the linked outlets and on advisories from PHP, Amazon, Palo Alto Networks and agencies such as INCIBE-CERT, using information available on 23 October 2026. It contains no exploit code. Taking a service offline, in the cases cited, does not imply that the organisation's systems were compromised or that its products or services were at fault. Exploitation and exposure figures come from third parties (Amazon, Cloudflare, Palo Alto Networks, UptimeRobot), and versions, patch status and scope may change.