Last week the PHP project shipped emergency fixes for two critical security flaws, now known as PHP2Shell. If your website runs on WordPress, it runs on PHP, and this was one of those rare moments where keeping WordPress and its plugins up to date did nothing to protect you. The fix had to be applied to the server itself.
All the sites on our main hosting platform were patched by 2:44pm on Thursday 22 October, less than 14 hours after the fix was released, and they were protected by temporary measures for most of the time in between. Sites with our other hosting suppliers were patched over the following weekend. Here’s what happened, what it cost our clients in the meantime, and the question every business owner should be able to answer about their website after a week like this.
What actually happened
On Tuesday 20 October (US time), the PHP security team gave advance notice of a release fixing two vulnerabilities, both rated 9.2 out of 10 for severity. Details leaked online within hours, and the fix arrived on schedule at 14:00 UTC on Wednesday 21 October. In Australia, that was 1am Thursday.
The two flaws, CVE-2026-109618 and CVE-2026-109619, allow what’s called unauthenticated remote code execution. In plain terms, an attacker could run their own code on your web server without logging in to anything. That’s about as serious as website vulnerabilities get. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP’s own release notes didn’t soften it.
“There are no complete mitigations, updating is the only safe choice.” PHP release notes, 21 October 2026.
Why updating WordPress didn’t help
It’s worth understanding how a website is put together, because it explains why this one caught people out.
A WordPress site is a stack of layers. At the bottom is the server, run by your hosting provider. On top of that sits PHP, the programming language that does the work every time someone loads a page or submits a form. WordPress runs on PHP, and your theme and plugins run on WordPress.
Most website maintenance conversations focus on the top layers: WordPress core updates and plugin updates. Those matter, and they’re where most WordPress security problems come from. But PHP2Shell sat a layer below. As Wordfence pointed out in their analysis, updating WordPress, a plugin or a theme doesn’t update PHP. Your site could have looked perfectly up to date in the WordPress dashboard and still been exposed.
There’s a second catch that’s easy to miss. Installing the patched PHP version isn’t the end of it. Wordfence’s advice was to restart every PHP worker after updating, because processes that are already running keep using the old code until they’re restarted. A server can report the new version and still be serving pages with the vulnerable one.
What our hosting partner did overnight
Our main hosting supplier, which looks after the majority of the sites we manage, didn’t sit and wait for the patch. They posted their first notice at 2:04pm on Wednesday, half a day before the release. By 4:31am Thursday, following the PHP Foundation’s recommended advice, they had extra protections in place across their shared and managed servers, restricting form submissions and file uploads.
That sounds drastic, and it was. Enquiry forms, quote requests and anything with an upload field were affected for around ten hours, most of them overnight and early morning. In practice, only a very small number of our clients noticed their forms playing up during that window. But even if more had, it was the right call. The attack traffic Wordfence recorded was aimed at the part of PHP that processes form data and file uploads, so closing that door bought time until the proper fix could go on.
The rest of the morning was the slow part. Their platform vendor confirmed patches at 9:40am, the first patched builds were being tested by 11:16am, and the rollout across all servers was under way by 1:15pm. At 2:44pm the patches were on, the restrictions came off, and that was that.
A few hours without contact forms is an inconvenience. A compromised server is a very different conversation.
I’ll admit a morning without enquiry forms isn’t nothing for a business that depends on them. But weighed against someone running code on your server, it’s an easy trade to make.
How serious did it get?
So far, the news is reassuring. Wordfence, which protects more than five million WordPress sites, reported no confirmed compromises from these flaws as of 22 October. They put that down to how complex the exploit is to pull off.
That’s not the same as nobody trying. Wordfence’s firewall blocked more than 74,000 exploit and probing attempts in the first few days, climbing from around 1,200 on 20 October to more than 44,000 on 21 October as the details spread. Proof-of-concept exploit code is now public, which means the attempts will keep coming and get more refined. Any server that still isn’t patched is a target, and will stay one.
Closer to home, we’ve seen no evidence of any issues across the 300 websites we host, beyond those few form hiccups on the Thursday morning.
The question to ask about your website
Because PHP2Shell made the mainstream news, something happened last week that I haven’t seen before in over 25 years of doing this. I’ve never had so many clients check in about a security issue. Nearly every message came down to the same two questions: are you on top of it, and were we affected?
That’s exactly the right instinct, and I was glad to be asked. It also showed me how few business owners know the answer without picking up the phone. Every business owner should be able to answer the question underneath it for themselves: who is responsible for patching the server my website runs on, and how fast do they move?
For a lot of businesses, the answer is “not sure”. The website was built by one company, it’s hosted by another, someone in the office logs in to update plugins now and then, and nobody’s ever been asked to own the server layer. That gap is exactly where an event like PHP2Shell does its damage.
Here’s what to check, or to ask your web team:
- Which PHP version is your site running? In WordPress, go to Tools, then Site Health, open the Info tab and expand the Server section. The official fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. One catch: some hosting platforms apply the fix to the version you already have, so a patched server can still show an older number. Our main host is one of them. If your number looks old, ask your host before you panic.
- Who updates PHP on your server? On shared or managed hosting it’s usually the host. On a VPS or your own server, it’s whoever manages it. If that’s nobody, it’s you.
- Were PHP workers restarted after the update? It’s worth a direct question to your host or developer.
- Is your site on an unsupported version? PHP 8.1 and older don’t receive official security fixes. Some hosting platforms, including ours, backported this fix to versions as old as PHP 5.2, but that’s a favour from your host, not something to plan around.
- Is PHP 8.2 on your radar? It reaches end of life on 31 December 2026, only a couple of months away. Moving to a newer version needs compatibility testing, so now is the time to plan it.
Speed is now part of the service
We’ve been building and looking after websites since 2000, and one pattern hasn’t changed much in that time. The serious problems rarely come from the layer everyone’s watching. They come from the layer nobody owns.
What has changed is the pace. This vulnerability went from advance notice to leaked details to public exploit code in a couple of days. The window between a fix being released and attackers testing it against real websites is now measured in hours. A maintenance plan that checks in once a month was built for a slower world.
That’s the competitive point for business owners. Your website takes enquiries while you sleep, and its security can depend on someone acting quickly at 1am on a Thursday. The businesses that came through last week without a problem had someone who owned the whole stack, and a hosting partner willing to make an unpopular call overnight.
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the name given to two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Both are rated 9.2 out of 10 and can allow an attacker to run code on a web server without logging in. They affect PHP itself, so they apply to WordPress sites and most other PHP-based websites.
Does updating WordPress fix PHP2Shell?
No. The vulnerabilities are in PHP, the language WordPress runs on, not in WordPress, plugins or themes. PHP has to be updated on the server to version 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a patched build from your host), and PHP workers restarted, before a site is protected.
How do I check which PHP version my WordPress site uses?
In your WordPress dashboard, go to Tools, then Site Health, open the Info tab and expand the Server section. If you can’t see it or aren’t sure what the number means, ask your hosting provider or web team. Some hosts patch the version you already have, so the number alone won’t always tell you whether the October 2026 fix has been applied.
What if my site is on PHP 8.1 or older?
PHP 8.1 and older versions no longer receive official security fixes from PHP. Some hosting platforms backported this fix to older versions, but you can’t count on that next time. The safe path is upgrading to a supported version, which needs compatibility testing of your theme and plugins first. PHP 8.2 also reaches end of life on 31 December 2026.
Not sure who’s looking after your server?
If you don’t know which PHP version your site runs, or who’s responsible for patching it, we’re happy to check. Our website support, security and maintenance service covers the whole stack, not just the plugins. Get in touch with the team and we’ll tell you where you stand.
