PHP security release · 21 October 2026

PHP2Shell: what UK website owners need to do

Two critical flaws in PHP itself let an attacker run code on a web server without logging in. PHP fixed them on 21 October. Most sites on managed hosting are being patched by their host. Sites on old PHP, and servers you run yourself, are not. Here is how to tell which you are, and what to do about it.

By Chris at OnComp · Published 21 October 2026, 23:45 BST · Last verified 21 October 2026, 23:40 BST

PHP2ShellAs of 21 October 2026

CVE-2026-109618: 9.2 (CVSS v4.0)
CVE-2026-109619: 9.2 (CVSS v4.0)
Fixed in: 8.5.128.4.278.3.368.2.35
PHP 8.1 and older: No official fix
Login needed to attack: None
Fixed by updating WordPress: No

Is your website affected?

Enter your address. We load your home page once, as a browser would, and tell you what your server says about its PHP.

Free. One normal page load of your home page, nothing more. How the check works

In short

Three things to know

The fix is a PHP update on the server

Not a WordPress, theme or plugin update. Whoever runs the server, you or your host, has to install the fixed PHP and restart it.

PHP 8.1 and older has no official fix

Only minimal source backports for 7.4, 8.0 and 8.1. CISA says systems still on 8.1 or older should go offline until they are patched or updated.

Most managed hosts are dealing with it

Get it in writing. Some hosts have patched PHP; others have only put a filter in front of it, which every agency calls a stopgap.

Official advice

What the agencies said

Their own words, each linked to the original. They agree on the order: find your PHP, patch what faces the internet first, and isolate what you can't patch. They differ on when to take a system offline.

NCSC

National Cyber Security Centre (UK)

“Organisations using any version of PHP are affected and all organisations are highly encouraged to update to the latest fixed version.”

If PHP's temporary mitigations can't be applied, or would take too long: “you should consider taking the system offline until it can be fully mitigated”.

Read the original

CISA

Cybersecurity and Infrastructure Security Agency (US)

“Organizations should immediately update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 to fix these vulnerabilities.”

The firmest line: organisations that can't update, or still use PHP 8.1 or earlier, “should take PHP-based systems offline until they can be patched or updated”.

Read the original

NSA

National Security Agency (US)

“If an immediate update is not feasible, it is recommended that organizations take the system offline until it can be fully mitigated.”

On why: “These vulnerabilities often provide a direct path to the server's file system or database.”

Read the original

CERT-EU

Cybersecurity Service for the EU institutions, bodies, offices and agencies

“Where immediate patching is not feasible, organisations should consider isolating internet-facing resources from public networks until the fix is applied and verified.”

Advisory 2026-018 tells organisations to patch affected assets immediately.

Read the original

ENISA

Joint statement: European Commission (DG CNECT), ENISA, CERT-EU, Europol EC3 and the CSIRTs Network

“Organisations should identify their PHP-based applications, coordinate with hosting and service providers, and apply the released security updates.”

Where that isn't feasible right away: “consider isolating exposed applications from public networks until fixes can be applied”.

Read the original

PHP

The PHP project

“PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution.”

And for older sites: “PHP 8.1 and older no longer receive updates from the PHP project.”

Read the original

Quoted as read on 21 October 2026, 23:40 BST. Agencies update their pages; the linked original is the authority. OnComp is not affiliated with, assured or endorsed by any of these organisations.

Fixed versions

Which PHP you need

If your PHP is on one of these branches, you need at least the version shown. Below that, you need a backport from your host or Linux distribution, or an upgrade.

Branch	First fixed release	Security support ends
PHP 8.5	8.5.12	31 December 2029
PHP 8.4	8.4.27	31 December 2028
PHP 8.3	8.3.36	31 December 2027
PHP 8.2	8.2.35	31 December 2026
PHP 7.4, 8.0, 8.1	No release; minimal source backports only	Already ended
PHP 5.4 to 7.3	No fix of any kind from PHP	Already ended

Linux distributions often fix PHP without changing its version number, so an older number on Ubuntu, Debian, AlmaLinux or Red Hat can still be patched: the package changelog is the proof. And a fixed package protects nothing until every PHP process has been restarted.

Your hosting

Who has to patch your site

It depends on who runs the server your website lives on.

Managed WordPress or website platform

WordPress.com, WP Engine, Kinsta, SiteGround, Pressable

Who patches

Your host

Usually nothing. Ask the host to confirm in writing that PHP itself was updated and restarted, not only shielded by a firewall rule.

Shared hosting with cPanel or Plesk

Most UK web hosts

Who patches

Your host

Check which PHP version your account runs. On 8.2 or newer, confirm the host has rolled out the fix. On 8.1 or older, ask whether they have backported it.

