There’s a bit of software under your website that you probably never think about, and on 21st October it had a very bad day. If your site runs on WordPress, it runs on PHP.
The PHP project released fixes for a serious PHP vulnerability that day, two flaws in fact. Updating WordPress won’t fix them. A few things are worth checking now.
What actually happened
The flaws are tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 for severity. In plain terms, they can let someone who isn’t logged in make your server run code of their choosing. That’s called remote code execution, and it’s about as bad as website security problems get. Once someone can do it, they can steal data or plant malware on your site.
The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP Foundation’s release post has the full timeline. Details got out before the planned release, and Cloudflare reported attacks on the morning of the 21st, before the fix was public.
Is my WordPress site affected?
The flaws sit in PHP itself, underneath WordPress, your theme and your plugins. WordPress.org has said no WordPress update is needed. The fix has to happen on the server.
The PHP project only releases updates for 8.2 and newer. Anything older than the fixed versions should be treated as exposed. If you’re on 8.1 or older there’s no official fix for your version. Some hosts and server vendors backport patches themselves, but the proper answer is a supported version.
How to check your PHP version
In your WordPress dashboard, go to Tools, then Site Health, then the Info tab, and open the Server section. It shows the PHP version. Your hosting control panel will usually show it too.
Some hosts patch PHP without changing the version number, so an older-looking number doesn’t always mean you’re exposed. The reliable move is to ask your host directly: “Have you applied the 21st October PHP security release to my server?”
Who does what depends on your hosting:
- Managed WordPress hosting: the host patches PHP for you. Check their status page or ask support to confirm.
- Shared hosting: the host rolls the patch out. If you’re on 8.1 or older, see whether your control panel lets you pick a newer version.
- A VPS or your own server: nobody does it for you. The updated PHP packages need installing and PHP restarting so every worker runs the fixed version.
If you manage your own server and can’t patch today, Codeable’s guide suggests setting session.upload_progress.enabled to 0, which blocks one of the known attack paths for the second flaw. WordPress core doesn’t use that feature, so switching it off shouldn’t affect your site. The setting doesn’t close every route in, so treat it as a holding measure until the update is on. On shared or managed hosting, leave this one to your host.
If you’re on an old version of PHP
This is where it gets awkward. Plenty of small business sites are still on PHP 7 or 8.0 or 8.1, usually because nobody wanted to touch something that was working. Old versions don’t get fixes, so the choice is to upgrade or carry the risk.
Aim for 8.3 or newer. PHP 8.2 got this patch, but its security support is due to end on 31st December 2026, so moving to it now means doing the job again within weeks.
The catch is that old sites often have old themes and plugins, written for the PHP of their day. Jump to a much newer PHP and a plugin that was fine before can start throwing errors.
Will a PHP upgrade slow down or break my site?
Newer PHP versions are usually a bit faster than old ones. On most small sites you won’t notice much, so don’t upgrade for the speed alone. If you do want to look at that side, we’ve written about why website speed matters.
Breaking is the bigger risk. The usual suspects are a plugin that hasn’t been updated in years or a theme with custom code written for an older PHP. Checkouts, booking forms and members areas can also quietly depend on behaviour PHP has since removed.
Sometimes you get a few warning messages at the top of a page. Sometimes it’s a blank white screen, or WordPress telling you there’s been a critical error. Forms that stop sending are the sneaky one. Nothing looks broken until someone mentions they never heard back.
How to upgrade without a nasty surprise
- Take a full backup, and make sure you can actually restore it. A backup stored only on the same server won’t help if the server is the problem.
- Get WordPress, your theme and your plugins updated first. Many compatibility problems are already fixed in newer releases. This is the step to hand to a developer, so there’s a rollback ready if an update causes trouble and someone to jump on any issues that come up.
- Test on a staging copy of the site if you have one. Click through the pages that earn you money: contact forms, checkout, bookings, login.
- Switch the live site over at a quiet time of day, and check those same pages again straight afterwards.
- Keep the old PHP version available for a short while so you can switch back if something unexpected turns up.
What to do if the site breaks
Don’t start deleting plugins at random. You can lose settings or end up with a plugin you can’t put back the way it was.
If you can, switch PHP back to the previous version in your hosting panel. That usually brings the site straight back and buys you time. Then get in touch with whoever built or looks after the site. The fix is usually an outdated plugin that needs updating or replacing, or a bit of theme code that needs patching. Occasionally a feature has to be rebuilt because it relied on something abandoned. It’s a much calmer job when the site is back up and nobody’s panicking.
If you don’t have a developer, or the person who built your site has moved on, that’s the kind of job we pick up. We can work out what isn’t compatible and sort it. There’s more about what we do on our WordPress page.
Keeping PHP on your radar
This won’t be the last PHP flaw. A few habits make the next one a non-event.
- Know your PHP version and put its end-of-life date in your diary. Every PHP version has one, and it’s published on php.net.
- Ask your host how quickly they patch the server. This week was a good test of that.
- Delete plugins and themes you don’t use. The files of a deactivated plugin are still on your server, and can still be attacked.
- Keep WordPress, plugins and themes updated, and have a developer do it. Small regular updates hurt far less than one enormous catch-up. Our guide to WordPress maintenance covers how often.
There’s more on the wider picture in our no-nonsense WordPress security guide.
What to do today
Check your PHP version. Ask your host if the 21st October fix is on your server. If you’re on 8.1 or older, book the upgrade in properly. And if you’d rather someone else looked, get in touch about the PHP vulnerability and we’ll look at your site, then either do the PHP upgrade or fix anything the upgrade has broken.
Questions people are asking about the PHP update
No. The flaws are in PHP, which sits underneath WordPress, so a WordPress update doesn’t fix them. The fix has to be applied on the server, either by your host or by whoever manages the server. It’s still worth keeping WordPress, plugins and themes up to date for everything else, ideally through a developer who can roll back if an update causes problems.
In the WordPress dashboard, go to Tools, Site Health, Info, then open the Server section. Your hosting control panel usually shows it as well. Some hosts patch PHP without changing the version number, so it’s also worth asking them directly whether the 21st October security release has been applied.
If you’re on a supported PHP version (8.2 or newer) and your host has confirmed the fix, you’ve done what you need to for this one. If you’re on 8.1 or older, ask what exactly was patched and plan a move to 8.3 or newer, because older versions don’t get official fixes. PHP 8.2 itself loses security support at the end of 2026.
A little, usually. Newer PHP versions tend to be quicker than old ones, though on most small sites the difference is small. The bigger risk is compatibility. Outdated plugins and themes can break on a newer PHP, so test on a staging copy before you switch the live site.
Switch PHP back to the previous version in your hosting control panel to get the site working again, then ask your developer or web agency to find the incompatible plugin, theme or code and fix it. Avoid deleting plugins at random while you’re trying to diagnose it.
