Security alert

PHP2Shell: What the critical PHP flaws mean for WordPress sites

By Lucas Weber, CyberSec42 · Updated 22 Oct 2026

On 21 October 2026 the PHP project fixed two critical security flaws, CVE-2026-109618 and CVE-2026-109619, known as "PHP2Shell". Any website running a PHP version below 8.2.35, 8.3.36, 8.4.27 or 8.5.12 is affected, which includes most WordPress sites. The fix is a PHP update, usually done at your hosting provider. This article shows how to check in a few minutes whether your site is already patched, and which attack surfaces WordPress still has after the update.

In short.

Two flaws in PHP itself, both rated 9.2 under CVSS 4.0. They can lead to code execution on the web server without authentication.
Patched versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older no longer receive official releases.
According to Germany's federal cyber security agency BSI (as of 21 Oct 2026), no confirmed attacks are known, but there are unconfirmed reports of existing exploits.
WordPress shows the PHP version actually running under Tools, Site Health. Your hosting panel may show a different one.
The PHP update closes this one flaw. Plugins, user accounts and exposed interfaces remain attack surfaces of their own.

What happened

On 20 October 2026, details of two unpublished PHP flaws leaked ahead of coordinated disclosure. The PHP project then scheduled security releases for 21 October, 14:00 UTC, and published them together with two advisories. The same day, the BSI issued a cyber security warning titled, in translation, "PHP: critical vulnerabilities threaten web applications worldwide".

Technically, both are flaws in how PHP manages memory:

CVE-2026-109618 ("RCE via OOM corruption"). If PHP runs out of memory at a particular point, request memory is left in an invalid state. An attacker can trigger this deliberately, for example with crafted file uploads (multipart requests). According to the PHP advisory, under Apache with mod_php this happens before any application code runs. For PHP-FPM, the advisory considers the flaw exploitable based on source analysis, but no complete exploit has been shown there.
CVE-2026-109619 ("RCE via stale global state"). PHP worker processes handle many requests in sequence. If state from one request is left behind, a later request in the same process can access memory that has already been freed. With careful preparation, this also leads to code execution.

Neither flaw is trivial to exploit; the CVSS vector lists high attack complexity and attack requirements. That is no reason to wait. Once a patch is public it can be analysed, and the path to a working attack gets shorter.

Which versions are affected

PHP branch	Affected	Patched from
8.5	below 8.5.12	8.5.12
8.4	below 8.4.27	8.4.27
8.3	below 8.3.36	8.3.36
8.2	below 8.2.35	8.2.35
8.1 and older	no more official releases	move to a supported branch

One exception: Linux distributions and some hosting providers backport fixes into older version numbers. There, a version number below the table does not necessarily mean "unpatched". Only your provider's statement about your exact package gives certainty.

How to check your WordPress site yourself

Look in WordPress

Tools, Site Health, tab "Info", section "Server". It shows the PHP version your site is actually running on. This is the most reliable source.

Compare with your hosting panel

If the panel shows a different version than WordPress, WordPress wins. We have seen this in practice: a line in the .htaccess file overrode the version set in the panel.

Read "automatic updates" carefully

With some providers this only means updates within one branch. A site on 8.1 then stays on 8.1, and that branch no longer gets official fixes.

Check the site after switching

Click through the home page, contact form, shop or booking flow once. Changing the PHP branch can break older plugins.

Look for traces

New administrator accounts, unknown PHP files in the uploads folder, new scheduled tasks and unexpected redirects are warning signs worth checking regularly, regardless of this flaw.

From the outside, the version is often not visible. Many servers do not send it, and a page cache can hide it on the home page while other paths still show it. An external check can therefore have three outcomes: patched, not patched, or not determinable from outside. In the third case, only a look from the inside helps.

mod_php or FPM: how exposed your site is

According to the PHP advisory, how easily CVE-2026-109618 can be exploited depends on how PHP is connected to the web server. This connection is called the SAPI, and WordPress shows it in the same place as the version: Tools, Site Health, Info, Server, row "PHP SAPI".

"PHP SAPI" shows	Meaning	Assessment per PHP advisory
`apache2handler`	Apache with mod_php	Most exposed: the flaw is triggered before any application code runs.
`fpm-fcgi`	PHP-FPM	Also susceptible based on source analysis; no complete exploit has been shown.
other, e.g. `litespeed`, `cgi-fcgi`	LiteSpeed, CGI/FastCGI	Not specifically assessed in the advisory.

