Update · Published October 21, 2026

php2shell: critical remote code execution in PHP itself

Two flaws in PHP — the software almost every website runs on — let a stranger take over your site, even with no plugins installed. WordPress auto-updates do not close them: only your host can.

CriticalIn effect since October 21, 2026Fix released 21 October 2026, 14:00 UTC. No official fix is expected for PHP 8.1 and older.

AffectsEvery WordPress site · WooCommerce shops · Anything running PHP

A WordPress dashboard that says "everything up to date" tells you nothing about this one. The flaw is one level below WordPress, in PHP itself — and that level belongs to your hosting provider.

What happened

Underneath every WordPress site runs PHP — the software that builds your pages in the first place. Two flaws sit in exactly that software: an attacker can run their own code on your server, with no password and no login. At that point the site is effectively theirs. The two are tracked as CVE-2026-109618 and CVE-2026-109619, nicknamed php2shell, and both are rated critical (CVSS v4 9.2 out of 10).

The flaws are in the PHP interpreter itself, not in WordPress, not in a plugin and not in a theme. That is what makes this one different from the usual plugin advisory: a site with no plugins at all is exposed, and the reported affected range covers PHP 5.4 through 8.5 — effectively every PHP version in use. The fix was published on 21 October 2026 at 14:00 UTC.

Affected: PHP 5.4 through 8.5, as reported with the advisory
Not fixed: PHP 8.1 and older are not expected to get an official patch
Independent of plugins, themes and WordPress version

Is it being exploited?

Reported, yes — but worth stating precisely rather than dramatically. Patchstack's live timeline said "multiple active exploitation incidents confirmed" on the morning of 21 October without naming who observed them. watchTowr reproduced one of the two bugs but had not seen in-the-wild use at the time of writing, and a demonstration video shows command execution on test installs of WordPress, Drupal and Magento.

So: treat it as urgent because the barrier is low and the payoff is total, not because your own site is known to be under attack.

Why WordPress updates will not save you

This is the part most site owners get wrong, and it is the whole reason this post exists. WordPress auto-updates patch WordPress, its themes and its plugins. They cannot patch PHP, because PHP is the program that runs WordPress in the first place.

Patching PHP is the hosting provider's job. On managed hosting (Hostinger, Cloudways, SiteGround and the like) you wait for them and then verify. On your own server somebody has to install it by hand. Either way, a WordPress dashboard showing "everything up to date" tells you nothing at all about php2shell.

Three things we hit while patching our own servers

We patched the servers we maintain on the day of the release, between 14:46 and 17:00 UTC. Three things cost time and are worth knowing before you start:

The distribution mirror lagged. On Hetzner the patched Ubuntu package was not there yet; pulling it from a temporary source pointing directly at security.ubuntu.com had it immediately — and that source has to be removed again afterwards.
`php -v` tells you nothing about the web. The command line and the web server can run different PHP builds. Under mod_php and under PHP-FPM both need restarting, and the version has to be verified from the web, not from the shell.
The interim mitigation is a stopgap, not a fix. Setting `session.upload_progress.enabled = 0` is unofficial and may only block one of the two bugs; as `.htaccess` `php_flag` it works under mod_php and returns a 500 under PHP-FPM. PHP's own position is that only patching helps.

What to do

Find out which PHP version you are onWordPress backend → Tools → Site Health → Info → Server. Note the version and whether it is 8.2 or newer.
Ask your host, in writing, when the patched build landsManaged hosting patches on its own schedule and rarely announces it. Ask for the date and the exact PHP version, so there is something to verify against.
Verify the patch from the web, not from the shellAfter the host has patched, check the version in Site Health again. On your own server restart Apache or PHP-FPM and confirm the web PHP reports the patched build.
Move anything on PHP 8.1 or olderNo official fix is expected there, so no amount of waiting helps. Those sites need an upgrade to PHP 8.3 or 8.4, tested on a copy first.
Look for traces afterwardsNew or changed .user.ini files, unknown PHP files in the web root, plugins and mu-plugins, unexpected admin users, PHP files newer than the day before the advisory.

What we take off your hands

Standby Website: a static copy for the outage

When your site has to go offline — a critical PHP flaw, a hack, an outage at your host — we switch a finished static copy live. You stay reachable and you keep your rankings.

WordPress Security Hardening: Secure Your Site Preventively

We review your entire WordPress installation, reduce unnecessary attack surfaces, and implement targeted security measures for login, user accounts, files, database, server, and firewall.

WordPress Audit: A Technical Analysis of Your Website and WooCommerce Shop

We examine your WordPress installation or WooCommerce shop and clearly show you where the technical risks, performance bottlenecks, and unused potential lie.

WordPress Maintenance

Updates, backups, security, and technical issues — with direct developer support instead of a ticket system.

Sources

Technical assessment based on the advisories listed above, at the time of writing. Which PHP version your site serves, and whether it has been patched, can only be answered on your own server — so treat this as the reason to check, not as a verdict on your site.

Not sure whether your server is patched?

Send us your domain. We will tell you which PHP version it serves and whether the patch is on it — ten minutes, no charge, no strings.

Free intro call hello@hechenbros.com

All updates