PHP is patching two critical flaws. Here's what we're doing about it.

The short version for our customers

We're onto it. Every site we host runs on a supported version of PHP that is covered by this release. As soon as the patched build is available we'll roll it out to every site and check each one afterwards. Your site will restart for a few seconds while that happens, and that's all you should notice. There's nothing you need to change, install or update.

We'll update this post once every site is patched.

What's been announced

On 20 October the PHP security team announced a release for Wednesday 21 October at 14:00 UTC. That's midnight on Thursday 22 October in Brisbane, 1am in Sydney and Melbourne, and 10pm Wednesday in Perth. It fixes two vulnerabilities, each scored 9.2 out of 10 (CVSS v4.0), which puts them in the critical band.

That's all the official notice says. The details, the affected versions and the fixed versions will be published with the release itself. The team has said it may release early if the details become public first or if anyone is seen exploiting the flaws.

Advance notice like this is unusual for PHP. Normally a security fix simply turns up in the next scheduled release. Announcing a time ahead, for two critical issues, tells you the team wants everyone ready to move quickly.

What we don't know yet

Reports are going around with CVE numbers, a higher severity score and claims about which versions are affected. Some say an exploit has leaked. None of that has come from the PHP project, so we're not treating it as fact. We're planning for the worst reasonable case: a flaw that could let someone run code on a site without logging in.

So far nobody credible has reported these flaws being used in real attacks. That usually changes soon after a fix ships. Once the fix is public, anyone can compare it with the old code and work out what was wrong. The days straight after a patch are when unpatched sites are at the most risk.

How we'll patch it

Each site we host runs in its own container, with PHP built in. Patching doesn't mean logging into servers and upgrading packages by hand. It means moving every site onto a new build of the same PHP version:

• We wait for the patched build, then check it. We confirm the new build really carries the fixed PHP version before it goes anywhere near a customer's site. Restarting a site onto a build that only looks new would fix nothing.
• Your site doesn't change. WordPress, your plugins, your theme, your uploads and your database all stay exactly as they are. Only the PHP underneath is replaced.
• Every site is checked afterwards. We load each site's real homepage once it's back up, and we follow up on any site that doesn't return a proper page.
• Same version, so no surprises for your plugins. This is a patch within the PHP version you're already on, not a jump to a new one. Your plugins see the same PHP they saw yesterday, minus the flaw.

If your site is hosted somewhere else

The question to ask your host is simple: which PHP version is my site on, and is it still supported?

• PHP 8.2 and newer still get security fixes and should be covered by this release, once your host applies it.
• PHP 8.1 and older are end of life. 8.1 stopped getting security fixes at the end of 2025, and 7.4 well before that. If these flaws reach back that far, those versions will never be fixed. Plenty of WordPress sites still run on them, often because nobody has checked.
• On shared hosting, you're waiting on your host. You can't patch PHP yourself there. If your host hasn't said anything by the end of the week, ask them.

You can see which version you're on in WordPress admin, under Tools then Site Health then Info, in the Server section.

Updates

• 21 October 2026: Release announced. We've confirmed every site we host is on a version that will get the fix, and we're watching for the patched build.