PHP2Shell: The Critical PHP Flaw You Can't Fix From WordPress

Status as of 22 October 2026. We'll update this page if the picture changes.

This month's PHP security update won't appear in your WordPress dashboard. On 21 October the PHP project fixed two critical flaws in PHP itself, the software that WordPress and many other website platforms run on. Your hosting company is the one that has to apply that fix, so the useful thing to do today is ask them to confirm it's done.

What happened

PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which, in the PHP project's own words, "fix two critical vulnerabilities that can allow unauthenticated remote code execution". Put plainly, an attacker could run their own code on a web server without needing to log in to anything.

The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and they have become known as PHP2Shell. PHP rates both 9.2 out of 10 on version 4.0 of the CVSS severity scale. The US National Vulnerability Database scores them 9.8 on the older version 3.1 scale. In the UK, the National Cyber Security Centre has published an alert urging organisations to update.

Why updating WordPress won't fix it

PHP is the engine underneath WordPress. When you update WordPress or a plugin, you're updating code that runs on top of that engine. These flaws are in the engine, so nothing you install from the dashboard reaches them.

The two flaws work differently. CVE-2026-109618 involves a specially crafted upload that can make PHP run out of memory at the wrong moment and leave damaged data behind, before any of the website's own code has run. CVE-2026-109619 comes from leftover information from one failed request being reused by the next request the server handles. Neither needs the attacker to have an account on your site.

Who is affected

PHP's advisory says the risk covers every PHP setup that serves web pages, and it considers the risk highest on servers that run PHP through Apache's mod_php module, where a working attack needs nothing from the website itself.

Other servers run PHP through a component called PHP-FPM. That doesn't make them safe. For CVE-2026-109619, the attack was shown working against PHP-FPM as well, although that route depended on something in the website's own code. The practical answer is the same either way: the server needs the update.

If your site runs PHP 8.1 or older, the PHP project no longer releases updates for it. For these two flaws its security team did publish minimal source patches for 7.4, 8.0 and 8.1, but they only help people who build PHP themselves. Some Linux distributions and support vendors patch older versions themselves, but the dependable fix is to move to a supported version. The NCSC also warns against checking only old versions, because all versions may be affected.

Is it being exploited?

Reports differ, so it's worth being precise about who is saying what.

Amazon's threat intelligence team says it saw an exploitation attempt on 17 October, four days before the fixes were published, and now describes PHP2Shell as being broadly exploited, though it says it is unclear whether any of these attempts would have succeeded. On 21 October, the security firm watchTowr told SecurityWeek it had seen attempts but no successful ones. According to SecurityWeek, Patchstack, Cloudflare and Vega also observed attempts. PHP's own security team said it had not identified any working exploits at the time of release. And as of 22 October, neither flaw was on the US Cybersecurity and Infrastructure Security Agency's list of known exploited vulnerabilities.

Whichever account turns out closest to the truth, the action for a site owner doesn't change.

What to ask your host

WordPress itself points out that your hosting company decides which PHP versions are available for your site. A short email is enough:

Has the PHP running my website been updated for CVE-2026-109618 and CVE-2026-109619, the October 2026 PHP security release? Which PHP version or package is my site on, and has PHP been restarted since the update? If my site is on PHP 8.1 or older, what's the plan to move it to 8.3 or newer?

The restart question is there because a server can keep running the old code until PHP is restarted, which is why update instructions such as AlmaLinux's include that step.

Why the version number may not tell you

You can see your PHP version in WordPress by going to Tools, then Site Health, then the Info tab, and opening the Server section. The number is useful, but it doesn't always tell you whether this fix is in place.

Linux distributions often apply security fixes to their own builds without changing the version number. Ubuntu 24.04's fixed package, for example, still reports PHP 8.3.6. So a number lower than 8.3.36 doesn't necessarily mean your site is unpatched, and only your host can tell you which build you're actually on.

If you run your own server

If you manage your own virtual server, update the PHP packages from your distribution and restart PHP-FPM or Apache afterwards. PHP's advisory is blunt about the alternatives: "There are no complete mitigations, updating is the only safe choice."

If you genuinely can't update straight away, the NCSC points to temporary mitigations from the PHP Foundation. Treat them as a stopgap, not a fix. The NCSC also advises checking any system you couldn't update immediately for signs of compromise and for backdoors left by an attacker, and, if neither the update nor the temporary mitigations can be applied quickly, to consider taking the system offline until it can be fully mitigated. Amazon's earliest reported attempt was on 17 October, so that's a sensible date to look back from.

Cloudflare has added free firewall rules for its customers, but its chief technology officer, as quoted by Tenable, described them as a stopgap only. They can also only filter traffic that actually passes through Cloudflare.

Two things not to do

Don't install unofficial "fix" plugins. Patchstack warns that they aren't verified and can break your site, and the same caution applies to unofficial patched builds of PHP shared online.

Don't go looking for exploit code to test your own site either. Tenable reports that code claiming to exploit these flaws is circulating publicly, and that it hasn't verified any of it works. Running untrusted code against your own server is a risk in itself.

The question that outlasts this fix

Once this release is applied, there's a longer-running question worth answering: is your site on a version of PHP that still gets security fixes at all? The PHP project's support dates are:

WordPress recommends PHP 8.3 or newer. Yet WordPress.org's statistics, checked on 22 October 2026, suggest around 36% of WordPress sites still report PHP 8.1 or older, and around 24% report 8.2, which loses security support at the end of this year.

Moving up a version is usually straightforward, but plugins and themes written for older versions of PHP can break. Test the change on a copy of the site before switching the live one.

Today, and before the end of the year

Send your host the email above today. Then put a note in the diary for early December: if your site is still on PHP 8.2 or older by then, it needs moving to 8.3 or newer before 31 December.

If we look after your site on one of our website care plans, PHP updates are part of that work, so this one is on our list rather than yours. If you think a site may already have been compromised, our website security page explains how we clean up and harden affected sites.

Update log

• 22 October 2026: first published.