The October 2026 PHP vulnerability: is your WordPress site affected?

On 21 October 2026 the PHP project fixed two critical security flaws. PHP is the programming language WordPress is built on, so if your website runs on WordPress this is about your site, even though the flaw is not in WordPress itself.

It matters to trades because so many trade websites run on WordPress. In our study of UK trade websites, 52.9% of the 19,359 sites whose platform we could identify were built on WordPress.

Updating WordPress will not fix this one. The fix has to be made on the server, which usually means your web host. Below is what happened, how to check your own site in a couple of minutes, and what to send your host.

One thing to be straight about first: we sell website care plans, and they cover WordPress sites, so we have an interest here. Every fact below comes from the PHP project's own advisory, WordPress.org, the UK's National Cyber Security Centre (NCSC) and Canada's Cyber Centre, all read on 25 October 2026.

What the PHP vulnerability is

PHP runs on the server behind your website. WordPress, your theme and your plugins are all written in it, so a flaw in PHP sits underneath all of them.

• Two flaws, both rated critical. They are known as CVE-2026-109618 and CVE-2026-109619, and both score 9.2 out of 10 on the standard severity scale.
• What an attacker could do. Under certain conditions, run their own code on your server without logging in. In plain terms, take over the website.
• When it happened. PHP gave advance notice on 20 October and released the fix on 21 October.
• What it is called. Some write-ups call it PHP2Shell, the name the Dutch NCSC uses for its list of affected products.
• Who is at risk. PHP says every installation serving web pages, whichever way the server runs PHP, with the risk highest on servers using Apache with mod_php.
• It is not a WordPress bug. WordPress.org says the flaws affect any server running PHP, and that no WordPress update is required or planned.

Is anyone using it yet?

Attempts have started. WP Engine, a large WordPress host, said on 22 October that its firewall blocked more than a million related requests in the first 24 hours, and that it had seen no successful attacks.

In its alert, updated on 23 October, Canada's Cyber Centre said that attack code proving the flaw works is available, with no active exploitation identified "at this time, but that can change quickly."

Is your business affected?

Work through these in order. If step three shows your version is already fixed, you can stop there.

1. Is your website on WordPress?

If you log in to edit your site by adding /wp-admin to the end of your web address, it is WordPress. If someone else built it and you are not sure, ask them.

If your site is on a builder such as Wix or Squarespace, the platform runs the servers, so there is nothing here for you to update.

2. Which PHP version does it run?

1. Log in to WordPress.
2. Go to Tools, then Site Health, then the Info tab.
3. Open the Server section and find PHP version.

Many hosts also show the PHP version in their control panel.

3. Compare it with this table

If your PHP version starts with	It is fixed from
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 or lower	No fix from the PHP project

So 8.3.36 is fixed and 8.3.30 is not. One caution: some hosts and Linux suppliers apply the fix to an older version of PHP, which PHP calls a backported fix. A lower number is a reason to ask your host, not proof that your site is exposed.

4. If it says 8.1 or lower

The PHP project no longer fixes PHP 8.1 or anything older, and about a third of WordPress sites are in that position: 34.0% report PHP 8.1 or older in WordPress.org's own figures.

Ask your host whether they have a backported fix, and plan a move to a supported version. PHP 8.2 itself stops getting security fixes on 31 December 2026, so if you are moving anyway, 8.3 or newer saves doing it twice. Check that your theme and plugins support the newer version first.

5. Who hosts it?

Managed WordPress hosts usually look after PHP for you, and some have already said they are done. WP Engine told customers on 22 October that every customer site was on a fully patched version and that they did not need to do anything.

On cheaper shared hosting, check your host's status page, or ask them directly using the message below.

How to fix it yourself

For most trades, fixing it means getting your host to update PHP, then checking that they have. This is the order we would do it in.

1. Write down your PHP version using the steps above.

2. Ask your host. Copy this into an email or a support chat:

   Hello, my website is [your web address]. Has the server it runs on been updated for the PHP security release of 21 October 2026 (CVE-2026-109618 and CVE-2026-109619)? Site Health shows PHP [your version]. If it has not been updated yet, when will it be?

3. If your host lets you choose the PHP version, you can change it yourself. In cPanel the setting is called MultiPHP Manager, if your host has switched it on: tick your domain, pick a version from the PHP Version menu and click Apply. Take a backup first, because an old theme or plugin can stop working on a newer version. Choosing a newer version only helps if your host has updated it, so check the full number in Site Health again afterwards. Then make sure the site loads, the quote form sends and your phone number still taps to call. If you are not sure, ask your host to do it.

4. Update WordPress while you are logged in. It does not fix the PHP flaw, but WordPress put out three security releases between 17 September and 6 October: 7.1.1, then 7.1.2, which fixed a critical vulnerability, then 7.1.3 on 6 October with seven more security fixes. If your site updates itself, it may already be on 7.1.3; Site Health shows the version under WordPress. If not, go to Dashboard, then Updates, and click Update Now. Then update your plugins and theme, and delete any you no longer use.

5. Look for signs the site has already been hacked. WordPress's own list of clear signs includes:

   • Google or Bing warning people away from your site
   • your host disabling the site
   • visitors' antivirus software flagging it
   • new users, or other changes nobody on your side made
   • pages that look visibly wrong when you open them

   If you see any of these, contact your host. Then change every password: WordPress, your hosting control panel, FTP and the database. Once the site is clean, change them again.

6. If nobody can update the server. This is rare for a trades website, but if yours runs on a server that you or a friend manage and it cannot be updated, the NCSC's advice is to consider taking it offline until it is fixed. PHP has published temporary settings that reduce the risk without removing it; pass its advisory to whoever runs the server.

What will not fix it

• Updating WordPress, your theme or your plugins. Worth doing, as above, but the flaw is in PHP underneath them.
• A security plugin on its own. A plugin runs inside PHP, so it cannot update PHP. Firewall rules from your host or a security service can block known attacks, which helps, but PHP is clear that only an update is a complete fix.

Should you move off WordPress?

Not because of this. The flaw is in PHP, which sits under far more than WordPress: the Dutch NCSC keeps a list of other affected products.

The better question is who is looking after your site. A WordPress site needs its core, theme, plugins and server kept up to date, regularly. If that is happening, this week was an email to your host. If nobody is doing it, that is the thing to fix, whatever the site is built on.

Do you need help?

If you would rather not do any of this yourself, get in touch with your web address and tell us what you are seeing. If you think the site has already been hacked, tell us that first, because it changes what we look at.