On Wednesday, October 21, a lot of websites that people rely on simply stopped loading. There was no outage in the traditional sense, no failed data center or cut cable. Operators switched the sites off on purpose.
Government websites across Europe went dark as operators raced to patch two critical vulnerabilities in PHP, one of the most widely used programming languages on the web. It was one of the largest precautionary shutdowns of public-sector web services in recent memory. globalbankingandfinance
This post covers what happened, why governments chose to go offline rather than wait, what the episode says about modern web infrastructure, and what it means for your own site. If you want the technical anatomy of the flaws and a patching checklist, my earlier post on PHP2Shell covers those. This one is about the scramble.
The day the sites went quiet
The shutdowns came in waves across several countries.
The Netherlands. The Dutch cybersecurity agency took itself offline as a precaution. Others followed its lead. Organizations that took public-facing websites down included the Port of Rotterdam, the government portal Overheid.nl, the national soccer association KNVB, the websites of the country’s five largest political parties, and several hospital websites. U.S. News & World Reportkfgo
Finland. Disruption was even more widespread in Finland, where the state IT services provider Valtori said government public network services had been taken offline as a precautionary measure. U.S. News & World Report
France. The Interior Ministry placed all of its websites into preventive maintenance. Reporting also said it temporarily took local government administrative websites offline while waiting for a security fix. U.S. News & World Reportkfgo
Beyond Europe. Australia was among the countries that took services offline temporarily to apply a protective patch. The shutdowns weren’t limited to one continent, even if Europe’s were the most visible. thenationalnews
For ordinary people, this meant a morning of “this site can’t be reached” messages on pages they’d expect to work, from municipal services to hospital information pages and even political party sites.
Why switch off a website instead of waiting?
This is the question most people asked. Taking a government website offline is disruptive, so the decision wasn’t made lightly. Several factors pushed operators toward it.
1. The flaws allow remote code execution without logging in
Both vulnerabilities allow unauthenticated remote code execution, which means attackers could remotely control affected servers. A site with this kind of flaw isn’t just at risk of defacement. An attacker who runs code on a government server could try to steal data, plant persistent backdoors, or use the machine as a launch point into internal networks. globalbankingandfinance
2. There was no patch yet when the warnings began
This is the critical timing detail. The first shutdowns happened ahead of the fix, with reports that hackers were already exploiting the flaws to break into websites. When a vulnerability is leaked or disclosed before a patch exists, defenders have only bad options: wait exposed, or go dark. kfgo
The leak made it worse. Security researchers said details of the two vulnerabilities leaked online on October 20, before the coordinated disclosure and before patches were released. The official fix landed on October 21, but the shutdowns started while many operators still had nothing to install. huntress
3. Official guidance explicitly allowed it
Governments weren’t improvising. Cybersecurity agencies in Europe, Australia, Japan and Britain urged PHP users to update immediately or take websites offline until patches could be applied. CERT-EU’s advice was similar: organizations unable to patch quickly were told to take websites offline rather than risk exposure to critical threats. kfgoglobalbankingandfinance
4. The “blast radius” was enormous
PHP is everywhere. According to the web technology tracker W3Techs, PHP runs roughly 75% of the websites whose programming language can be identified. That’s why a flaw in the language itself is so much more worrying than a flaw in one plugin. One researcher at a security firm put it bluntly, saying “This is about as broad as a critical vulnerability gets.” U.S. News & World Reportthenationalnews
Even WordPress users weren’t exempt. Wordfence noted that all WordPress sites run on a server with PHP installed. kfgo
5. For many public bodies, offline is the lower-risk choice
Consider the trade-off from an agency’s point of view. A site that’s down for a few hours is an inconvenience, and most critical public services have phone lines, offices and alternative channels. A site that’s compromised can lead to a data breach, a loss of public trust, or a foothold for a more serious intrusion. When the odds of exploitation look high and the downside is that severe, switching off is the cautious, defensible call.
A timeline of the day
Pulling together the published accounts, the sequence looks roughly like this:
- October 20: Details of the flaws leak ahead of schedule.
- Early October 21: Cloudflare reports early attacks at 07:43. Government agencies start pulling sites offline. sansec
- Midday: European agencies publicly urge operators to patch or go offline.
- 14:00 UTC: PHP releases the fixed versions, and the researchers and PHP disclose publicly. sansec
- Wednesday afternoon: The US Cybersecurity and Infrastructure Security Agency (CISA) urges organizations to install the patch quickly. thenationalnews
The patched releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP isn’t releasing fixes for 8.1 or earlier, which have reached end of life. google
An unusual detail: AI helped find the flaws
One notable part of this story is how the bugs were found. Reuters framed the story as an AI-discovered flaw. OpenAI said it helped researchers discover the vulnerabilities. Wiz, one of the security firms credited with the disclosure, said it used a mix of models to identify and help remediate the flaws. Government Websites Go Dark After AI-Discovered Flaw Sparks Security Scramble +2
The details of how much AI contributed versus human researchers are still emerging, so treat the more dramatic headlines with some care. What is clear is that AI-assisted vulnerability research is now finding serious bugs in foundational software, including code that has sat in widely used projects for years. That cuts both ways. Defenders get faster discovery, but the same techniques will be available to attackers, and the gap between “bug found” and “bug exploited” keeps shrinking.
What this episode reveals
Public infrastructure runs on shared foundations
Governments run thousands of websites, but many sit on the same few building blocks. When one of those blocks cracks, hundreds of agencies face the same problem on the same morning. The shutdowns spread so quickly across borders because the dependency is shared, not because the agencies coordinated their architecture.
Coordinated disclosure is fragile
The process is supposed to give vendors time to fix things before the public hears about them. Here the researchers reported the bugs to PHP in August, but the details leaked in October, a day before the fix. That left a dangerous window where attackers knew more than defenders could act on.
Incident response now includes the “off switch”
A few years ago, taking a national agency’s website offline for a vulnerability would have seemed extreme. Now it’s an accepted playbook step, and an explicit recommendation from agencies like CERT-EU. Expect “can we shut this down safely?” to become a standard question in security planning.
Old versions are everyone’s problem
Operators on unsupported PHP versions got the worst of this. With no upstream patch for 8.1 and earlier, they had to depend on vendor backports, migrate in a hurry, or stay offline. Every organization with a “we’ll upgrade next quarter” PHP server just saw what that decision can cost.
What it means for your site
You probably don’t run a national portal, but the lessons scale down:
- Update PHP now. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart your web server or PHP-FPM. PHP’s position is that updating is the only safe route.
- Check your host. On managed or shared hosting, ask whether they’ve patched and when. Don’t assume.
- Rebuild containers. Patched packages on the host don’t fix old images.
- Have an “off switch” plan. Know in advance how you’d put up a maintenance page and who can authorize it.
- Retire end-of-life PHP. If you’re on 8.1 or earlier, schedule the migration.
- Check for compromise. Look for new or modified PHP files, odd outbound connections and unexpected admin accounts, especially if your site was online and unpatched on October 20–21.
- Subscribe to advisories. Your national CERT and the PHP security announcements are the fastest sources.
Lastly
The October 21 shutdowns weren’t a technical failure. They were a deliberate risk decision, made by agencies that concluded a short, controlled outage beat the chance of an unauthenticated attacker running code on their servers. With a fix now released, the immediate emergency is easing, but the work isn’t over. Every PHP server still unpatched is exposed to flaws that are now public and reportedly being exploited.
If you manage any PHP site, update today. Then use this episode to ask what you’d do if the next warning arrives before the next patch.
