The engine under most of the web had a hole in it

At 3pm on Wednesday 21 October, the people who make PHP released an emergency fix for two flaws that let a stranger take over a web server without logging in. The same day, the Metropolitan Police and the councils in Edinburgh and Oxford were among the websites reported offline, and the National Cyber Security Centre’s advice to anyone who couldn’t patch quickly was to consider doing the same.

The flaws have a name, PHP2Shell. “Shell” is the command line on a server: the thing you’d use to run anything you like on it. So the name tells you what the flaws do. They get someone from an ordinary web request to a command line on your server.

I had nothing to do. Not on the WordPress sites I host, and not on the static ones. Those are two very different reasons, and the difference between them is most of why I’ve been moving clients off WordPress.

What PHP is, and why this one mattered

PHP is a programming language, and it’s the one most of the web’s servers run: 69.3% of websites whose server-side language can be identified, according to W3Techs. WordPress is written in it, and WordPress on its own runs 39.6% of all websites. Every time someone opens a page on a WordPress site, PHP wakes up on the server, reads the database, runs the theme and the plugins, builds the page and sends it back. Thousands of times a day, on every site.

Most of the WordPress security scares you hear about are in a plugin, or now and again in WordPress itself. This one was underneath both, in the engine. Both flaws were rated 9.2 out of 10 for severity. PHP’s own advisory said the risk was highest on one common server setup, where a stranger with no login could set the attack off before any of the site’s own code had run. In plain English: before WordPress has even started, let alone a security plugin.

How it works, without the jargon

A server running PHP keeps a handful of workers going, and each one deals with visitors one at a time, a bit like the clerks on a hotel front desk. A clerk checks a guest in, deals with them from start to finish, then clears the desk for the next one.

PHP2Shell is two slips in that clearing up. In the first, a worker that runs out of memory at exactly the wrong moment stops halfway through setting something up, and the tidying afterwards treats the half-finished job as if it were complete. In the second, a note about one visitor’s request can survive on the desk after the thing it points to has been thrown away, and the next visitor that worker serves can arrive before the desk is cleared.

Either one can be turned into a way in. Going by one research team’s reconstruction, it goes something like this. The attacker’s first visit is built to make the worker fall over at the right moment, so a stale note gets left behind. The note says, in effect, “the paperwork for this is in tray four”, and tray four has just been emptied. Their second visit, to the same worker, puts their own paperwork in tray four. It arrives as a file upload, and PHP files away its details without looking at them. The worker reads the note, goes to tray four and does what the paperwork says. What it says is: run this.

Getting that to work meant stitching together several small, unremarkable-looking weaknesses, in the right order, on the same worker, across separate visits. That’s why it went unnoticed for so long, and it’s why the way it was found matters. More on that below.

Why updating WordPress didn’t fix it

This is the part that catches people out. A WordPress site has an Updates screen, and when it’s all green it feels like the job’s done. Not this time. The flaw was in PHP, which sits underneath WordPress and is installed by whoever runs the server. Cloudflare, which sits in front of a large slice of the web, said as much: updating a site’s code or its plugins wouldn’t fix it.

So the question for a WordPress site wasn’t “is WordPress up to date?” It was “who runs my PHP, and have they patched it?” For a lot of small businesses, nobody knows the answer.

And for a lot of sites, the answer was worse than slow. PHP only released fixed versions for the four versions it still supports, 8.2 to 8.5. For 7.4, 8.0 and 8.1 it published a bare patch for people who build PHP themselves, and some Linux vendors backported fixes of their own. Anything older got nothing from PHP at all. WordPress.org’s own figures, from the sites that check in with it for updates, show how many sites that covers:

That’s about a third of WordPress sites on a version of PHP with no fixed release, and 15% still on PHP 7.4, which stopped getting security updates at the end of 2022.

Those sites aren’t old because their owners are careless. I’ve watched it happen to sites I built myself. I finish a WordPress site, the business wants to look after it in-house and save the monthly cost, which is a perfectly reasonable call, and I hand it over. Two years later it’s three versions behind. Nobody did anything wrong. Keeping a website updated just isn’t anyone’s job when you’re busy running a business.

What someone actually does with your site

Most people picture a hacked website as a defaced one, the homepage swapped for a message. That’s rare now, because a defaced site gets noticed and fixed. What an attacker wants is a site that carries on looking normal, so they can carry on using it.

Sucuri, a company that cleans up hacked websites for a living, published a breakdown of the 39,594 sites it cleaned in 2023, and 95.5% of the infections it found were on WordPress. Most of those sites had more than one thing wrong:

• About half had a backdoor (49%). That’s a hidden way back in, so cleaning up the obvious mess doesn’t get rid of them. Of the sites with malware hidden in the database, more than half also had a fake administrator account.
• Nearly half had general malware (48%): code that sends your visitors somewhere else, tries to steal their logins, or pushes downloads at them.
• One in five had SEO spam (20%). These are hidden pages selling pills, knock-off designer goods or gambling, borrowing your site’s good name in Google. It’s often shown only to Google, so you never see it yourself. The first you hear is your business turning up in search results for things you don’t sell.
• About one in twenty was sending spam email (5.8%), and about as many were hosting phishing pages (5.1%): fake login screens, sitting on your server under your domain name.
• About one in a hundred had a card skimmer (1.3%): code on the checkout that copies card details as customers type them.

