Two critical PHP bugs were fixed today. Every site I host was patched by half past four

If you're one of my hosting clients, here's the short version: two serious security holes in PHP were made public at 3pm today. By 4:30pm every site I host was running the fixed version. You don't need to do anything.

If you'd like to know what the fuss was about, read on.

What PHP is, and why this matters to you

PHP is the programming language that runs WordPress and WooCommerce. Roughly three quarters of the websites in the world sit on it, including most of the ones I build and look after. It's not something you ever see. It's the engine under the bonnet.

So when the PHP team announces an emergency fix for the engine itself, rather than for a plugin or a theme, it's a big deal. There's no "only affects sites that use X" to hide behind. If your site runs PHP and takes requests from the internet, it's in scope.

The two bugs, in plain terms

Both have been given the nickname PHP2Shell by the security crowd, because both let an attacker go from sending your website a web request to running their own commands on the server. No login. No password guessing. No dodgy plugin needed. One carefully built request, before your site's own code even gets a look in.

The first one (CVE-2026-109618) is a problem with how PHP copes when it runs out of memory. Every request your site receives gets a little bit of memory set aside for it. If an attacker can make PHP run out part way through setting that up, PHP gets interrupted with the job half done. It then tidies up as though the job had finished properly, and that mismatch is the crack an attacker can lever open.

The second one (CVE-2026-109619) is about leftovers. PHP keeps a handful of worker processes running and reuses them, one request after another. Some information from a request was surviving after its memory had been handed back, and the next request through the same worker could pick it up before everything was reset. Think of a hotel room where the previous guest's key still opens the safe.

Both are rated 9.2 out of 10 on the severity scale. Both are "critical", which is the top band. A working exploit was demonstrated before the fixes were even out, which is why the PHP team pulled the release forward by a day after details leaked on Monday.

What happened on my side

I run my own servers rather than renting space from a big host, which I've written about before. Days like today are the reason.

The servers are managed with a tool called FlyWP, and the FlyWP team said they'd push the patched PHP builds to everyone and let us know once it was done. That's the right thing for them to do. It's also not something I was prepared to wait for with a critical, unauthenticated bug and a working exploit in the wild.

So the moment their patched builds appeared on GitHub and Docker Hub, I went round and did it myself.

The timeline, UK time:

• Monday evening. The PHP security team posted an advance warning that two critical fixes were coming, originally on Thursday.
• Tuesday. Details leaked, the embargo was brought forward, and the release was scheduled for 3pm Wednesday.
• 3pm today. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were published.
• Shortly after. FlyWP's rebuilt PHP images landed on GitHub and Docker Hub.
• By 4:30pm. I'd pulled the fixed builds onto every server, recreated the PHP container for each site by hand, and checked them one by one. Thirty-odd sites, all answering, all on patched versions.

Each site was offline for about a second during its restart, in the middle of a Wednesday afternoon. Nobody noticed, which is the point.

For the technically curious: every site runs PHP in its own Docker container, so the update is a case of fetching the new image and recreating the container. The site's files and database aren't touched. That's a large part of why I set things up this way, and why the whole estate can be done in an hour and a half rather than an afternoon of logging into individual servers and hoping.

When FlyWP's own notice arrives, it'll find there's nothing left for it to do.

What this looks like if you're hosted elsewhere

It's worth asking your host, politely, what version of PHP your site is on. If the answer is 8.4.27, 8.5.12, 8.3.36 or 8.2.35 (or a vendor build that says it includes the fix for CVE-2026-109618 and 109619), you're fine.

If the answer is a version of PHP 8.1 or older, you have a harder conversation ahead. Those versions reached end of life some time ago. The PHP team has published minimal backported fixes for 7.4, 8.0 and 8.1 as a goodwill gesture, but whether your host applies them is up to them. Same goes for "I'll check and get back to you" with no date attached.

If you're not sure who your host even is, or the last person who touched the site has moved on, drop me a line. I can usually find out in ten minutes.

The bit nobody tells you about hosting

Most of what I do for a hosting and care client is invisible. Backups that run every night. Updates that go through on a Tuesday. Monitoring that pings me if a site takes longer than it should to answer.

Then, two or three times a year, something like today happens and the job is suddenly very visible for about ninety minutes. It's the same job. It's just that today you can see it.

I'll update this post if anything changes. For now: patched, checked, done.

Sources: PHP2Shell: critical PHP vulnerabilities patched (Help Net Security) · Rapid response: php2shell (Huntress) · PHP major vulnerability alert (Patchstack)