On Wednesday 21 October 2026, PHP released fixes for two critical security flaws. PHP is the language behind most of the web, including every WordPress site. The flaws, nicknamed PHP2Shell (CVE-2026-109618 and CVE-2026-109619), can let an attacker run their own code on a web server without logging in to anything.
Details leaked the day before the planned release, and attempts to exploit the flaws were reported within hours. The US cybersecurity agency CISA told organisations to patch immediately, and to take systems on unsupported PHP versions offline until they can be updated.
Here’s what it means in plain English, what we did for the sites we look after on the day, and what to ask your own host if you’re not one of them.
What PHP2Shell actually is
Most of the time, a security flaw lives in one piece of software: a WordPress plugin, a theme, a contact form. You update that one thing and the hole is closed. PHP2Shell is different. It’s in PHP itself, the engine that runs the website, so it sits underneath WordPress, Drupal, Joomla, Magento, Laravel and almost everything else written in PHP.
That has two consequences:
- Updating WordPress or your plugins doesn’t fix it. Keep doing those updates anyway, but this one is fixed by updating PHP on the server.
- It doesn’t need a weakness in your site. A perfectly built, fully updated website on an unpatched server is still exposed, because the flaw is in what runs it.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older than PHP 8.2 no longer gets official updates. The PHP team published emergency code fixes for 7.4 to 8.1, but hosts have to apply those themselves, and most won’t.
Why it was a race
Normally a fix like this is released quietly and the details follow later, giving everyone time to update first. This time the flaw identifiers leaked online on 20 October, the release was brought forward a day, and a researcher’s write-up and demonstration were public almost straight away. Cloudflare reported early attacks, and watchTowr said it was seeing attempts against both flaws.
So from Wednesday afternoon the question for every website owner was simple: how long until my server is patched?
What we did on the day
We host and look after 200+ websites on servers we manage, so this was our job, not our clients’. In short:
- Protection went on straight away. Before the patched versions were even available for our servers, we applied the temporary protection from PHP’s own advisory everywhere, and switched off older PHP versions that will never be fixed.
- Every site was patched the same evening, as soon as the fixed versions reached us.
- WordPress was brought up to date too. It doesn’t fix PHP2Shell, but on a day like this you close every door you can.
- Nothing broke. Every site was checked before and after each change, and they all came back as they should.
Checking nobody got in first
Patching closes the door. It doesn’t tell you whether somebody walked through it before it was shut. So once everything was patched, we went back over every server, starting from 18 October, before the details leaked:
- Every changed file was traced to something legitimate: a plugin update, a release we’d made, a normal build. Anything that looked like the kind of code attackers leave behind was matched byte for byte against the official published copy, or traced to the update that put it there.
- Every WordPress site’s core files were checked against WordPress’s own official copies.
- No new administrator accounts had appeared on any WordPress site.
- No unexpected programs, scheduled jobs, user accounts or access keys were found on any server.
We found nothing. That’s the boring answer, and it’s the one you want.
The part that was already in place
The response on the day mattered, but so did work that had nothing to do with PHP2Shell and was done before anyone had heard of it.
- Sites kept apart. In the weeks before, we’d been separating the sites we host from each other, so that a problem on one site can’t reach its neighbours. On a shared server, that’s the difference between one bad day and two hundred.
- Backups out of reach. Earlier in October we moved every backup somewhere no website can read or touch. A compromised site can’t get at them, which matters both for your data and for getting back up quickly if the worst happens.
- Attacks already being watched. We see a steady stream of automated attacks across the sites we host: around 33,000 blocked in a single day when we last counted, which we wrote about in our post on negative SEO. A day like Wednesday isn’t the first time anyone has looked.
None of that stops a flaw in PHP itself. What it does is limit what an attacker could do with one, and make it quicker to be sure they didn’t.
If your site isn’t with us: what to ask your host
If someone else hosts your website, it’s worth an email today. You’re entitled to straight answers to these:
- Which PHP version is my site running, and is it patched? You’re looking for 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer.
- If it’s PHP 8.1 or older, what’s the plan? Those versions no longer get official fixes. CISA’s advice is to take such systems offline until they’re updated. At the very least, ask for a date to move your site to a supported version.
- When was it patched? “At some point this week” isn’t the same as “Wednesday evening”, given that attacks were reported on the day.
- Has anyone checked for signs of compromise since 18 October? Patching doesn’t undo anything that happened before it.
And on your side:
- Check your WordPress users for any administrator you don’t recognise.
- Update WordPress, your theme and your plugins. It won’t fix PHP2Shell, but it closes the doors attackers try once they’re in.
- If your site has gone slow, started redirecting strangely or sending odd emails, tell your host straight away.
If you get vague answers, or none, that tells you something too. We’re happy to take a look at where your site stands. If it’s on an old version of PHP, moving it somewhere safer doesn’t mean losing what you’ve built: our website migrations page explains how we move sites without losing their search rankings.
The wider lesson
Most of the time, hosting is invisible. That’s the point. You only find out whether yours is being looked after on days like 21 October, when the answer to “are we OK?” has to come in hours, not weeks.
When we audited 100 Dundee business websites for our Dundee Digital Benchmark, 32 of them didn’t send any of the basic security headers that tell a browser how to protect visitors. Those are a five-minute fix. If the small, easy things are missing, it’s fair to wonder who’s watching the big ones.
It’s also why the alerts chapter of our free guide, The Business Owner’s Morning, argues that the best line on your morning screen is the boring one: nothing broke overnight.
If you’d like your website looked after like this, with the patching, the checking and the boring mornings, have a look at our hosting and support, or tell us what you’ve got.
Sources: CISA alert, 21 October 2026 · PHP security advisory (php.net) · Tenable PHP2Shell FAQ · Help Net Security
Got a problem like this? Good. We like those.
Tell us what you’re dealing with and we’ll tell you honestly what we’d do.