Your own VPS, dedicated or cloud server

Hetzner, DigitalOcean, AWS, Linode, Forge, a server in the office

Who patches

You

Update the PHP packages, restart every PHP process (PHP-FPM, Apache, LiteSpeed, containers), then check the version that is actually running.

A site that can only run PHP 8.1 or older

Old plugins or themes, Magento 2.4.4 or 2.4.5, Drupal 7, Joomla 3, bespoke code

Who patches

Nobody, upstream

There is no official release. A vendor backport or paid extended support is a bridge; the fix is moving to a supported PHP.

Shopify, Wix, Squarespace and similar

Hosted shops and site builders

Who patches

Not your concern

The platform does not run PHP for you. Check anything else you run beside it: a blog, a booking system, a subdomain.

UK hosts

What hosts have said

From each host's own status page or blog, as we read it on 21 October 2026, 23:35 BST. These change by the hour, so follow the link for the latest, and ask your host in writing if your site matters to your business.

20i Says patched
Says all PHP versions across all its platforms are now fully patched.
GoDaddy Patching under way
Managed WordPress patched on all PHP versions. Web and Windows Hosting mitigated, waiting on patched versions. VPS customers update themselves.
Heart Internet Patching under way
Mitigations in place, which it says are not yet a complete fix; patches rolling out. Unmanaged VPS and dedicated customers must patch themselves.
34SP Patching under way
Mitigations in place; updates rolling out.
Kinsta Patching under way
Some PHP versions patched, others still in validation. Cloudflare rules on all sites.
IONOS Patching under way
Installing the update across its systems; expects to finish within 24 hours.
Fasthosts Patching under way
Installing the update; expects to finish within 24 hours. Self-managed VPS and bare-metal customers patch themselves.
Krystal Mitigated, patch pending
All available mitigations applied across its fleet; still waiting for patched PHP packages from its supplier.
Cloudways Patching under way
Interim mitigations in place; official patches rolling out across every PHP version it supports, 5.6 and up.
SiteGround Mitigated, patch pending
Disabled the affected functionality before the fix was released. No update on the fix itself when we read it.
Hostinger Patching under way
Says its platform is not vulnerable, and is rolling out patched PHP anyway. PHP's own advice is that every installation is at risk.
cPanel Says patched
Patched EasyApache packages released for PHP 8.2 to 8.5, with backports for 7.4, 8.0 and 8.1. Your host still has to install them.
Names.co.uk No statement found
No PHP statement on its status page.
WP Engine No statement found
No public statement we could find.

“Patched” is the host's own claim. A firewall rule or a disabled feature is a mitigation, which every agency treats as a stopgap. Host not listed? Its status page, or a support ticket asking “has PHP been updated and restarted on my server?”, will tell you.

Advice to ignore

What doesn't fix it

Updating WordPress, your theme or your plugins

The bug is in PHP on the server, not in WordPress. WordPress.org says so itself. Source

Installing a security plugin

The attack runs while PHP reads the request, before any plugin code loads. Source

Cloudflare on its own

Cloudflare switched on free firewall rules for every plan, and its own CTO calls them a stopgap. They only cover traffic that goes through Cloudflare. Source

PHP's configuration workarounds on their own

PHP says its temporary mitigations “reduce exposure to specific attack paths but do not make an installation safe”. Updating is the only complete fix. Source

The detail

What the two bugs are

CVE-2026-109618 is memory corruption when PHP runs out of memory part-way through reading a request: it can be triggered while PHP parses an uploaded form, before any of the site's own code runs.

CVE-2026-109619 is stale state between requests: a fatal error leaves a pointer behind in a long-lived PHP worker, and a later request uses it. Session upload progress, which is on by default, is one way in.

PHP scores both 9.2 (CVSS v4.0), with high attack complexity. The worst case demonstrated is Apache running PHP as a module, where a single unauthenticated request reaches the bug. PHP-FPM servers are affected too, but turning the bug into code execution there depends on the application. Researchers at Calif, Wiz and OpenAI found the flaws with AI assistance.

Exploitation

Is it being exploited?

Security firms including Cloudflare and watchTowr report attempts to exploit the flaws. Cloudflare says attempt counts do not, on their own, show that any attack succeeded.

Neither CVE is in CISA's Known Exploited Vulnerabilities catalogue, and CISA said it had not observed exploitation when it published its alert.

We have found no primary-source report of a confirmed compromise. The PHP Foundation says its team found no working exploits at release; code circulating as an exploit is unverified and may itself be malicious.

As of 21 October 2026, 23:40 BST. This changes quickly; we update this section when it does.

UK obligations

The clocks that may apply to you

14 days · 4 November 2026

Cyber Essentials