If you take payments through Stripe, card numbers never touch your server, and that’s the right way to do it. It means nobody can steal a database full of them. What it doesn’t stop is a hacked site putting its own fake card form on the checkout page, on top of the real one, and collecting whatever people type. Sucuri found exactly that on WordPress checkouts in January 2025, hidden in the database rather than in the files, where most scanners look first.

Then there’s everything that follows. If anything personal was exposed (contact form messages, customer accounts, order history), that’s a data breach, and in the UK a reportable one has to go to the ICO within 72 hours of you finding out. Google can flag your listing as possibly hacked, and Chrome can warn people off before your page even loads. And because of those backdoors, cleaning up means finding out how they got in and closing it, which often means going back to a copy of the site from before it happened. That only works if one exists, somewhere the attacker couldn’t reach.

PHP is one layer of three

PHP2Shell was the engine. A WordPress site depends on two more layers, and each of them has had its own emergency this year.

WordPress itself. In July, a flaw nicknamed wp2shell let a stranger take over a standard, recent WordPress site, no plugins needed, without logging in. WordPress pushed the fix out automatically on 17 July, and Patchstack saw the first attacks about 90 minutes later.

The plugins. Patchstack counted 11,334 new vulnerabilities across WordPress in 2025. 91% were in plugins, and 46% still had no fix when they were made public. Then there are the plugins that get bought or broken into and turned against the sites running them, which I wrote about in April. It hasn’t let up. In June, someone got into the company behind OptinMonster and two sister plugins, which are installed on over 1.2 million sites between them. They tampered with the files those plugins load from the company’s servers, so any site where an administrator was logged in quietly gained a backdoor and a new admin account.

Each layer is looked after by different people, on a different schedule, and any of them can need an emergency fix on any afternoon of the week.

What I pay SiteGround for

All the WordPress sites I host are on SiteGround. It isn’t the cheapest option. IONOS, Hostinger, GoDaddy and WordPress.com will all host a WordPress site, most of them for less, and plenty of sites run happily on them. Hostinger told its customers on the day that they didn’t need to do anything either.

But this week showed what the extra buys. On 20 October, PHP gave a day’s notice that a critical fix was coming, without saying what it was for. SiteGround’s security team put protective rules in place across all its servers before the details went public, switched off the affected feature on every version of PHP it supports, and installed the official fixes the same day they were released. Its note to customers told them there was nothing they needed to do.

From where I sit, that’s the whole point. By the time news like this reaches my desk, a few hours have usually gone by, and on 21 October a few hours mattered. Details leaked before the fix was out, and Cloudflare reported attack traffic aimed at its customers. However quickly I move, a host that’s already acted has beaten me to it, on every site at once. Day to day, SiteGround is also 30 days of daily backups and a control panel that makes my job quicker. Weeks like this one are what I’m really paying for.

It’s also why I’d always rather look after a client’s WordPress site than hand it over and hope. Keeping an ear to the ground for this sort of thing is my job, and patching is the bit of it that can’t wait until Monday.

Why it’ll happen again

Underneath, every one of these is an ordinary bug: a mistake in the code nobody had spotted, because nobody had made the right unusual things happen in the right order. Parts of PHP2Shell weren’t even new. Calif, one of the teams that found it, traces the idea of attacking PHP through its memory limit back to 2004, and started from a bug report filed in 2020. A PHP developer noticed the out-of-memory problem itself in a 2024 security audit, and it was left alone, because nobody could show it led anywhere and nobody could agree on the fix. The PHP Foundation has since said plainly that the delay was a failure in how it works, which is to its credit.

What’s changed is how fast bugs like that are being found. PHP2Shell was reported by several teams working separately, and the ones that have described how they did it were all using AI. The first report came in August from Ryan Austin at Calif, working as part of an OpenAI programme to find and fix flaws in widely used software. About a week later, Wiz found the same flaws using its own tools alongside models from Google and OpenAI, and had working attacks on WordPress and Drupal within two days. Wiz reckons one researcher with today’s AI did in about a week what a world-class team would once have needed months for.

The tools that came before either throw millions of malformed requests at a program to see what breaks, or try to follow every route the code could take. Both struggle when a bug needs several unlikely things to happen in sequence, because every extra step multiplies the routes to check. Researchers call that path explosion. A model reading the code can do what a sharp human reviewer does: notice that a bit of tidying up assumes nothing can go wrong halfway through, and go and see what happens when something does. It just does it across far more code, far faster. In Calif’s case, an AI agent reading PHP’s memory code spotted two steps happening in the wrong order and traced the problem back to how PHP reads form data. Austin is clear that his own knowledge of PHP steered it. Nobody finds bugs like this with a one-line prompt.

