PHP2Shell: What the October 2026 PHP Flaw Means for Your WordPress Site

On 21 October 2026, PHP released fixes for two critical flaws that can allow an unauthenticated attacker to run code on a vulnerable server. WordPress runs on PHP, so owners needed their host to check the runtime. Updating WordPress, a plugin or a theme alone does not patch PHP. The practical question is who owns that server update and how quickly it can be tested.

For the client sites WP Creative hosts and manages, the answer was my team. The last couple of days have been busy: the team and our server team have been applying the PHP updates server by server and checking each site’s PHP version against the patched list. It has been an interesting couple of days. But this is our job. If your site runs on a server someone else manages, the useful question is not “are we safe?” but “which PHP build is on our server, and when was it applied?”

The facts, as of 25 October

• What it is: two flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 by the PHP project. Researchers nicknamed them PHP2Shell.
• Who is affected: almost every PHP version back to 5.4, on every common server setup. The researchers confirmed an attack against WordPress 7.1.2.
• The fix: PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, released on 21 October 2026. Plugin and theme updates don’t help.
• The follow-up: on 23 October the PHP project published a second, informational advisory about the session upload progress feature. It suggests setting session.upload_progress.enabled=0 until the next regular bugfix release, to close an unlikely remote code execution path (a new CVE, CVE-2026-115560). It only bites when an application switches the session serialize handler at runtime, but the setting was already on the 21 October mitigation list, so keep it if you applied it.
• What has been observed? AWS reported attempts against its honeypots on 17 October, before public disclosure. AWS said it was unclear whether those attempts would have succeeded against real systems. An observed attempt is not evidence that a particular WordPress site was compromised.
• What to do: ask your host to confirm the fixed PHP build or documented vendor backport, assess the 23 October advisory and check the active runtime in Site Health. If you are on upstream PHP 8.1 or older, arrange a tested upgrade to a supported branch.

What actually happened?

The researchers and PHP project coordinated a release, but leaked details brought disclosure forward to 21 October. The 23 October follow-up concerns a specific combination of session configuration and application code. PHP says applications that never change the serialisation handler at runtime can leave upload progress enabled. Your host and developer should assess that condition rather than assume every installation needs the same extra setting.

AWS reported pre-disclosure attempts against its honeypots and said real-world success was unclear. Cloudflare says it deployed WAF protection on free and paid plans about nine hours before disclosure. Its current follow-up notes a limit: the upload-progress rule covers the default field name, not custom names. Cloudflare still tells customers to patch PHP. A firewall is another layer, not the runtime fix.

In Australia, the national cyber agency (ASD’s ACSC) issued an alert before the patch was even out, which iTnews described as unusual. The ABC reported that cyber.gov.au and other Australian government websites had outages. Overseas, several governments took services offline as a precaution.

Why didn’t my plugin updates fix it?

Because the flaws aren’t in WordPress. They’re in the language WordPress is written in, running on the server. Think of it as the building’s foundations rather than the furniture: you can replace every chair in the office and the cracked slab is still there.

That’s why WordPress.org’s own post on 21 October said no WordPress update was required or planned, and why the UK’s National Cyber Security Centre told organisations that can’t patch to consider taking systems offline.

Who was actually exposed?

The pattern was clear within a day. Managed WordPress hosts put firewall rules in place within hours and rolled PHP out over the following day. Kinsta, for example, told customers there was nothing they needed to do and asked them not to suspend environments, because that would block the patch.

The sites with the most to worry about were the ones where nobody’s job is to patch PHP:

• self-managed VPS and cloud servers (the “we set it up once in 2019” box);
• sites still on PHP 8.1 or older, which no longer get releases from the PHP project (some Linux distributions and long-term support vendors have backported a fix, so ask yours rather than assume);
• anything else on the same server bundling its own PHP: control panels, Docker images, network appliances.

The risk usually isn’t the clever attack, it’s the gap between “someone set this up” and “someone owns this”. A server nobody owns is a liability with a login screen.

I’ve watched that gap play out. A services group with more than a dozen websites came to my team after a run of developers engaged job by job. There was no clear process for updates, so nobody owned them, and PHP, WordPress and the plugins had all fallen behind. The first thing my team did was the unglamorous part: bring PHP, WordPress and every plugin up to date, test each site, then put a monthly owner and a care plan around it. Weeks like this one are why that boring work matters.

What should you check this week?

1. Ask your host, in writing, whether the 21 October PHP release is applied to your site. Note that some providers backport the fix without changing the version number, so the written answer matters more than the number.
2. Check your PHP version: in WordPress, Tools, then Site Health, then Info, then Server. Patched versions are 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later.
3. Assess the 23 October follow-up: ask whether the application changes session.serialize_handler in the way the advisory describes. Where the mitigation is needed, the host should apply session.upload_progress.enabled=0 administratively and restart workers. A .user.ini file is too late for the relevant early-startup path. Check custom upload-progress functionality before changing it.
4. If you’re on PHP 8.1 or older, plan the move to 8.3 or newer and test it on a staging copy first. PHP 8.2 itself reaches end of life on 31 December 2026, so don’t stop at 8.2.
5. Keep your firewall in blocking mode (Cloudflare or your host’s), but treat it as a seatbelt, not the brakes.
6. Look back from 17 October, not from the patch date: unexpected PHP files, unknown admin users, changed files. If anything looks wrong, rotate passwords and API keys, because the flaws can expose server memory. My post-hack WordPress security checklist covers the clean-up order.

If you can’t get a straight answer by the end of the day, treat the site as unpatched. Ask whoever manages the server to apply the update or put the site behind a blocking firewall rule while they do. If it turns out nobody owns the server, that is the real finding. Tell me what you’re running and my team will help you get it patched or moved to managed WordPress hosting where someone does.

What I think this changes

Two things.

First, “keep your plugins updated” is necessary and no longer sufficient. Every business website needs a named owner for the whole stack, from PHP to plugins, with a response time when something like this lands on a Tuesday night.

Second, the speed of this one is the new normal. The researchers say they used AI help to find these bugs, attack attempts started before the fix existed, and Amazon notes that AI-assisted analysis makes it cheaper to turn a patch or advisory into a working exploit. Nobody has shown that the attackers here used AI. They didn’t need to: the window between “disclosed” and “exploited” was measured in hours anyway. If your website makes you money, the question isn’t whether you can patch, it’s whether someone will, before you’ve finished your morning coffee.

Where the evidence disagrees

Researchers disagree on how easy the public exploits are. Calif says the flaw is exploitable on default configurations; the security firm Sansec said on 22 October that public exploits don’t work against a default PHP install and usually need a second bug. Reports of exploitation “at scale” came from some security firms, but no confirmed breach had been publicly documented by 25 October. Treat claims of mass hacking with care until confirmed breaches are documented.