If you're certified, software in scope must be supported, and updates its vendor rates critical must be installed within 14 days of release. PHP rates both flaws critical. Fourteen days from 21 October is 4 November, by our count.

NCSC requirements, v3.3

72 hours

UK GDPR breach reporting

Being unpatched isn't a breach. A compromise that exposes personal data can be, and a reportable breach must reach the ICO within 72 hours of you becoming aware of it.

ICO guidance

If you suspect a compromise

Incident response

The NCSC advises organisations that can't assess a compromise themselves to use an NCSC-assured Cyber Incident Response provider. OnComp is not one; for a confirmed breach involving personal or payment data, we'll refer you to one.

The NCSC scheme

Timeline

What happened, and what's next

20 Oct 2026
PHP pre-announces an urgent security release. The CVE numbers leak the same day and the release is brought forward a day.
21 Oct 2026
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released, with source backports for 7.4, 8.0 and 8.1. Cloudflare had already switched on firewall rules for all plans.
21 Oct 2026
The NCSC, CISA, the NSA, CERT-EU and an ENISA-led joint statement tell organisations to patch, and to take systems offline or isolate them if they cannot.
21 Oct 2026
Councils and public bodies in the UK, including Edinburgh City Council, take websites offline as a precaution.
4 Nov 2026
Fourteen days after the release: the window Cyber Essentials gives certified organisations to install critical updates.
31 Dec 2026
Security support for PHP 8.2 ends. Sites moved to 8.2 in a hurry this week need another upgrade by then.

Precautionary takedowns: FutureScot.

Need it done?

Fixed, verified and signed off, at a fixed price

We patch servers, chase hosts for written confirmation, check exposed servers for signs of a break-in, and move old sites onto a supported PHP. Every job ends with a dated sign-off of what changed and how we checked it.

Host and PHP confirmation£195
Patch and verify, per server£450
Priority: work starts within 4 working hours£750
Compromise check£850
Upgrade a WordPress site to PHP 8.4£795
Fixed prices, excluding VAT.

Questions

What people are asking

Does updating WordPress fix PHP2Shell?

No. The flaws are in PHP, the language the server uses to run WordPress, so the fix is a PHP update on the server. Updating WordPress, plugins or your theme is worth doing anyway, but it doesn't touch this. WordPress.org says the same.

How do I find out which PHP version my site runs?

In WordPress, go to Tools, then Site Health, then the Info tab, and open Server. In cPanel, look under Select PHP Version or MultiPHP Manager. On a server, the version the command line reports can differ from the one serving the website, so check the package your web server actually uses.

My host says I'm protected. Is that enough?

Ask one question: has PHP itself been updated and restarted, or is the site behind a firewall rule or a disabled feature? The agencies treat the second as a stopgap. A short written answer from your host is worth keeping for your records, your insurer or your Cyber Essentials file.

I use Cloudflare. Am I covered?

Partly. Cloudflare switched on PHP2Shell rules for every plan, including Free, and calls them a stopgap. They only protect traffic that passes through Cloudflare, so a server that can also be reached directly, or a subdomain that isn't proxied, is still exposed.

My site is on PHP 7.4, 8.0 or 8.1. What now?

PHP released no fixed version for these branches, only minimal source backports, which some hosts and Linux distributions have applied. Ask your host first. The lasting fix is moving the site to a supported PHP; we'd go straight to 8.4, because PHP 8.2's security support ends on 31 December 2026.

Should I take my website offline?

Only if you can neither update nor apply PHP's temporary mitigations. That is the NCSC's advice: “consider taking the system offline until it can be fully mitigated”. CISA goes further for anything still on PHP 8.1 or older. For most sites on managed hosting, the host's update is the answer.

Do I have to tell the ICO?

Not for being unpatched. If your site was compromised and personal data was exposed, a reportable breach has to reach the ICO within 72 hours of you becoming aware of it. That is why a server exposed since 20 October deserves a compromise check, not just a patch.

Is this the same as WP2Shell?

No. WP2Shell, in July 2026, was a separate flaw in WordPress with its own fix. PHP2Shell is in PHP itself, so it affects every PHP application, not only WordPress.

Same day, separate issue

The Node.js security release of 21 October

Ten fixes, the worst a Brotli decoder bug rated High. Node.js 18, 20 and 25 get no fix.

What Node.js users should do

Patch Watch

Every security release we're tracking

What's out, what's coming, and the plan that tells you before release day.

See security releases

Sources

Where this comes from

About this page. Written by Chris at OnComp, a web and IT consultancy in Shoreditch, London. Every fact links to its source and was re-read at the “last verified” time above. OnComp is not an NCSC-assured Cyber Incident Response provider, and none of the agencies quoted here has reviewed or endorsed this page or our services.