If you tried to log in to DigiD, check a French prefecture’s website or read the news on Tweakers on Wednesday, October 21, 2026, you probably got an error page. Nothing had crashed. Governments, hospitals, news sites and hosting companies took their own websites offline, on purpose, while they waited for a fix to two critical flaws in PHP.
PHP runs a big part of the web. Wiz Research, one of the teams that found the flaws, puts it at 70% of all websites. So when the PHP team announced an emergency security release a day in advance, a lot of website owners came to the same conclusion: once the fix is public, attackers can study it and build an exploit, and every site that isn’t patched by then is a target.
Until the update shipped, there was no real fix. PHP’s own temporary settings only reduced the risk, so a lot of organizations, from governments to hospitals, chose to switch their sites off and wait for the update.
Quick overview: What is PHP2Shell?
The two vulnerabilities, nicknamed PHP2Shell, are CVE-2026-109618 and CVE-2026-109619. The PHP security team rated both critical, with a CVSS score of 9.2, and both can let an attacker run code on a server without logging in.
They sit in PHP itself, not in a plugin or a framework, so it doesn’t matter how carefully your own app is written. WordPress, Drupal, Magento, Joomla and Laravel sites are all exposed if the PHP underneath is vulnerable.
According to the PHP team, the riskiest setup is Apache with mod_php, where a single request can trigger the attack before any application code runs. Wiz says every PHP version back to 5.4 is affected by at least one of the bugs.
The fix shipped on October 21 at 14:00 UTC in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer get official updates, but the PHP team published source backports for 7.4, 8.0 and 8.1, and some vendors offer their own.
The bugs were found with a lot of help from AI. According to the PHP Foundation, the security firm Calif (auditing PHP as part of OpenAI’s Patch the Planet program) and OpenAI reported the same root cause independently on August 11. Wiz followed with more attack vectors on August 24.
The timeline
| Time (UTC) | What happened |
|---|---|
| Oct 20, ~15:00 | The CVE IDs leak on forums and social media, with the incorrect release time and a CVSS score of 10.0 |
| Oct 20, 19:30 | PHP publishes its advance notice. The release moves up a day, to October 21 at 14:00 |
| Oct 20, ~20:00 | Calif mistakenly publishes a video of its proof of concept |
| Oct 21, 03:02 | Cloudflare puts WAF rules live for its customers, free plans included |
| Oct 21, 07:34 | Hosting companies report active exploitation to Patchstack |
| Oct 21, 07:41 | Chainguard publishes container images with the fix, more than six hours early |
| Oct 21, 07:43 | Cloudflare’s CTO says the company is seeing early attacks |
| Oct 21, morning | Dutch sites go dark, including DigiD, MijnOverheid and the National Cyber Security Centre’s own website |
| Oct 21, evening in Japan | Japan’s Prime Minister asks companies on X to get ready to patch |
| Oct 21, 13:54 | php.net returns 504 errors for our team, minutes before the release |
| Oct 21, 14:00 | PHP releases the fixed versions |
| Oct 21, 14:11 | A widely used Ubuntu PHP repository on Launchpad returns 503 errors under the load |
| Oct 21, 17:00 | The Czech government takes its website offline to apply the patch |
Why so many sites took themselves offline
Switching off your own website sounds like the last thing anyone wants. On October 21, it was official advice. CERT-EU told organizations that couldn’t patch to isolate internet-facing systems until the fix was in place.
The UK’s NCSC said to consider taking systems offline if the temporary mitigations weren’t possible. In Japan, Prime Minister Sanae Takaichi posted on X asking companies to get ready to apply the patch as soon as it came out.
A lot of people listened. According to Reuters and NOS:
- Netherlands: The National Cyber Security Centre, DigiD, MijnOverheid, the House of Representatives, the Port of Rotterdam, the five largest political parties and many hospitals
- France: Prefecture websites, “a precaution pending a patch,” per the Interior Ministry
- Germany: Several federal websites, a move the digital ministry called “purely preventive”
- Finland: Government public web services, run by the state IT center Valtori
- Belgium: The foreign ministry’s websites
- Czech Republic: The government website, until the security updates were applied
- Wikimedia Foundation: “A number of other systems” as a precaution
In Japan, Bloomberg reported banks and airlines taking down digital services too.
“Once a patch like this goes public, it can be reverse engineered into a working exploit in minutes, and mass scanning starts right after. If you can’t patch yet, a few hours of planned downtime is a much smaller risk than leaving the site up and hoping.”
Kristian Razum, DevOps expert at UptimeRobot
Patching turned into its own outage
The fix was out at 14:00 UTC. Getting it onto servers was harder, because everyone was trying to download it at the same moment.
Our team got 504 errors from php.net itself a few minutes before the release. Shortly after, the Launchpad repository many Ubuntu servers use for PHP packages started returning 503 errors, and people on Hacker News and the repository’s issue tracker reported the same.
Its sister repository at packages.sury.org had the new builds earlier and became the workaround. Builds for some architectures and container images took longer to appear, so some teams compiled PHP from source rather than wait. The Remi repository, popular on Red Hat-based systems, had already warned it wouldn’t have updates on release day.
“The patch was ready, but half the internet was trying to download it at the same time. Know where your packages come from, have a second source ready, and be prepared to build from source if you need to.”
Alex Ioannides, Head of DevOps at UptimeRobot
What we saw from UptimeRobot
All that planned downtime showed up in our data. On October 21, UptimeRobot triggered about 11 times more downtime alerts than on a normal day, around 37,000 per minute at the peak, against roughly 3,300 the day before.
The rise started in the late morning in Europe and turned steep at 12:00 UTC, two hours before the fix was out. The peak came after the release, from about 14:30 to 19:00 UTC, and alerts only eased off slowly overnight.
Website checks took the hit.
Almost all the extra failures came from website checks (HTTP and keyword) that couldn’t connect. Ping and DNS failures stayed at their usual level. The error that grew fastest was “connection refused,” where the server answers but nothing is accepting connections for the website. Between 09:00 and 13:00 UTC, still an hour before the fix shipped, those errors grew about four times.
Three times the usual failure rate, for hours.
On a normal day, about 0.55% of website checks fail because the site won’t accept the connection. Between 14:00 and 18:00 UTC on October 21, it was about 1.7%, or around 1.3 million failed connection attempts per hour instead of 430,000.
Europe was hit hardest.
For monitors checked from our European locations, downtime alerts rose about 20 times, from around 1,100 to 23,000 per minute, and stayed above 20,000 per minute from 14:40 to 19:00 UTC. In North America, they rose about six times, from 2,300 to 14,000 per minute. Asia and Oceania barely changed.
Country domains point the same way. Compared with the day before, the number of monitored websites we couldn’t connect to rose most for European country domains, led by the Netherlands, where DigiD and MijnOverheid went dark:
| Domain | Websites unreachable, Oct 20 | Websites unreachable, Oct 21 | Change |
|---|---|---|---|
| .nl (Netherlands) | 4,356 | 14,682 | 3.4× |
| .ch (Switzerland) | 2,509 | 7,211 | 2.9× |
| .fr (France) | 3,158 | 7,492 | 2.4× |
| .de (Germany) | 8,660 | 18,422 | 2.1× |
| .com | 99,797 | 157,224 | 1.6× |
It wasn’t over by the next morning. At 09:00 UTC on October 22, downtime alerts were still about 30% above a normal day.
It isn’t over yet
- Attacks started before the fix was out and haven’t stopped. If you patched late, check your logs. Patchstack lists signs to look for: unusual multipart requests followed by memory-limit errors or repeated HTTP 500s, oversized PHPSESSID cookies, and PHP workers restarting for no clear reason. If you find them, update, treat the server as compromised, and rotate the credentials it holds.
- Ignore the rumors saying the fix doesn’t work. A post claiming PHP 8.5.12 is still vulnerable spread fast on X. Its author later edited it to say the bug was unrelated, and there’s no official advisory. Keep deploying the official releases.
- Older PHP versions need more work. If you’re on 8.1 or older, you’ll need a vendor backport, the PHP team’s source backport, or an upgrade.
- It wasn’t only PHP. Node.js shipped its own security release the same day, with four high-severity fixes across the 22.x, 24.x and 26.x lines, including a remote code execution bug in the Brotli decoder.
Getting ready for the next one
October 21 won’t be the last time a team has to take its site down at short notice. A few things make that day calmer.
Plan the downtime so it doesn’t page you. Set a maintenance window in UptimeRobot for the time you expect the site to be offline. Your monitors won’t fire alerts for downtime you planned, and the on-call person won’t get woken up for it.
Tell your users before they find out. Post a short note on your status page: what’s down, why, and when you expect it back. People are much more patient with “we’re applying an urgent security fix, back by 16:00” than with an error page and no explanation.
Check that the site actually came back. A server can be up while the app on it is broken after an upgrade. A keyword monitor on your login or checkout page tells you if users see a 500 error or an empty page instead of the content they expect.
“Patching isn’t the last step. Check that every site came back the way it should, and keep an eye on your logs, because the scanning starts right away.”
Kristian Razum, DevOps expert at UptimeRobot
Watch the services you depend on. Your patch, your hosting and your CDN all come from someone else. With Third party monitoring, you pick the providers your product runs on, among more than 6,000, and get an alert through the channels you already use when their status changes.
Final thoughts
On October 21, the internet chose to go dark for a few hours rather than risk being hacked, and for most teams it was the right call. The ones who had the easiest day already knew which of their sites ran PHP, had told their users what was going on, and got an alert the moment something didn’t come back.
Get 50 monitors with 5-minute checks, free, no credit card required.
