PHP2Shell: the emergency PHP update WordPress can’t install for you

When wp2shell hit WordPress in July, WordPress.org pushed the fix out automatically and most sites were patched without anyone lifting a finger. Today’s emergency PHP release won’t work like that.

The two flaws sit in PHP itself, the engine underneath WordPress and most other website software, rather than in WordPress, a theme or a plugin. Nothing in your WordPress dashboard can fix them. Whoever runs your server has to.

Most of the coverage is written for server administrators. This guide is for everyone else: business owners, marketing teams, office managers and anyone who owns a website without running the server it sits on. By mid-afternoon the story had reached the BBC, so expect questions from colleagues and trustees.

What is PHP2Shell?

On Tuesday evening the PHP security team gave advance notice of an urgent security release fixing two critical vulnerabilities, both rated 9.2 out of 10 on the CVSS v4.0 severity scale. Anything from 9.0 upwards is classed as critical. The team said it would publish the full details, affected versions and fixed versions with the release, and urged users to “prepare now”.

Details had already leaked. Security firm watchTowr told BleepingComputer the flaws are real, that both are remote code execution bugs (meaning an attacker can run their own code on your web server), and that they’re believed to affect versions going back to PHP 5. It also said it had reproduced one of them, but hadn’t seen either being exploited in the wild.

A screenshot of an exploit tool called PHP2Shell, credited to security firm Calif, leaked alongside the news, which is where the nickname comes from. Ecommerce security firm Sansec expected mass attacks to begin within 15 minutes of the fix going public. Once a patch is out, attackers can compare it with the old code to work out how to break into sites that haven’t updated. The EU’s cyber security service, CERT-EU, and the UK’s National Cyber Security Centre are both advising organisations that can’t patch straight away to consider taking affected systems offline until they can.

What PHP published at 3pm

The release landed on schedule. PHP’s security advisory confirms both CVE numbers and explains the flaws. In plain English: one (CVE-2026-109618) lets an attacker deliberately make PHP run out of memory part-way through handling a request, leaving it in a confused state it then trusts. The other (CVE-2026-109619) lets leftovers from one request survive into the next request handled by the same worker process. Either way, a single request from a stranger, with no login, can end in their code running on your server.

PHP’s own words on the workarounds: “There are no complete mitigations, updating is the only safe choice.”

Is your website affected?

Yes, if your site runs on PHP and hasn’t been updated since 3pm. PHP’s advisory says every setup that serves web pages is affected, and it lists them: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed (which a lot of UK shared hosting runs on). Apache with mod_php is the highest risk, because PHP has a working exploit for it that runs before any of your site’s own code gets a look in.

That covers a huge share of the web. WordPress alone powers 39.6% of all websites, according to W3Techs, and the same applies to WooCommerce shops, Drupal and Joomla sites, Magento and Shopware stores, Laravel apps and plenty of custom-built booking systems and client portals. The application on top doesn’t change the answer. The PHP version underneath does.

When was the PHP security update released?

On schedule, at 14:00 UTC on Wednesday 21 October 2026, which is 3pm UK time. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. At the time of writing, no confirmed attacks in the wild had been reported, but that’s the sort of sentence that goes out of date quickly.

Why WordPress can’t fix this one for you

Think of your website as a shop and your hosting as the building it trades from. WordPress, your theme and your plugins are the shopfittings: you, or your agency, can update those whenever you like. PHP is part of the building. If the foundations need fixing, that’s the landlord’s job.

Wordfence put it plainly in its public service announcement: “WordPress automatic updates will not apply this fix.” Who does depends on how your site is hosted:

• Shared or managed WordPress hosting (most small businesses and organisations): your hosting company updates PHP.
• A VPS or your own server: it falls to you, your developer or your agency.
• Hosted by your web agency: your agency, and it should be telling you what it’s doing.
• Wix, Squarespace, Shopify and similar platforms: you don’t manage the server, so there’s nothing for you to patch. The platform is responsible.

If you’re not sure which of these applies, look at who sends your hosting invoice. If nobody does, because a former colleague or a friend set the site up years ago, that’s worth knowing today rather than after something goes wrong.

