On Wednesday afternoon we watched the Dutch parliament, Finland’s central government and the Dutch national cyber security agency switch off their own websites. Japan’s prime minister asked everyone running a public website to patch that night or take it down, in a post seen 30 million times. The NSA said the same. By 14:00 UTC the fix was out, and by Friday afternoon all of the 51 sites I’d been tracking were back.
Nothing burned. A decade ago, this would have gone very differently.
In January 2003, SQL Slammer infected about 90% of vulnerable hosts within ten minutes. There was no warning, no coordination, and no way to react faster than a worm that doubled every few seconds.
In 2017 there was warning. Microsoft patched the bug behind WannaCry in March. WannaCry hit in May anyway, because two months wasn’t enough for a lot of organizations to install a patch.
In 2019 Microsoft patched BlueKeep and told everyone it was wormable. Six weeks later about 805,000 machines were still exposed, a drop of 17%.
This week had two critical failures in shared infrastructure: two remote code execution bugs in PHP, and eight private keys at a certificate authority that were built from small numbers instead of random ones, which made them simple enough to guess. Both were handled in hours, mostly in public, by people who had been preparing for exactly this.
The warning reached people, and they listened. When the PHP bug details started leaking on Tuesday, the PHP security team moved the release up by a day and pre-announced it the same evening. By Wednesday morning, hosts had disabled the risky setting, governments had issued guidance, and security teams had a deadline in their calendars. That much attention used to take a breach. This week it took a pre-announcement, a leaked CVE number and a few posts from people who knew what they were looking at.
The edge moved first. Cloudflare had been building protections inside the embargo since early October, and its rules went live for every customer, free plan included, at 03:02 UTC, eleven hours before the fix existed publicly.
Packages were ready within hours. Linux distributions got the patch in advance. Debian’s advisory went out at about the same time as PHP’s own release, and Red Hat, AlmaLinux and Ubuntu followed within hours. PHP itself published source backports for three versions it no longer supports.
Ondřej Surý, who maintains the PHP packages a lot of Debian and Ubuntu servers depend on, had fixed builds out the same afternoon for every version back to PHP 5.6, a release that has been out of support since the end of 2018. That is heroic work, and it should never have been needed: anyone still running PHP 5.6 in 2026 is on software nearly eight years past its final end of life. The Atlantic has the story of his week.
Not everything was smooth: the official Docker image briefly pushed empty tags, ARM builds took days, and one popular repository for Red Hat systems didn’t catch up until Thursday. But the gap between “the fix exists” and “the fix is on your server” was measured in hours.
People chose downtime over risk. Pinboard, the bookmarking and archiving site Maciej Cegłowski has run largely on his own since 2009, went dark too. When someone called switching servers off “kinda extreme in hindsight”, Maciej answered:
Pinboard@Pinboard
Not in hindsight (issue is ongoing), and it really depends on potential consequences. I run an archiving site and remote code execution means everybody's data over the past 17 years is potentially compromised. I'm good at apologizing but prefer the downtime.
Sabatino Masala @SabatinoMasala
I understand everyone has a different use-case, but 'turning the server off' as a solution to todays problem seemed kinda extreme in hindsight?
8:31 PM · Oct 21, 2026 · 4.28K Views
4 Replies · 8 Reposts · 186 Likes
A pessimist would call that a tooling change, but it’s actually a significant cultural change. A decade ago, organizations taking their public sites offline for a bug nobody had exploited yet would have been ridiculed.
The certificate authority took hours, not weeks. On 17 October a researcher ran Google’s open-source key checker over the public list of CA certificates and found eight eMudhra keys that anyone could recover in milliseconds. He emailed the browser root programs at 18:05 UTC. Chrome was blocking the keys an hour and forty minutes later. Firefox followed the same night. eMudhra revoked them the next morning, Mozilla removed the whole root, and on Thursday eMudhra announced it was leaving the TLS certificate business. When DigiNotar was compromised in 2011, it detected the intrusion on 19 July and told nobody. A fake Google certificate was used against Gmail users in Iran for weeks, until an Iranian Gmail user noticed on 28 August.
By Friday, nobody had confirmed a single successful break-in from either incident.
On Thursday I spoke at AWS Community Day Adria in Ljubljana, and PHP and eMudhra came up in nearly every conversation. Everyone I talked to said the same thing: that was handled well, and it could have been much worse. They’re right. Mostly.
The slow part was upstream, and it was very slow. The PHP root cause first surfaced in a 2020 bug report and turned up concretely in a 2024 security audit by Quarkslab. Then it sat. The PHP Foundation’s own post-mortem doesn’t soften it: “the delay was a structural failure.” The fast response this week was cleaning up after a two-year wait.
eMudhra’s keys were weak for about eighteen months. In June 2025, crt.sh, the public certificate search engine, flagged invalid revocation-list signatures on exactly these intermediates in a public bug. eMudhra called it a configuration mistake, the bug was closed, and eMudhra now says it fixed those revocation lists by re-signing them with the weak keys. Its annual audits found nothing. In both cases a warning existed, and someone decided it wasn’t urgent because nobody had proven an exploit.
The embargo leaked from the inside. What was initially reported as one careless researcher leaking the vulnerability was actually four separate breaks, three of them from people inside the coordination circle, including a security company that published patched images hours early. Separately, Amazon’s honeypots logged an exploitation attempt on 17 October, three days before anything leaked, and nobody knows how.
The long tail is still there. Chrome and Firefox fixed the certificate problem in hours because they update themselves. Apple’s block depended on eMudhra’s own revocation server, which was returning errors, so Safari kept accepting some of the bad chains until Thursday. Microsoft said nothing at all and blocked the keys a few days later. Go shipped a hard block with no way to turn it off, which is the right call, but it only helps programs that get rebuilt. A test server with a certificate that was never published to any log still took 8,806 successful connections in seventeen hours, mainly from curl, Node and Python. On the PHP side, the firewalls and NAS boxes whose admin pages run PHP wait for firmware that some of them will never get.
And some of it was luck. The real PHP exploit is hard. Marcus Hutchins points out that most of the “exploits” hitting honeypots were AI-generated code for an unrelated, years-old technique, and that the real one works only on a handful of configurations. The system was never tested by a working worm. So we were also quite lucky: despite all the leaks, it appears nobody got to a one-size-fits-all working exploit in time.
And it was never a PHP problem. The comments treated this week as proof that PHP is a legacy language that deserves what it gets. The same afternoon, Node.js shipped a fix for CVE-2026-111497, a remote code execution bug in its Brotli decoder, already nicknamed Node2Shell and reported by OpenAI’s Codex Security team. In July, Rails patched CVE-2026-66066, a critical Active Storage flaw that attackers started exploiting about a month later. And this morning, Ruby shipped fixes for four memory-corruption bugs in its regex engine that, by Ruby’s own account, could be turned into remote code execution on GitLab’s servers. PHP’s week was louder because WordPress alone runs about 40% of the web, not because PHP is uniquely bad. The next one could just as easily land in Node, Python or Ruby, and the comment sections will be just as sure it couldn’t happen to them.
AI showed up on every side this week, and it didn’t behave the same way on each.
The PHP bugs were found by researchers at Calif, Wiz and OpenAI, using AI-assisted tooling. Chainguard’s CEO says a harness built on Claude found a working exploit chain in eight hours for under $1,000, days before the leak. That’s his claim, and he hasn’t published proof.
Meanwhile, the crowd pasting hints into chatbots produced fake exploits by the thousand. According to Hutchins, some researchers then used AI to triage those fakes and reported “mass exploitation” that wasn’t happening. He calls LLMs “a Dunning-Kruger accelerator” in the wrong hands. A purpose-built harness that checks its own work three times found a real chain; a chatbot asked for an exploit found a plausible-looking wrong one. The skill moved from writing the exploit to building the thing that verifies it.
The maintainers are caught in the middle. curl’s Daniel Stenberg says AI-assisted bug reports are now “typically accurate and correct“ and that the problem is “high volume, high quality”. From Monday, curl handles everything below HIGH severity in public, because its maintainers are “brought to the brink” and can’t keep running every report through a private process. Ruby, meanwhile, is still deciding whether this morning’s regex bugs even count as vulnerabilities.
Coordinated disclosure, embargoes and advance patches worked, and they’re expensive. Projects run by a handful of people can afford them for the few bugs that really matter, and only if someone pays for the people. The PHP Foundation’s answer to its own two-year stall is a security team that decides by majority instead of consensus, leadership that steps in when a fix stalls, and a request for money. Amazon’s CISO put the other half bluntly: “A 7-day or 30-day SLA assumes a delay that no longer exists.“
If you patched on Wednesday and checked your logs from Wednesday, Amazon’s advice is to start your investigation from 17 October, the earliest attempt its honeypots logged, not from the day the bug went public. Amazon hasn’t said whether that attempt, or the ones on release day, could actually have worked.
We got good at this because we had to. The next one will move even faster, and so must we.