The PHP patch was the easy part
A headline said PHP took down 80% of the internet. It didn't. What actually happened is a cleaner story, right up until you reach the half of the web that the PHP project no longer patches.
Someone forwarded me a headline this week that said 80% of the internet was down because of PHP. A couple of people asked me if it was actually true.
It wasn't. No wave of sites fell over. Nobody has shown a single confirmed break-in at any major site. What happened is smaller than the headline, except for one piece that is worse, and that piece never made a headline at all. So let me walk through the whole thing.
What actually happened
On the 20th of October, a post appeared on Hacker News claiming two serious security holes in PHP were about to be made public. Someone pulled the post down, but by then it was out. Within hours a security firm called watchTowr had checked the claims, rebuilt one of the bugs themselves, and confirmed they were real.
PHP's security team already had a fix in the pipeline. Once the secret was half spilled, they brought the release forward by a day and pushed out an emergency patch on the 21st.
The two bugs picked up the nickname PHP2Shell. Both score 9.2 out of 10, which is near the top of the scale. Both let an attacker run their own code on your server without ever logging in. One abuses what PHP does when it runs out of memory. The other abuses leftover internal state that should have been cleaned up and wasn't. The mechanics differ, but the shape is the same: send the server a certain kind of request and it does something it was never built to do.
Now, the part that scared everyone.
Think of your website as an apartment you've furnished. You chose the layout, painted the walls, locked your own front door. PHP is the building itself: the foundation, the frame, the pipes running inside the walls. You didn't build that part and you can't see most of it. These two bugs were cracks in the building, not in anything you put inside your apartment. However carefully you'd furnished the place made no difference. If your site ran an affected version of PHP and faced the open internet, the crack was in your wall too.
So people stopped waiting to find out who would fall through it. The Dutch government pulled portals offline, including the one citizens use to check their own records. Germany, France, Finland and Belgium did the same with parts of theirs. The Wikimedia Foundation took some of its systems down. Hospitals, universities, a Dutch tech news site, a long list of others. Cloudflare and a few other firms did see attackers probing for the bug within hours, but nobody has shown a successful intrusion. The outages were self-inflicted. Administrators switched their own lights off, on purpose, until they could patch, because for a few hours the safest state for a site to be in was unreachable.
That is the whole of "the internet went down". People unplugging their own sites before anyone else could.
An AI found what twenty years of humans missed
One detail from this stuck with me more than the bug itself.
These flaws were found by AI. Not one team, two. Researchers at Wiz had been pointing a model at the PHP source code and it surfaced problems that had been sitting there for more than a decade. OpenAI says its own model found the same bugs independently, as part of a project it runs to scan open source code for exactly this kind of thing.
That is strange when you sit with it. PHP's source is some of the most-read software on earth. Thousands of engineers have opened those files over the years, plenty of them excellent. The crack was behind the plaster the entire time, and two machines, working separately, walked past and spotted it.
I've argued before that most people bolt AI onto the wrong job. They want it writing the feature, standing in the live path of the app, making calls in production. That's the shaky place for it. The solid place is this one: reading something everyone already trusted and finding the fault nobody else did. The same technology that lets a beginner spin up a web app over a weekend can also read a twenty-year-old C file and catch what a generation of experts walked past. We'll be living with both of those for a long time.
More than half the web got nothing from PHP
So a fix exists. If you're on a current version of PHP, you update and you're done. Pick your branch: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Run it, restart, get on with your day. For most working developers this was a dull Tuesday-afternoon chore.
But here is the piece the headlines skipped.
The PHP project only patches four branches, 8.2 through 8.5. Everything older got nothing from the project itself. No official fix for 8.1, none for 8.0, none for the huge slice of the web still sitting on 7.x. And by most counts, around six in ten internet-facing PHP servers run exactly those abandoned versions.
Now, to be fair, "nothing from the project" is not the same as nothing at all. Ondřej Surý, the person who maintains the PHP packages most Debian and Ubuntu servers actually install, shipped patched builds for every version from 5.6 to 8.5 within a day. Cloudflare put a rule in front of its customers' sites nine hours before disclosure. So if you were on 7.4 on Ubuntu, there was something you could install.
But think about what that means. Your security now depends on one volunteer in Prague deciding to backport a fix to a version the language itself gave up on, and on you knowing where your PHP packages even come from. Plenty of people don't. The other workaround going around, switching off session.upload_progress, shuts one of the two doors and leaves the other wide open. So for a large chunk of the web, the honest advice this week was closer to "hope someone upstream covers you" than "apply the update".
That is why the patch was the easy part. It was finished the moment it shipped. What isn't finished, and won't be, is the millions of sites that got a loud, global, government-level warning and had to go looking for a fix the language itself was never going to give them.
You're running a backend, even if you didn't mean to
One lesson sits under all of this.
The moment your software touches real users and real data, you are running a backend, whether you signed up for one or not. And a backend is not the code you launched with. Go back to the building for a second. The rooms you furnished are the features you shipped. The foundation and the pipes are the runtime underneath them: the PHP version, the server, the updates you'll be forced to apply at two in the morning the week a bug like this one lands.
Nobody treats the foundation as optional. You don't get to say you'll reinforce the load-bearing wall later, once you've bought more furniture. It holds the whole thing up or it doesn't.
The developers patching this week were fine, because they'd kept their foundation current and it cost them a boring afternoon. The ones stranded on a dead version of PHP were in trouble long before this bug had a name. All the warning did was switch the lights on so they could finally see it.
Get the next one
No drip sequence. Unsubscribe is one click in the first line.