Will your PHP version be patched?

This is the part most coverage skips. PHP only fixes security problems in the versions it still supports. According to php.net, that’s currently four:

That last row is bigger than it looks. Using WordPress.org’s own statistics, The Repository calculates that 35.1% of WordPress sites run a PHP version the PHP project no longer patches, with PHP 7.4 alone accounting for 16.46%. Roughly another quarter are on PHP 8.2, according to a September snapshot of the same data, which loses its own security support on 31 December.

Two things soften that. First, PHP’s security team has published minimal source patches for 7.4, 8.0 and 8.1, described as being for people who build PHP themselves or have no vendor to rely on. That’s not something a site owner can install, but it makes a host’s job easier. Second, some hosts run on CloudLinux, which maintains “hardened” builds of older PHP versions; its TuxCare team aims to patch critical vulnerabilities within 14 days of disclosure. So an older version isn’t automatically hopeless, but it may not be fixed today, and only your host can tell you which situation you’re in.

How to check your PHP version in WordPress

1. Log in to WordPress as an administrator.
2. Go to Tools > Site Health and open the Info tab.
3. Expand the Server section and note the PHP version.

Write down the full number (for example 8.3.25, not just 8.3). You’ll want it for the email below and to check the update has landed later. Not on WordPress? Your hosting control panel usually shows the PHP version, or your host can tell you.

What to do now

1. Find out who looks after your server. Hosting company, agency, freelancer or in-house: get a name and a way to reach them today. If it’s a hosting company, check its status page first; the bigger hosts will post their plan there.
2. Check your PHP version using the steps above.
3. Email your host using the template below, so you have their plan in writing.
4. Take a fresh backup of your files and database, stored somewhere other than the server itself, and make sure you know how to restore it.
5. If you’re on PHP 8.1 or older, plan the upgrade now. WordPress core committer Jonathan Desrosiers warned that many hosts are likely to force PHP upgrades to protect their customers. Moving on your own terms, with time to test your theme and plugins, beats finding out your site is down because the host moved you overnight.

A template email to send your host

Copy this, fill in the brackets and send it. Hosts are busy today, so a clear, specific question gets a faster answer than “are we OK?”.

For whoever manages your server: PHP’s interim mitigations

If the update can’t go on straight away, PHP’s advisory lists settings that reduce exposure. Its own caveat: they “reduce exposure but do not make an installation safe”. The main ones are memory_limit = -1 (set where applications can’t override it, such as php_admin_value in the FPM pool) and a low post_max_size for CVE-2026-109618, and session.upload_progress.enabled = 0 for CVE-2026-109619, which is the setting many hosts switched off this morning. WordPress doesn’t use that feature, so turning it off is low risk.

One correction to advice that was circulating earlier, including in the first version of this post: PHP says these settings must go in php.ini, the FPM pool or the server config, with every worker restarted afterwards, and not in a .user.ini file or via ini_set(). Those apply too late in the request to help. In practice that means on shared hosting it’s the host’s job, not something you can do from your own account.

Cloudflare has pushed emergency firewall rules, including two blocking rules on its free plan, and its CTO has since confirmed they’re for these flaws. They only help if your site’s traffic actually passes through Cloudflare; an attacker who finds your server’s real IP address goes straight past them. Wordfence says it will assess whether firewall protection is possible, but that updating PHP “remains the most important step whatever we find”. All of these buy time. None replaces updating PHP.

How to tell if your site has been patched

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If Site Health shows one of those numbers or higher, you’re patched. Anything lower on those branches, you’re not.

Don’t expect every host to have it done by now. What PHP published at 3pm is source code. PHP says Linux distributions and long-term-support vendors got the patches in advance, so some hosts will be quick. Others, particularly those on control panels such as cPanel or Plesk, are waiting on those suppliers to rebuild, and Wordfence notes they “may arrive on a different schedule from the official php.net release”. Hours is normal. Days is worth chasing. (One footnote for anyone running their own server on the popular volunteer-run Remi repository: PHP says it won’t have updates on day one, and suggests switching to distribution packages.)

