WordPress PHP version security: your host decides

Every piece of WordPress PHP version security advice you have followed — a security plugin, a hardening checklist, file permissions, an application firewall — sits inside PHP. php2shell triggers before PHP hands control to your application. PHP's own advisory says so: the risk is highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs".

So for the next week the only variable that decides your exposure is which PHP binary your host is running, and whether they have patched it. If you are on shared or managed hosting, that is not your decision. Here is how to find out where you stand and what to ask.

Why CMS hardening does not reach this

The PHP advisory of 21 October 2026 puts the scope at "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed". Two unauthenticated remote code execution bugs, CVSS v4.0 9.2, fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Trace a request to see why your controls are not in the path. It arrives at Apache or LiteSpeed; PHP begins parsing the request body; the overflow happens; your wp-config.php has not been read, no plugin has loaded, no theme has initialised, no login has been evaluated. A WordPress security plugin is PHP code waiting for PHP to finish starting up. Sophos makes the same point about in-application protection generally, noting that RASP or in-app WAF "may not prevent exploitation".

Which also means the usual reassurances do not apply here. Being fully updated on WordPress core, running no vulnerable plugins, and having an admin password nobody could guess are all true and all irrelevant to this specific bug.

What was actually confirmed against CMS platforms

One claim is circulating that deserves careful handling. Tenable reports that the researchers who built the exploit "confirmed pre-authentication remote code execution against specific versions of popular PHP applications, including WordPress, Drupal, Joomla and Magento".

Treat that as an unverified vendor claim. No versions are named, we have not seen the proof, and Tenable itself notes that while exploit code is circulating publicly, "we have not verified that any of it works". What it tells you is the direction of attacker interest, not that a working public exploit exists for your stack today.

On scale, two published estimates disagree and both are worth knowing: Tenable cites "over 1.3 million internet-exposed hosts" from one researcher and "over 1.9 million" from Shodan via another. Either figure means scanning is indiscriminate — Datadog describes "broad untargeted scanning" — so nobody is too small to be found.

WordPress PHP version security starts with the running version

Your hosting plan's documentation is not evidence. The running version is, and there are three places to check because they disagree more often than you would expect.

Where	How	What it tells you
Control panel	cPanel or Plesk PHP selector	The branch, rarely the patch version — not enough
Through the web server	A temporary page calling phpinfo()	The version and SAPI actually serving requests
WordPress admin	Tools → Site Health → Info → Server	Version without the SAPI; easiest to check

You need the full patch version, not the branch. "PHP 8.3" does not answer the question; 8.3.36 or later does. The SAPI matters too, because mod_php is where PHP says the risk is highest. Delete any phpinfo() page immediately after reading it — it exposes paths, extensions and configuration that help an attacker.

What to ask a managed host, and what counts as an answer

If the version is below the fixed releases, you are asking someone else to act. Make the question specific enough that a support script cannot absorb it:

• Which exact PHP patch version is serving my site right now, and which SAPI?
• Have you applied the 21 October 2026 php2shell fixes, and on which date?
• If my branch is 8.1 or older, which branch do I need to move to, and can you move me?

"We are aware and monitoring the situation" is not an answer to any of those. "We patched to 8.3.36 on 22 October" is. The distinction matters because PHP's advisory notes that "Linux distributions and LTS vendors received the patches in advance", so a competent host had the fix before you heard about the bug — a host still deliberating a week later has told you something useful about the next incident too.

If you are on 8.1 or older the answer is a migration rather than a patch, because the PHP project ships nothing for those branches. For a storefront, that decision is also a version-target decision, and the dates argue against the smallest hop — 8.2's security support ends on 31 December 2026, so the smallest hop buys about ten weeks.

If you cannot patch today

PHP is blunt that nothing short of updating is sufficient: the measures below "reduce exposure to specific attack paths but do not make an installation safe", and for 8.5.12 it states "There are no complete mitigations, updating is the only safe choice."

With that understood, Sophos's interim list includes setting file_uploads = Off and rejecting multipart/form-data at the web server or WAF. One important gap: Datadog reproduced one of the two CVEs using an application/x-www-form-urlencoded request, so a multipart-only filter does not cover it. If you run a storefront taking payments, a maintenance page for a few hours is a smaller loss than an unpatched pre-auth RCE on a server holding customer data — and that is a commercial judgement, not a technical one.

The question worth taking away

This incident is a clean test of something most e-commerce owners have never checked: how fast can your host patch the runtime, and how would you know? That answer governs every future PHP, nginx or OpenSSL advisory, and it is a procurement question rather than a security one. Runtime calendars are unusually crowded right now, as Node 20 reaching end of life showed the same fortnight.

If the honest answer is "we would find out from a blog post, and we could not verify the fix ourselves", the hosting arrangement is the finding. We run into this on most e-commerce engagements that inherit an existing platform, and it is usually cheaper to fix the arrangement than to survive the next one. Plenty of good hosts patched this within a day; the ones that did not are the ones worth knowing about before December, when 8.2 stops receiving fixes entirely.