On October 21, 2026, the PHP project shipped emergency fixes for two critical flaws in PHP itself, now known as PHP2Shell. Both can let an attacker run code on a web server without logging in. 1 Source 1 PHP Group, security advisory, October 21, 2026. CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2.
WordPress didn’t cause this. WordPress can’t fix it either. The flaw sits one layer down, in the language every WordPress site runs on, which makes it a question about who looks after your server.
Is WordPress affected by PHP2Shell?
Yes, indirectly. Every WordPress site runs on PHP, so a site on an unpatched PHP version is at risk however current its WordPress core and plugins are. A WordPress update won’t help. The fix is a newer PHP on the server: 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
How much risk depends on how the server runs PHP. The PHP project rates it highest for servers running Apache with mod_php. Other common setups are affected too, so the advice is the same everywhere: update. 2 Source 2 PHP Group, October 21, 2026. One advisory notes no complete exploit has been shown on PHP-FPM, another common setup; the other reports its attack path validated on both mod_php and PHP-FPM.
The harder number is how many sites can’t simply take that update. Here is how the sites that report to WordPress.org’s update service break down, as of October 22: 3 Source 3 WordPress.org PHP version statistics, read October 22, 2026. Covers every reporting site, including small and inactive ones.
| PHP version your site runs | Share of reporting WordPress sites | What the PHP project offers |
|---|---|---|
| 8.2 to 8.5 | 64.1% | Official fixed release |
| 7.4 to 8.1 | 30.2% | No release; source backports only |
| 5.4 to 7.3 | 5.3% | Nothing; end of life |
Fix status is from the PHP advisory and Tenable’s summary of it. 4 Source 4 Tenable, October 21, 2026, citing Calif’s finding that the earliest affected code path dates to PHP 5.4.0, and listing 7.4 to 8.1 as source backports only and 5.4 to 7.3 as end of life with no fix.
Roughly one in three of those sites runs a PHP version that no official PHP release fixes. For those sites, “just update” means moving up a version. Your host, your Linux distribution or a long-term support vendor may have backported the fix for you. The PHP project published source backports for 7.4 to 8.1 and tells anyone on those versions to ask their vendor or upgrade. 5 Source 5 PHP Group, October 21, 2026: “PHP 8.1 and older no longer receive updates from the PHP project.” Minimal source backports were published for 7.4, 8.0 and 8.1. PHP 8.2 reaches end of life on December 31, 2026. WordPress itself recommends PHP 8.3 or newer and treats 7.4 as a legacy floor. 6 Source 6 WordPress.org Requirements, read October 22, 2026: “PHP version 8.3 or greater” recommended; 7.4+ works in legacy environments.
One more date matters. PHP 8.2 itself stops getting security fixes on December 31, 2026. A site that patches to 8.2 this week has ten weeks before it faces the same question again.
How serious is it?
Serious enough that the details didn’t wait for the fix. The CVE numbers leaked on October 20, and the PHP project moved its release up a day. 7 Source 7 Tenable, October 21, 2026. The PHP project’s pre-announcement went out October 20; the release was first planned for October 22.
The reports so far:
- Amazon Threat Intelligence logged an attempt against its honeypots on October 17, four days before public disclosure, and more on October 21. It says it is unclear whether those attempts would have worked against real systems, and that PHP2Shell is now broadly exploited in the wild. 8 Source 8 Amazon Threat Intelligence, AWS Security Blog, October 21, 2026.
- watchTowr reports exploitation in the wild as of October 21. 9 Source 9 watchTowr FAQ, updated October 22, 2026.
- The PHP project’s advisories describe validated exploits and don’t claim attacks in the wild. According to Tenable, PHP’s security team found no working exploit among the proof-of-concepts circulating at release. 10 Source 10 GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, October 21, 2026; Tenable, October 21, 2026.
None of these reports a confirmed break-in yet. Researchers at Calif, one of the teams credited with finding the flaws, also showed they could be used to run code on specific versions of popular PHP applications without logging in, WordPress among them. 11 Source 11 Tenable, October 21, 2026. A research finding about exploitability, not a report of attacks. The specific WordPress versions were not named. If you’re checking whether you were hit, Amazon’s advice is to start from October 17.
A site that patches to 8.2 this week has ten weeks before it faces the same question again.
What to do this week
None of this needs a developer to start. It needs someone to ask the right questions of whoever runs your server.
-
Find your PHP version. In the WordPress dashboard, go to Tools, then Site Health, then the Info tab, and open the Server section. Write the version down. A number below the fixed releases doesn’t always mean you’re unpatched, because Linux distributions often backport security fixes without changing the version number. Treat it as the starting point for the next step.
-
Ask your host three things, in writing:
- Is the PHP2Shell fix applied on the server my site runs on, and in which package or version?
- If my site is on PHP 8.1 or older, where is the fix coming from, and when?
- Will you check the server logs back to October 17 and tell me what you find?
A good managed WordPress host should answer all three the same day. A budget shared host may tell you to pick a newer PHP version from your control panel yourself. If your site is on a server your team or a freelancer set up, the answer to all three is “us”, and the work starts now.
-
If you’re on PHP 8.1 or older, book the upgrade this week and do it properly. Moving up a version can break old plugins and themes, so test on a staging copy first, update or replace whatever fails, then switch production. A plugin that can’t run on current PHP was already a liability.
-
Treat a security plugin or firewall as a stopgap. The PHP project says there are no complete mitigations and updating is the only safe choice. Its own interim server settings block specific attack paths but, in its words, “do not make an installation safe.” 12 Source 12 PHP Group, October 21, 2026, “If you cannot update immediately.” The interim settings are server-level and need a host or administrator to apply them. A firewall can buy time while the update happens.
What the scramble actually tells you
If you can name your plugins but not the person who keeps PHP current underneath them, or how fast they move, PHP2Shell just showed you the gap.
The question of who owns that layer is worth settling now, while it’s urgent, because the answer pays off well past this CVE. A site with a named owner for every layer, a patch commitment in the hosting contract and a plugin stack known to run on current PHP can take a runtime upgrade as routine maintenance. That’s the difference between reading about the next PHP2Shell and losing a week to it.
If this week showed you that nobody clearly owns that layer, that is a decision worth making on purpose. For some companies the answer is a better host or a clearer contract. For others it’s a hard look at whether the platform still fits. The real cost of WordPress at mid-market scale puts numbers on the upkeep, and 11,334 new vulnerabilities in a year covers the plugin side of the same risk. If you’re weighing a bigger change, the six-factor evaluation and the WordPress Score will tell you whether moving makes sense for you, or whether staying is the better call.
The research is free. So is the diagnosis. 60 seconds →