The table helps you prioritise if you look after several sites. It is no reason to postpone an update: CVE-2026-109619 does not depend on this distinction, and only a patched version is patched.

Suspected compromise: the first steps

If your site was unpatched for a while and you notice anything unusual, follow a simple order. Preserve first, then clean up, otherwise you lose the traces that show what happened.

Take the site offline or switch to maintenance mode

This stops further access by the attacker and prevents malicious code being served to visitors.

Preserve evidence before deleting anything

Web server and PHP logs, a full copy of the files and a database export. Many providers delete logs after a few days.

Look for the usual leftovers

New administrator accounts, PHP files in the uploads folder, recently changed files in plugins, themes and mu-plugins, new scheduled tasks, a modified .htaccess.

Change all credentials

WordPress accounts, database, FTP/SFTP, hosting panel, API keys and the security keys (salts) in wp-config.php. Any password stored on the compromised server must be treated as known.

Return to a clean state

The safest route is a backup from before the attack, followed immediately by all updates. Cleaning the running system is possible but error-prone: one missed backdoor is enough.

Check reporting obligations

If the attacker had access to personal data, for example from contact forms or customer accounts, a notification to the data protection authority within 72 hours may be required under Art. 33 GDPR. Clarify this with your data protection officer.

What keeps WordPress exposed after the PHP update

PHP2Shell is a flaw in the foundation. Most successful attacks on WordPress sites, however, go through other places, and those stay unchanged after the update. Our guide WordPress security gives the full overview.

Plugins and their supply chain

A few days before PHP2Shell, tampered copies of version 3.0.123 of the premium plugin Rank Math PRO were delivered through its official download and update channel, in a window from 15 to 16 October 2026 (CVE-2026-111862, CVSS 9.8). Anyone who updated during that window received a backdoor. Important: the follow-up update to 3.0.124 does not remove the injected files, accounts or tasks. An update is not a cleanup.

Outdated plugins and themes

Every installed plugin is additional code with its own flaws, even when deactivated. What is not needed should be deleted, not just switched off.

Exposed usernames

By default, WordPress reveals the login names of its editors through the REST API and author pages. Attackers then only need the password.

The login itself

Administrator accounts without a second factor and shared logins are the shortest way in. This includes xmlrpc.php, an older interface that lets many passwords be tried in a single request.

Outdated software at the provider

PHP branches, database and server versions without security updates often only surface when a warning like this one arrives.

Backups without a restore test

After an incident like Rank Math, a clean state from before the attack is the fastest way back. Whether it works only shows in a practised restore.

How we can help

For companies that cannot or do not want to check themselves, we offer a free external quick check. It only looks at what your site already serves publicly: the PHP version where visible, whether usernames can be retrieved, whether xmlrpc.php is reachable, and which software versions are recognisable from outside. No attacks, no load tests and no access to your system. You receive a short written assessment, including "not determinable from outside" when that is the honest answer.

If you want to go further, we offer hardening and testing within a scope agreed in writing: plugin inventory and update paths, user and permission model, login with a second factor, interfaces, hosting configuration and a restore test of your backup.

Is your site already patched?

Send us your domain and the keyword "PHP2Shell" via the form. We will get back to you with the result of the free external quick check.

Request a quick check

The quick check only evaluates publicly served information and does not replace a full security review. CyberSec42 provides independent technical security testing. It is not an accredited certification body and does not provide legal advice.

Frequently asked questions

Is my WordPress site affected by PHP2Shell?

If it runs on PHP below 8.2.35, 8.3.36, 8.4.27 or 8.5.12 and your provider has not applied its own fix, yes. WordPress shows the running version under Tools, Site Health, Info, Server.

Is a WordPress update enough?

No. The flaws are in PHP, not in WordPress. Only a patched PHP version on the server fixes them, which you usually set in your hosting panel or request from your provider.

What do I do with PHP 8.1 or older?

Move to a supported branch, ideally 8.3 or newer, and then click through your site. There are no more official PHP releases for 8.1 and older.

Is the flaw already being exploited?

According to the BSI warning of 21 Oct 2026, no confirmed attacks are known, but there are unconfirmed reports of existing exploits. The situation can change quickly, so it is worth updating without waiting.

What does the free quick check cover?

Only what your site serves publicly: the PHP version where visible, retrievable usernames, reachability of xmlrpc.php and recognisable software versions. No attacks and no access to your system.