The most capable of these models aren’t on general release. Anthropic’s Claude Mythos, announced in April, found a bug in the OpenBSD operating system that had sat there for 27 years, and one in FFmpeg, video software built into a huge amount of other software, that had sat there for 16. Anthropic chose not to release it generally. It went first to companies that maintain critical software, including Amazon, Apple, Google, Microsoft and the Linux Foundation, so they could fix things before anyone else found them, and US government agencies have reportedly been given access too. The version anyone can use, Claude Fable 5.1, is the same underlying model with tighter safeguards. It’ll help you find holes in your own code, but hands exploit-building and penetration testing over to a less capable model.

Not every model has those safeguards. DeepSeek and others publish their models’ weights, meaning the trained model itself, so anyone with the hardware can run one with no company in the middle to say no. When the UK’s AI Security Institute tested DeepSeek’s latest in July, the model’s safeguards barely got in the institute’s way, and it pointed out that once weights are public, any safeguards can be stripped out for good. It also found these open models are now only four to seven months behind the best ones on cyber skills.

To be fair to the machines, AI didn’t give the attackers their head start this time. A leak did: details got out early, along with a demo video published by mistake, and Amazon spotted an attempt four days before the fix came out. But every fix is also a map of where the hole was, and Amazon’s point is that AI makes reading those maps cheap. Turning a published fix into a working attack is getting faster and open to more people. Patchstack’s figure for WordPress last year: for the flaws attackers went after hardest, the typical gap between going public and the first attack was five hours.

None of this is bad news overall. Every one of these bugs was reported privately, so a fix could be ready before the details got out (this time, only just), and more bugs found means more bugs fixed. In May, the National Cyber Security Centre told organisations to expect a wave of fixes across all software, as skilled people using AI work through old weaknesses at speed, and its advice was to install updates as soon as they come out, automatically if possible. That’s the right advice. It’s also exactly the advice a website nobody’s looking after can’t follow.

What my static sites have instead

On the static sites I build now, there was nothing to patch, because there’s no PHP. There’s no database and no login page either. When you visit one, the server isn’t building anything. The pages were built once, when I published them, and Cloudflare hands out the finished files from its network. A request has nothing to trip over: no worker to confuse, no tray four.

What your browser gets is plain HTML, a stylesheet and, now and again, a little script. That’s on purpose. A lot of websites these days are built on a stack of technologies they don’t need, and every layer in the stack is one more thing someone has to keep patched. Where a site needs a contact form, that’s a small piece of code on Cloudflare with one job: check the message came from a person, and email it on.

Backups work differently too. A WordPress site is a set of files and a database that change whenever anyone does anything, so the backups have to keep up with it, and you’re always relying on the last one being recent enough. A static site doesn’t change unless I change it, so it doesn’t need backing up so much as keeping. Every version of every site I build lives in GitHub, along with every change we’ve ever made to it. Going back isn’t “restore last night’s copy”. It’s “put it back how it was on 3 March.” On top of that, the code sits on my own computer, on a NAS (a separate storage drive on my network) and in a remote backup somewhere else entirely, and the live copy is on Cloudflare. Lose any one of those and there are four more.

Not every site can work this way. Culted and XO are news sites with teams publishing every day, so they need somewhere to write and somewhere to keep what’s written. When I rebuilt them, the rule was to keep those two things apart. The public website is code, kept in GitHub like everything else, running on Cloudflare with no login on it at all. Its pages are rendered there and cached across Cloudflare’s network, so a reader is almost always handed a finished copy. The editing system the writers use is a separate application at a separate address, with its own accounts and permissions. Its database runs on Cloudflare’s D1, which keeps a history you can roll back to any minute in the last 30 days. It’s always on and costs nothing extra, and we take our own database exports on top. Nothing lives on one machine, and no single copy is the only one.

None of this makes a site impossible to attack. It moves the risk somewhere much smaller. On a static site, the things worth going after are the accounts that can publish it: the domain, Cloudflare and GitHub. That’s a handful of logins I control, not a server running code for anyone on the internet who asks. The other risk is anything a site borrows from another company. In September, the chat widget from Brevo, a popular email marketing service, was hijacked for about four hours and could show a scam to visitors of any site that had it, WordPress or not. That’s why I keep third-party scripts on the sites I build to the few that earn their place.

If you’ve got a WordPress site

Ask your host two questions. Have they patched PHP2Shell, and which version of PHP is your site running? If they can’t answer both quickly, that’s an answer in itself.

If it’s PHP 8.1 or older, get it moved up. Most hosts let you switch versions from the control panel. Check the site still works afterwards, because old plugins sometimes don’t.

If nobody’s updating it, that’s fixable. It’s what my managed WordPress hosting is for: the updates, the backups and the watching become my job, for £75 a month.

Or ask whether it needs to be WordPress at all. Most small-business sites don’t, and moving one to a static site costs the same as a new build, from £600, with every old address redirected so you keep your place in Google. There’s more on why I made the switch, and on how Cloudflare’s network differs from a traditional host.

It’ll happen again. The only real question is whether, next time, it’s somebody’s job to notice. If you’d like that somebody to be me, get in touch.