Update, 21 October, 18:10 UTC: the fix is in. Every WordPress site we host is now running PHP 8.3.36, the version with both flaws fixed. We rolled it out one site at a time with no downtime, checked every copy of every site, and found no sign that any site was broken into. There’s nothing you need to do.
On 21 October the team behind PHP, the language WordPress is written in, announced an emergency security release for 14:00 UTC (3pm in the UK). It fixes two serious flaws that could let an attacker run their own code on a website without logging in. Details leaked before the fix was ready, so security researchers expect attacks to start within minutes of the release, if not before. The CERT-EU advisory has the official summary.
Every WordPress site we host runs on PHP, so this affects us like everyone else. Here’s what we’re doing about it.
Before the Fix
- We’ve kept a copy of the evidence. The access and error logs for every site, from 20 October onwards, are saved in separate storage. If anything does turn out to have happened, we can look back and see it.
- We’re watching the front door. No site we host can be reached directly from the internet. Every visit comes in through Google’s load balancer first, so there’s no back way in. We’ve added a check there that flags the type of request these flaws rely on, on every WordPress site, and we’re watching the results as they come in.
When the Fix Arrives
When the fix is out and the updated WordPress software has been built with it, we’ll rebuild our WordPress setup with that version and roll it out to every site in turn.
You shouldn’t notice. Every live WordPress site runs as at least two copies, and we replace them one at a time. The second copy keeps serving visitors while the first is updated, then they swap. Once every copy is updated, we check that each one is running the fixed version before calling it done.
The Honest Bit
We’re watching for these requests, not blocking them. The same kind of request is how some sites take file uploads, such as a form where someone attaches a document, and blocking it would break those forms for the few hours until the fix lands. If we see anyone actually trying to exploit the flaws, we can switch to blocking within minutes, and we’ll accept the broken uploads for a while to keep your site safe.
What If a Site Were Broken Into?
We don’t expect it to happen, but it’s the right question to ask, so here’s the honest answer.
Each site lives in its own sealed box. Every WordPress site we host runs in its own set of containers, with its own database, its own database login and its own folder of files. A site’s login only opens its own database, and only its own folder of files is connected to its containers. So an attacker who got into one site would find themselves inside that one site, with no login for anyone else’s database and none of anyone else’s files to hand.
Even inside, they’d have very little to work with. The website software runs as an ordinary, restricted user, never as an administrator of the machine. On top of that, every WordPress site has a lock that stops it reading anything outside its own website folder. That’s the same lock we described last month, and it shuts down a whole class of attacks that try to reach the rest of the system.
Restarting wipes the slate clean, mostly. Each container is built fresh from a known-good copy every time it starts, so anything an attacker managed to plant in the running software disappears on a restart. The part that does survive is the site’s own files and database, because that’s your content. That’s why the next step matters.
Backups go somewhere an attacker can’t reach. Every site’s database and files are copied every night to separate storage, and we keep 28 days of them. The site itself has no way to change or delete those copies, so a break-in can’t quietly erase the evidence or the way back. We also take a fresh snapshot by hand before any risky change.
If the worst happened, here’s what we’d do:
- Shut the door first. We can make a site read-only at the front door within minutes, as we did today for one site that drew a lot of hostile attention. Visitors can still read it, but nothing can be changed or sent to it.
- Work out how and when. We keep the logs, so we can see where the attacker came in and when it started.
- Put it back as it was. We restore the site from the last backup taken before the break-in, then check every WordPress and plugin file against the official published copies to make sure nothing tampered with has survived.
- Change every key. Passwords, database logins and the site’s secret keys are all replaced, so anything the attacker copied becomes useless.
- Tell you straight away, with what happened, what was affected and what we’ve done about it.
What This Means for You
- No action needed. There’s nothing for you to install or change.
- Static sites and our custom apps aren’t affected. They don’t run PHP.
- Every site is now on the fixed version (see the update at the top).
Not hosted with us? Ask your host when their sites moved to PHP 8.3.36 and how they checked for break-ins. If the answer is vague, or doesn’t come, send us a login or an export: we copy the site, test it privately, then switch your domain. The first migration is free.
If you have any questions about your own site, get in touch.