Critical PHP flaw: is your WordPress site safe?

If you look after a WordPress website, you may have seen some worrying headlines this week about a security flaw in PHP. First things first: don't panic. It is a serious one, but for most site owners the answer is straightforward, and it starts with a 30-second check you can do yourself.

Here is what has happened, in plain English, and what to do about it.

What is PHP, and why does WordPress care?

PHP is the programming language WordPress is written in. Every time someone visits a page on your site, PHP runs on your web server to build that page for them. The same goes for WooCommerce, Drupal, Joomla, Magento and Laravel, which is why this story is bigger than WordPress alone.

The useful thing to know is that PHP is not part of your WordPress install. It belongs to the server your site lives on. That distinction decides who has to do what, and we will come back to it.

So what happened?

The PHP project has released emergency fixes for 2 serious security holes in the language itself. You may see them referred to by their reference numbers (CVE-2026-109618 and CVE-2026-109619) or by the nickname PHP2Shell.

Both are what security people call "remote code execution" flaws. In everyday terms, an attacker could send a specially crafted request to a vulnerable server and run their own code on it, from anywhere in the world, without needing a login.

That is why it is being taken so seriously. A flaw like this can lead to a defaced site, stolen customer data, malware or spam being slipped into your pages, or your server being used to attack other people. Researchers have also shown that it can be used to gain full access to a servers filesystem, including files where things like database passwords and API keys live potentially leading to exploits in other systems or leaks of sensitive customer data.

On the industry severity scale (CVSS), both flaws score 9.2 out of 10. Anything over 9 counts as critical.

And because the flaws sit inside the PHP engine rather than in any particular plugin or theme, a site can be exposed even if its own code is spotless. Researchers have demonstrated it against fully up-to-date copies of WordPress, Drupal, Joomla and Magento.

Details leaked before the fix was ready, which is why the patch was rushed out as an emergency release. Once a fix is public, attackers can compare the old code with the new code to work out how to exploit it, and Cloudflare reported seeing attempts before the patch had even landed. So this is one to deal with this week, not next month.

Which versions are fixed?

The fixes shipped in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. If your server is on PHP 8.2 or newer, moving to the patched release is the whole fix, and your host will usually do it for you.

PHP 8.1, 8.0 and 7.4 are out of support, and the official position from the PHP project is that they will not be patched. Some hosting companies have said they are working on their own fixes for those older versions, so it is worth asking yours. But the only complete answer for a site on an unsupported version is to move it to a supported one.

This is the bit that catches WordPress sites out. A surprising number are still running PHP 7.4 or 8.0. Not through neglect, usually. More often an old theme or plugin broke the last time somebody tried to move to a newer version, and the site was quietly left where it was.

How do I check which PHP version my site is on?

Good news: you don't need any technical access, just your WordPress login.

1. Go to Tools, then Site Health.
2. Click the Info tab.
3. Open the Server section. The PHP version is listed there.

If it says 8.2, 8.3, 8.4 or 8.5, you are in good shape. Your host should be applying the patch, and the only question to ask them is whether it has been done yet. If it says 8.1 or anything lower, your site needs to move to a newer version of PHP, and that is a slightly bigger job.

Your hosting control panel will usually show the same information, and most hosts have a setting to switch PHP version. Please don't just flick that switch on a live site, though, for reasons explained next.

Your host updates PHP. Your site still needs updating.

Remember the distinction from earlier? The PHP version is a server-level setting, so it is your hosting company who updates it. Good managed hosts, WP Engine among them, were ready to apply the patches the moment they were released.

But a host can only patch the version you are on. If that version is 7.4 or 8.1, there is nothing for them to apply. The site has to move to PHP 8.2 or newer, and that only works if WordPress core, your theme and every plugin are happy running on it. A plugin that was last updated in 2021 may well not be. Switch PHP underneath it and the site goes down, or bits of it stop working in ways you only notice later.

So the sensible sequence for a site on old PHP looks like this:

1. Take a full backup.
2. Set up a copy of the site (a staging site) on the newer PHP version.
3. Update WordPress core, the theme and every plugin. Replace any plugin that has been abandoned and will not run on modern PHP.
4. Test the copy properly: forms, checkout, logins, anything custom.
5. Only then switch the live site over.

WordPress lists every waiting core, theme and plugin update in one place: Dashboard, then Updates. If that page has been showing a long list for a while, it is a fair bet the site is on an older PHP version too.

For a simple site that is a few hours' work. For a complex WooCommerce store with a lot of plugins it can be a few days. The nice part is that it only needs doing once, as long as the site is kept current afterwards.

What if I can't update straight away?

There are some partial mitigations, and your host may already have applied them. Blocking multipart requests at the web server level, and turning off PHP's session upload progress feature, each close off one of the known ways to trigger the flaws. Neither is a complete fix. They buy you time, nothing more, and they can break legitimate features like file uploads. Updating PHP is the only full answer.

A quick checklist for WordPress site owners

• Find your PHP version in Site Health (Tools, Site Health, Info, Server).
• On 8.2 or newer: ask your host to confirm the patched release is applied.
• On 8.1 or older: plan a move to a supported version, tested on a staging copy first.
• Update WordPress core, theme and plugins regardless. Out-of-date plugins are what stop PHP upgrades happening.
• Check your backups actually exist and can be restored.
• Make sure someone is responsible for keeping the site current from here on. This won't be the last PHP security release.

Where we stand

The sites we host and look after sit on managed hosting that was patched as soon as the fixes went out, and our web team spent the day moving the handful still on older PHP across. If your site isn't one we look after and you would like a hand working out where it stands, we are offering a free same-day WordPress check while this is live: clicky.co.uk/lp/wordpress-security.

Either way, do check your PHP version today. It takes 30 seconds, and it is the one piece of information that tells you whether you have anything to worry about.