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

In short

• What: two critical flaws in PHP, the software behind most websites including every WordPress site. They’re nicknamed PHP2Shell (CVE-2026-109618 and CVE-2026-109619).
• Status: fixed by PHP on Wednesday 21 October 2026, and already being used in attacks.
• Who fixes it: your hosting company or whoever manages your server. WordPress updates won’t touch it.
• What to do now: get written confirmation from your host that your site is patched, take a fresh backup, and check for signs your site was attacked before the fix went on.

What should I send my website host?

When wp2shell hit WordPress in July, WordPress.org pushed the fix out automatically and most sites were patched without anyone lifting a finger. PHP2Shell doesn’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 so far is written for server administrators. This guide is for everyone else: business owners, charity staff, marketing teams, office managers and anyone who owns a website without running the server it sits on.

What is PHP2Shell?

PHP2Shell is the nickname for two critical security flaws in PHP, tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 on the CVSS severity scale, where anything from 9.0 upwards counts as critical.

In plain terms, they let an attacker run their own code on your web server without logging in. Security people call this remote code execution, and it’s about as serious as website flaws get. Researchers have also shown the flaws can be used to read files and leak data held in the server’s memory.

Details leaked online on Tuesday 20 October, before a fix was ready. PHP’s security team gave advance notice that evening and released the fixed versions at 3pm UK time on Wednesday 21 October.

The flaws were found by researchers at Wiz, OpenAI and Calif, who used AI models to find them and turn them into working attacks. They’d been hiding in PHP for a long time: every version back to PHP 5.4, released in 2012, is affected. We wrote in August about an AI finding a bug in WordPress. This is the same trend on a much bigger scale.

Is anyone being attacked?

Yes. Amazon’s threat intelligence team recorded an attempt on its decoy servers on 17 October, four days before the flaws were made public, and says PHP2Shell is now being broadly exploited. Security firm watchTowr is seeing attempts against both flaws, and Cloudflare was seeing early attacks even before PHP’s fix came out.

Security researcher Kevin Beaumont called it “one of the biggest vulns in years”, and organisations took that seriously. On Wednesday, parts of Wikipedia went offline as a precaution, and websites belonging to Edinburgh and Oxford councils and the Met Police were reported unavailable. The Dutch government’s own cyber security agency took its website down too. Wiz estimates roughly 70% of the internet is affected, though that figure hasn’t been independently verified.

What the UK’s National Cyber Security Centre says

The NCSC has published an alert for UK organisations. In short, it advises you to:

1. Find every system running PHP, starting with anything the public can reach.
2. Update to a fixed version of PHP.
3. If you can’t update, apply the temporary measures PHP has published.
4. If you can’t do either quickly, consider taking the system offline until it’s fixed.
5. If a system couldn’t be updated straight away, check it for signs of an attack and anything an attacker may have left behind.
6. Keep watching for updates to other products that include PHP.

Most of that is a job for your host or developer. Your job is to make sure someone has done it, and to have that in writing.

Is your website affected?

If your site runs on PHP, assume yes until your host confirms it’s patched. The NCSC says every version of PHP is affected, and PHP says that’s true however the server is set up.

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 software on top doesn’t change the answer. The PHP version underneath does.

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.” Security plugins can’t plug the gap either. On some server setups, the attack happens before WordPress or any plugin has even loaded.

Who fixes it 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. Automattic says sites on WordPress.com, WordPress VIP, WP Cloud and Pressable are already protected.

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 finding out today rather than after something goes wrong.

Which PHP versions have been fixed?

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, and that loses its own security support on 31 December. We’ve written about what that means for charity websites.

An older version isn’t automatically stuck. Some hosts run their servers on CloudLinux, which maintains its own builds of older PHP versions and released patched builds of PHP 5.6, 7.4 and 8.0 on the day of the fix. But that only helps if your host uses those builds, and only your host can tell you. Either way, it’s time to plan a move to a supported version.

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 later that the fix has landed. 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, as the bigger hosts are posting updates there.
2. Check your PHP version using the steps above.
3. Email your host using the template below, so you have confirmation in writing that both flaws are fixed on your site.
4. Take a fresh backup of your files and database, stored somewhere other than the server itself. Also check how far back your existing backups go. If your site turns out to have been attacked, a copy from before 17 October could matter.
5. If your host can’t confirm a fix, take the site offline properly. That’s what the NCSC suggests. A WordPress maintenance mode plugin doesn’t count: WordPress still runs on PHP behind it, so the flaw is still exposed. Ask your host to switch the site off at server level, or to replace it with a plain holding page that doesn’t use PHP.
6. 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 today. Hosts are busy, so a clear, specific question gets a faster answer than “are we OK?”.

How to tell if your site has been patched

Check your PHP version in Site Health again. If it’s at or above the fixed version for your branch in the table above, you’re patched.