One trap to watch for: the version number alone isn’t always proof. Hosts using backported builds, such as CloudLinux’s hardened PHP or Linux distribution packages, can fix a vulnerability without the version number changing at all. If your number looks the same tomorrow, don’t assume the worst, and don’t assume the best. Ask your host to confirm in writing that both CVE-2026-109618 and CVE-2026-109619 are fixed on your site.

What’s actually at risk

Very few websites are just brochures any more. They take enquiries, bookings, orders and payments, and many have logins for staff or customers. A remote code execution flaw hands an attacker control of the server all of that runs on.

In practice that tends to mean malware or spam injected into your pages, card details skimmed from checkout pages, your domain used to send convincing phishing emails to your customers, or personal data copied off the site. We’ve written before about how stolen data turns into phishing.

This isn’t a niche risk. 43% of UK businesses and 28% of charities reported a cyber breach or attack in the past year, according to the government’s Cyber Security Breaches Survey 2025/2026. Phishing is still the most common attack, not sophisticated hacks. Flaws like this one make the sophisticated version cheap.

If something does go wrong

A vulnerability on its own isn’t an incident, and you don’t need to report a routine update to anyone. If your site is compromised and personal data is affected, though, UK organisations normally have 72 hours to report it to the Information Commissioner’s Office if it’s likely to put people at risk. Charities should also check the Charity Commission’s serious incident reporting guidance. Our guide to what to do when a supplier has a security incident walks through the first steps.

The bigger lesson: someone has to own the layer below WordPress

Most site owners have a plan for WordPress updates, even if that plan is “auto-updates”. Far fewer have a plan for PHP, because it’s invisible until a day like today. That’s how sites end up on PHP 7.4 nearly four years after it stopped receiving fixes.

Desrosiers made the same point, calling on agencies to build PHP updates into their retainer agreements and on hosts to upgrade their customers proactively. Whoever looks after your site, it’s worth asking them one question after today: who is responsible for our PHP version, and how will we know when it needs to change?

If we look after your website

[CONFIRM BEFORE PUBLISHING: make sure this matches what we’re doing today.] If Nebula hosts or maintains your website, you don’t need to email anyone. We’re watching for the release and will apply the update as soon as it’s available, then confirm with you once your site is patched. If your site is on an older PHP version, we’ll be in touch about moving it to a supported one.

If you’d like someone to own this layer for you in future, our WordPress support and maintenance plans cover core, plugin and PHP updates, with a person checking the work rather than hoping it happened.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the nickname for two critical remote code execution vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619 and rated 9.2 out of 10. PHP released fixes on 21 October 2026 at 3pm UK time.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP has also published minimal source patches for 7.4, 8.0 and 8.1 for hosts and vendors to apply, but no normal release for those versions.

Has PHP2Shell been exploited?

At the time of writing, no confirmed attacks in the wild had been reported. PHP has a working exploit for Apache with mod_php, and security firms expected attacks to start within minutes of the release, so treat unpatched sites as exposed.

Will WordPress update itself to fix PHP2Shell?

No. The flaws are in PHP, not WordPress, so WordPress automatic updates won’t fix them. Your hosting company, or whoever manages your server, has to update PHP.

My site is on PHP 7.4. Will it be patched?

Not as a normal release. PHP stopped supporting 7.4 in 2022, but its security team has published a minimal source patch for 7.4, 8.0 and 8.1 that hosts and Linux vendors can apply, and CloudLinux-based hosts usually backport fixes to their hardened builds. Ask your host whether they’ve applied it, and plan a move to PHP 8.3 or later regardless.

Does this affect Wix, Squarespace or Shopify sites?

If your site is on a fully hosted platform, you don’t manage the server, so there’s nothing for you to update. The platform is responsible for its own infrastructure.

Do we need to report this to anyone?

Not for applying a security update. If your site is compromised and personal data is affected, you may need to report it to the ICO within 72 hours, and charities should also follow the Charity Commission’s serious incident reporting guidance.

Sources: PHP security advisory (21 October), PHP advance notice (20 October), PHP supported versions, Help Net Security, BleepingComputer, Sansec, CERT-EU, The Repository, Wordfence, W3Techs, DSIT Cyber Security Breaches Survey 2025/2026.