Skip to content
WordPress Maintenance

A critical flaw in PHP itself — why fully updated WordPress and plugins do not cover it, and how to check your PHP patch version

A critical flaw in PHP itself — why fully updated WordPress and plugins do not cover it, and how to check your PHP patch version

This article reflects public information as of October 28, 2026. The situation keeps changing, so check the sources at the end for current version numbers and exploitation status.

What happened

In late October 2026, two critical vulnerabilities were disclosed in PHP itself, and fixed releases were published. Press coverage and security vendors refer to them by the nickname “PHP2Shell.”

  • The fixed versions are 8.2.35 (8.2 branch), 8.3.36 (8.3), 8.4.27 (8.4) and 8.5.12 (8.5). Earlier versions on those branches are described as affected.
  • Security vendors have attached the identifiers CVE-2026-109618 and CVE-2026-109619 and rate both 9.2 on the CVSS v4.0 scale. The php.net changelog, however, lists the fixes under GitHub advisory IDs, and we could not confirm CVE numbers there — so read the CVE numbers as the vendors’ labels.
  • The release date appears as October 21 (UTC) in vendor write-ups and as October 22 in the php.net changelog, so you may see the date off by a day depending on the source.

Note: A CVE (Common Vulnerabilities and Exposures) is a shared identifier for a specific vulnerability. CVSS is a 0–10 severity score; 9.0 and above falls in the top “Critical” band.

Why updating your applications isn’t enough

WordPress maintenance tends to focus on core, plugins and themes. What makes this case different is that the problem sits not in WordPress or a plugin, but in PHP — the runtime that executes all of them.

Think of a house: you can replace the front-door lock (WordPress core) and every room lock (plugins) with the newest ones, but a flaw in the foundation (PHP) is a separate matter. Per the vendor write-ups, the flaws stem from how PHP handles memory, and researchers have reported demonstrating unauthenticated code execution against WordPress and other applications. (A demonstration is research output, not proof of real-world compromise.)

So even if WordPress, plugins and themes are all fully up to date, a PHP that isn’t on a fixed version means this particular issue hasn’t been addressed.

Reading a PHP version number

A version like 8.3.36 has three parts.

Position Example Meaning
8 Major Large changes; compatibility can break
3 Minor New features; the branch changes (e.g. 8.3 → 8.4)
36 Patch Bug and security fixes within the same branch

The response here is a patch bump within your current branch — if you’re on 8.3.35, you go to 8.3.36. That is a different kind of task from moving from the 8.3 branch to 8.4.

Our earlier article, “What breaks when you upgrade PHP — deprecated vs. removed,” covered what breaks when you cross branches. A patch update takes in fixes without changing features, and its compatibility risk is generally lower than a branch migration. Letting “PHP updates break things, so postpone them” extend to security patch releases is where it gets dangerous.

Checking your PHP version

There are several ways to check, and they can give different answers.

  1. Your hosting control panel: shows the PHP version per domain. This is often the setting that actually runs the website.
  2. WordPress admin: Tools → Site Health → Info → Server shows the PHP version the site is actually running on.
  3. A command over SSH: php -v works, but it reports the PHP used on the command line over SSH, which can differ from the PHP that serves your website.
php -v

Note: On shared hosting, the command-line PHP and the web PHP are often managed separately. A fixed version over SSH doesn’t guarantee the web side is fixed, and vice versa. Since the website is what’s exposed, the control panel or Site Health is the more reliable check.

If the version you find is at or above the fixed versions listed earlier (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12), the fix for this issue is included.

If your version is behind

  • On managed or shared hosting: some providers update PHP on your behalf; others expect you to switch versions in the control panel. Check your provider’s notices and the panel itself — it varies by provider and plan.
  • If you’re on an end-of-life branch: these fixes were released for the supported branches (8.2–8.5). Older branches are reported as unlikely to receive them, which means moving to a supported branch. Before that migration, do the compatibility checks from the earlier article, take a backup, and switch in stages.
  • After updating: make sure the processes that run PHP aren’t still serving the old version. Providers usually handle this; on a server you run yourself, the web server or PHP processes need a restart after the update.

Before and after, confirm that the site renders and that you can log in to the admin.

How this relates to “wait a bit before applying”

On this blog we’ve argued for “not applying WordPress major releases on day one” — for large releases with new features, letting early bugs settle is the safer course.

That premise doesn’t hold here. For a security patch release, the risk of waiting often outweighs the risk of the update itself — and in this case, attack attempts were reportedly seen before the public disclosure. Whether to wait or apply can flip depending on the kind of update: feature release or security fix.

What isn’t clear yet

To keep this accurate, here is what can’t be confirmed at this point.

  • The extent of exploitation: AWS, Cloudflare and Patchstack, among others, have reported attack attempts and reports from hosting providers. Huntress, meanwhile, reported not seeing exploitation across its partner environments (all as of around October 21). Observed attempts and successful compromises are different things, and the full picture of the latter isn’t established.
  • What the logs show: because exploitation happens below the application layer, application logs may show little. “Nothing odd in the logs” can’t be taken as proof of safety.
  • How well published exploit code works: proof-of-concept code is reported to be circulating, but it is tied to specific environments and isn’t guaranteed to work elsewhere as-is.

Coverage updates daily. If you cite numbers or dates, check the sources for the latest.

From a maintenance perspective

This episode illustrates the real scope of maintenance work. It isn’t only WordPress core, plugins and themes — it’s keeping track of the update status of PHP underneath them, and of the server environment underneath that.

If you manage several sites, PHP versions tend to drift from site to site. Without a list of which site runs which version, an advisory like this one means spending time just working out what’s affected. More than the update itself, deciding in advance how to inventory and verify is what pays off in the next emergency.

Sources (checked October 28, 2026)