If it hasn’t moved yet, don’t panic straight away. What PHP publishes is source code. Hosts that install PHP through their operating system, a control panel such as cPanel or Plesk, or container images wait for those suppliers to rebuild it, and Wordfence notes the fix can reach servers on a different timetable from PHP’s own release. Hours is normal. Days is worth chasing.

There’s 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 flaw without the version number changing at all. If your number looks the same, 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 this looked like on our own server

We saw this first-hand. On Thursday morning our hosting partner confirmed in writing that the server running our clients’ sites had been patched against both CVE-2026-109618 and CVE-2026-109619. The fixes were backported into the existing builds, so a site on PHP 8.4 still reports 8.4.26 in Site Health, one release below the official fix in 8.4.27, even though it’s protected.

Going by the number alone, we’d have assumed it wasn’t. That’s why the written confirmation matters: ask your host to name both CVEs and the date the fix went on.

Was your site attacked before it was patched?

Patching closes the door. It doesn’t tell you whether someone got in first. Because attacks started before the flaws were public, Amazon advises looking back to at least 17 October, not just to the day of the fix. The NCSC also asks organisations to check any system that wasn’t updated straight away for signs of an attack.

Your host or developer should check the server itself. These are things you can look for yourself:

• Administrator accounts in WordPress (under Users) that you don’t recognise.
• Pages, posts or links you didn’t add, or your site sending visitors somewhere else.
• Odd results when you search Google for your own site, such as spammy page titles in another language.
• Warnings from your browser, Google Search Console or your host.
• Customers or supporters reporting strange emails that appear to come from you.

If anything looks wrong, don’t just restore a backup and move on. Get the site checked properly, then change your WordPress, hosting and database passwords, along with any keys stored on the site for services such as payments or your CRM. If you need outside help, the NCSC keeps a list of assured cyber incident response providers.

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, and any UK organisation can report a cyber incident to the NCSC. Our guide to what to do when a supplier has a security incident walks through the first steps.

For whoever manages your server

If you’re passing this post to your developer or host, these are the points that matter:

• Update PHP, then restart it. Running PHP processes keep using the old code until they restart, so restart PHP-FPM, Apache or LSAPI after updating.
• Check what the site is actually running, not just what’s installed. Site Health shows the version the website uses, which catches a missed restart.
• Don’t lean on the session.upload_progress workaround. watchTowr says .ini changes don’t prevent exploitation, and that feature is only one of the routes in.
• Treat firewall rules as a stopgap. Cloudflare, Imunify360 and others have rules that block known attack patterns, but Cloudflare itself describes its protections as temporary. Rules in front of a site only help if the server can’t be reached directly on its IP address.
• Check products that bundle PHP, such as appliances and control panels. The Dutch NCSC is keeping a list of affected software.

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 week like this one. 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 once this is over: who is responsible for our PHP version, and how will we know when it needs to change?

If we look after your website

If your site is on Nebula’s hosting, it’s patched. Our server firewall started blocking the known attack on Wednesday morning, before PHP’s fix was even out, and our hosting partner confirmed the fixed PHP builds were in place on Thursday morning. Your site may still show the same PHP version number as before. As explained above, that’s expected with a backported fix.

If we maintain your site but it’s hosted elsewhere, we’re checking with your host. If your site is on an older PHP version, we’ll be in touch about moving it to a supported one. Any questions about your site, get in touch and we’ll confirm where it stands.

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 vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619 and rated 9.2 out of 10. They let an attacker run their own code on a web server without logging in.

Has PHP fixed PHP2Shell?

Yes. PHP released fixes on Wednesday 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There’s no official fix for PHP 8.1 or older, though some hosts provide their own patched builds.

Is PHP2Shell being used in attacks?

Yes. Attack attempts were seen from 17 October, four days before the flaws were made public, and security firms are now reporting widespread attempts.

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 host says we’re patched, but my PHP version hasn’t changed. Is that right?

It can be. Some hosts backport the fix into their existing PHP builds, so the version number stays the same. Ask your host to confirm in writing that both CVE-2026-109618 and CVE-2026-109619 are fixed, and when.

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

Not by the PHP project, which stopped supporting 7.4 in 2022. Some hosts provide patched builds of older versions, so ask yours today, and plan a move to PHP 8.3 or later.

Should I take my website offline?

If your host can’t confirm your site is patched, the NCSC says to consider it. Do it at server level, or with a holding page that doesn’t use PHP. A WordPress maintenance mode plugin won’t protect you.

Does this affect Wix, Squarespace, Shopify or WordPress.com 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, and Automattic says WordPress.com sites are already protected.

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: NCSC, PHP release announcements, PHP supported versions, Amazon Threat Intelligence, watchTowr, NCSC-NL, BleepingComputer, Help Net Security, Imperva, OX Security, Huntress, CloudLinux, Insurance Business, The Cyber Express, Techzine, Newsweek, The Repository, Wordfence, W3Techs, DSIT Cyber Security Breaches Survey 2025/2026.