An Equal Sense of Speed.

At the speed everything happens at now, there has to be an equal sense of speed for fixing things. That's the thought we've had all day, watching a security story unfold that touches something like seven in ten websites. The story is the occasion. The habit is what we want to talk about.

Here's the story. On Wednesday 21 October the PHP project shipped fixes for two critical holes in the language itself — not in WordPress, not in a plugin, in the engine underneath. PHP runs WordPress and WooCommerce, Drupal, Magento, Laravel, and by Wiz's count around 70% of the web. The flaws, which have picked up the name PHP2Shell, let someone with no login run code on the server, and they've been sitting there for more than a decade: every version back to PHP 5.4 is affected. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older is out of support and isn't getting a fix from the project at all. In php.net's words, "there are no complete mitigations, updating is the only safe choice."

What they are, and why nobody found them

The bugs live in the part of PHP that handles things going wrong. When a request runs out of memory, or dies halfway through, PHP can leave a half-made internal state behind, and the next request on the same worker can pick it up and reuse it. One flaw lets an attacker read live memory out of the worker — other people's sessions, passwords, API keys. The other is a use-after-free in the way fatal errors are logged, with a second bug in OPcache alongside it. Chained together, Wiz demonstrated unauthenticated remote code execution against stock WordPress and Drupal.

So why did a decade of developers walk past them? Our reading is that they live on the failure path. The code that runs when memory has already run out is the code nobody exercises on a good day, and it's the hardest to test. And spotting a wobble there isn't the same as proving it dangerous. Turning these into working exploits meant chaining several bugs and getting PHP's memory layout exactly right, differently for each version and each configuration. Wiz says that's work that would have taken a world-class team months. With Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol doing the analysing and the iterating, one researcher did it in about a week, back in August. That's the new part. The flaws were always there. The ability to prove it, cheaply, is what arrived this year.

The second wave

We've watched these things play out before, over eighteen years of running and building shops, a good many of them on PHP — Zen Cart, osCommerce, Magento. The pattern used to be reliable. The first wave is aimed at the high-profile sites, the ones worth the effort of a hand-built attack. Then, a few days later, the second wave: bots with scripts, hitting any site they can find that answers as PHP, whether it's a bank or a bike shop. The last big PHP hole, in June 2024, had a ransomware crew using it inside forty-eight hours of the patch. So people think after a day or so that things are calm. It may just be the calm before a really big storm, if you haven't patched.

This time the waves arrived out of order. The details leaked onto social media before the embargo lifted — the disclosure was pencilled in for Thursday, the project brought it forward to Wednesday, and by mid-morning on Wednesday hosts were logging the first exploit attempts, hours before the patch landed. By lunchtime the automated scanners were out. That's the bad part of today: details getting out before sites have had a chance to update. Everything else about it is, oddly, good news.

Not necessarily a terrible thing

It's tempting to read today as proof that AI has made the web more dangerous. We'd put it the other way. These holes were open for ten years. Anyone with the resources of a state, or a patient criminal, could have been using them quietly the whole time, and nobody would have known. Now they're closed, and the code is better for it. What AI has changed is the price of looking: the kind of audit only a handful of teams in the world could afford is becoming something one person can run in a week. So there will be more of these, probably a lot more, across every language and platform, not just PHP. The code the web runs on is about to get a thorough going-over, and that's a good thing.

The cost lands in one place: the gap between a hole being announced and your site being fixed. That gap used to be measured in days, and nobody minded much. Today it was measured in hours, and in the wrong direction.

An equal sense of speed

Which brings us back to where we started. If the finding gets faster, the fixing has to get faster to match. For a shop on a hosted platform like Shopify, that's part of what you're paying for: the people who run the platform patch it, and you'll never see a version number. For anyone on WordPress, WooCommerce, Magento or a custom PHP build, it's on you, or on whoever looks after the site for you. Today the job was to find out which version you're running, find out whether your host had already moved you, and if they hadn't, to move — the same day, not the week after.

What we'd take from today is simple. You've got to have a partner who's really on it, who knows what they're doing, and who can react to these things fast. Someone who already knows what your site runs on, who read the advisory this morning rather than next month, and who you can reach at once. For the sites we look after, a morning like this one ends as a line in the Logbook — what was patched, when, and what we checked afterwards — so the next person to open it knows.

And as of this week we're on WhatsApp, on +44 7743 298109. If something's happening and you want a person on the other end of it quickly, that's the number. If your site is on PHP and nobody has been in touch with you today, that's worth knowing too.

The flaws were always there. The ability to prove it, cheaply, is what arrived this year.