php2shell: Critical PHP RCE Hits WordPress Sites — What You Need to Know

Introduction

PHP will ship an emergency security release on October 21, 2026 at 14:00 UTC (10:00 AM Eastern). It fixes two critical remote code execution bugs in PHP core, CVE-2026-109618 and CVE-2026-109619, which some are calling “php2shell.” Details leaked a day before the planned disclosure, so the usual patch window doesn’t apply.

If you run WordPress or WooCommerce, do three things today: find out which PHP version every site runs, find out who patches PHP on each server, and be ready to update the moment the release lands.

How the Vulnerability Works

PHP itself hasn’t published the root cause, so this is the shape of the attack as researchers describe it, not a confirmed mechanism. The specifics are deliberately left out here.

When a request comes in, the web server hands it to PHP, and PHP starts preparing it before any of your WordPress, plugin or theme code runs. These bugs live in that early core stage. A crafted request corrupts PHP’s own memory during that handling, and an attacker who does it precisely can turn that corruption into running their own commands on the server, as the web user (www-data or similar).

Three things make that serious:

• No login needed. The request is unauthenticated. The attacker doesn’t need an account, an API key or a valid session.
• Any PHP page is a door. Because the bug is reached during core request handling, almost any script that runs PHP will do, even a near-empty one. The attacker doesn’t need a vulnerable plugin or a particular URL.
• Your app never gets a say. The code executes below your application, so a well-built, fully updated WordPress site is just as exposed as a neglected one. This is why patching PHP, not hardening the app, is the fix.

In practice, a successful attack tends to show up as PHP suddenly running shell commands, which is exactly what the detection section below looks for. For a deeper technical rundown, watchTowr’s FAQ is the authoritative source.

What We Know So Far

Two bugs in PHP core allow remote code execution. The PHP security team rates both CVSS v4.0 9.2. CERT-EU reads that score as a sign they may be exploitable without authentication.

• The leak is real. On October 20, details surfaced before coordinated disclosure. watchTowr confirmed the bugs and says it reproduced CVE-2026-109618 (Huntress).
• The release moved up. PHP pulled the release forward a day from the original embargo date of Thursday, October 22. It says it may ship even sooner if details go public or attacks appear in the wild.
• Ignore the 10.0. Early social posts claimed CVSS 10.0. The official score is 9.2.
• No technical details yet. The bug class, affected code paths and fixed versions will be published with the release.
• Expect attacks fast. Sansec expects mass attacks within 15 minutes of the release.

Affected Versions and Exposure

Assume every PHP site you run is affected until the official advisory says otherwise. PHP hasn’t published affected versions, but early reports agree the range is wide:

• CERT-EU says PHP 5 onward could be affected; Sansec says PHP 5.4 and later, based on a leaked screenshot of an exploit tool called PHP2Shell that claims to work against every release from 5.4.0 on. watchTowr notes that PHP hasn’t confirmed the version range or described any configuration requirement.
• Only PHP 8.2, 8.3, 8.4 and 8.5 will get the fix. Those are PHP’s four supported branches. PHP 8.1, 8.0, 7.x and 5.x are end of life and get no patch.
• Exposure is large. Silas Cutler of Censys estimated over 1.38 million internet-exposed hosts running affected PHP configurations (KloudBoy). Mallory put it lower, at about 884,000 hosts advertising PHP 8.1 or older. The gap is method: Mallory counted only version banners, which undercounts hosts that hide their version, while Censys matched affected configurations more broadly.

This is a bug in PHP itself, not in WordPress, a plugin or a theme. Keeping WordPress core and plugins current won’t protect you here. Every WordPress, WooCommerce, Drupal or Magento site on a vulnerable PHP build is exposed, however well maintained the application is.

The biggest risk is sites still on PHP 8.1 or older. Those branches are end of life and likely won’t get a fix.

Immediate Mitigation Steps

1. Inventory PHP versions

In WordPress, open Tools → Site Health → Info → Server for the version a site actually runs. On a server you control, list what’s installed:

# Debian/Ubuntu: every PHP package and version installed
dpkg -l | grep -E '^ii\s+php[0-9.]+-(fpm|cli)'

# Which FPM services are running
systemctl list-units --type=service | grep -i php

A server can run several PHP versions side by side, and PHP also hides in control panels like cPanel and Plesk, vendor appliances and Windows software. Check every pool and install, not just php -v.

2. Find out who patches PHP

On managed hosting or a control panel (GridPane, RunCloud, Cloudways, cPanel and so on), the provider usually builds and pushes the PHP packages. Check their status page or support channel for their plan. On a self-managed server, it’s you.

3. Line up the update

Know your package source (distro, Ondřej Surý’s PPA, Remi, a container image) and how you’ll restart PHP-FPM. Schedule the window now rather than waiting until the release lands.

4. Take fresh backups

Patching PHP should be routine, but a known-good snapshot makes it safe to move fast.

5. Don’t count on a WAF

Cloudflare has pushed emergency rules (covered in the mitigations below), but no WAF can reliably block a bug whose details aren’t public. A WAF rule buys time; it’s not a substitute for patching.

Installing the PHP Security Update

The fix reaches most servers through the operating system’s package manager, not from php.net. Your Linux distribution rebuilds its PHP packages with the patch and pushes them to its repositories, usually within hours of the release, and sometimes before PHP’s own source tarballs. So the update is a normal package upgrade once your distro ships it.

On a server you manage yourself:

# Debian / Ubuntu
sudo apt update
sudo apt upgrade php8.3-fpm php8.3-cli php8.3-common   # match your version(s)
sudo systemctl restart php8.3-fpm

# RHEL / AlmaLinux / Rocky
sudo dnf update 'php*'
sudo systemctl restart php-fpm

Afterward, confirm the running version is the patched one and that PHP-FPM actually restarted:

php -v
systemctl status php8.3-fpm --no-pager

If you run several PHP versions on one box, upgrade and restart each one. A package upgrade alone doesn’t reload running FPM workers, so the restart matters.

Keep an eye on your distribution’s security tracker (Ubuntu USN, Debian DSA, the Remi repo for RHEL) for the exact patched build number once PHP publishes it.

Managed Hosting and Control Panels

On managed hosting and control panels, the provider builds and pushes PHP for you. Confirm their plan and timing rather than patching by hand. What the major WordPress hosts have said so far:

• GridPane: said on Facebook that it will apply the PHP update to managed servers once it’s released.
• RunCloud: no response yet.

Mitigations to Reduce Exposure

PHP hasn’t published root-cause details, so there’s no official workaround yet. The measures below reduce exposure; see the final item on the theory they’re based on.

The measures below reduce exposure while you wait for, or roll out, the official patch. Neither is confirmed to stop these CVEs, so treat them as defense-in-depth layered on top of patching, not as a replacement for it. Test each on staging before production.

1. Disable session upload progress

The most targeted option, and the one that works on nginx. If your sites don’t need the upload-progress feature, disable it:

; in php.ini or a pool config, then reload PHP-FPM
session.upload_progress.enabled = Off

Verify it from the web SAPI, not just the CLI, since the two can differ. Introduced in PHP 5.4, so it has no effect on 5.2.

To roll this across a fleet, use one of the copy-paste scripts below. Each one writes the directive into every installed PHP version, reloads FPM, and prints what each binary actually resolves, so you can confirm it took. Pick the one that matches your stack.

# Debian / Ubuntu (standard /etc/php/VERSION/ layout)
for d in /etc/php/*/fpm/conf.d /etc/php/*/cli/conf.d; do
  echo "session.upload_progress.enabled = Off" > "$d/99-php2shell-hardening.ini"
done
for v in $(ls /etc/php/); do
  systemctl is-active --quiet "php$v-fpm" && systemctl reload "php$v-fpm" && echo "reloaded php$v-fpm"
done
for b in /usr/sbin/php-fpm* /usr/bin/php-fpm*; do
  [ -x "$b" ] && printf "%s: " "$b" && "$b" -i 2>/dev/null | grep -m1 'session.upload_progress.enabled'
done

# RunCloud (per-version dirs at /etc/php8Xrc/conf.d/, single conf.d, no cli split)
for d in /etc/php8*rc/conf.d; do
  [ -d "$d" ] && echo "session.upload_progress.enabled = Off" > "$d/99-php2shell-hardening.ini"
done
for d in /etc/php8*rc/conf.d; do
  v=$(basename "$(dirname "$d")")          # e.g. php81rc
  systemctl is-active --quiet "$v-fpm" && systemctl reload "$v-fpm" && echo "reloaded $v-fpm"
done
# Verify the file is in place for each version:
grep -r 'session.upload_progress.enabled' /etc/php8*rc/conf.d/99-php2shell-hardening.ini

RunCloud puts each version in its own /etc/php8Xrc/ directory (php81rc, php82rc, and so on) with a single conf.d and no separate CLI path, so its layout differs from a stock Debian/Ubuntu box — hence the separate script. On cPanel, Plesk or RHEL-family servers the layout differs again, so check your PHP config paths and FPM service names and adjust the globs before running.

2. Block multipart POSTs at the edge

An option only if a site genuinely has no uploads or multipart forms. This and the upload-progress toggle above trace to the php2shell-protection toolkit from Felipe Daragon of Syhunt, built on an unconfirmed theory that the bug is reached through PHP’s upload-progress handling of multipart POSTs. The repo ships an Apache .htaccess rule and a test harness. The rule rejects every multipart POST, so it will break media uploads, Gutenberg image drops and any form that posts files, which rules it out for most WordPress sites. On a GridPane or RunCloud (nginx) fleet the .htaccess rule doesn’t apply anyway; the equivalent is an nginx rule, and the same caveat holds.

3. Disable OS-execution functions

If your sites don’t legitimately shell out, disable PHP’s OS-execution functions. This won’t stop the memory corruption itself, but it blunts the common payload that runs system() or shell_exec():

; php.ini, then reload PHP-FPM
disable_functions = exec,passthru,shell_exec,system,proc_open,popen

Some plugins and tools (image processors like ImageMagick or Ghostscript, some backup plugins) call these functions legitimately and will break, so test on staging.

4. Upgrade to a Supported PHP Version

The real fix, and the only one that resolves the vulnerability rather than working around it. Treat a site on PHP 8.1, 8.0 or 7.x as unpatchable until proven otherwise, since those branches are end of life and won’t get a fix. Upgrade to PHP 8.2 or newer (8.3 is the better target); test on staging first, as most current WordPress plugins already run on PHP 8.1+. If a site can’t move because of a legacy plugin or theme, isolate it (CERT-EU recommends taking internet-facing apps off public networks until a fix is in place) and have that upgrade conversation with the client now.

5. Enable the Cloudflare WAF

If your sites sit behind Cloudflare, it has pushed an emergency managed WAF rule set that blocks anomalous-execution request patterns matching this attack. Cloudflare’s CTO has confirmed the rules target these PHP vulnerabilities. To benefit, make sure the site is proxied through Cloudflare (orange cloud on, not DNS-only) and that the Cloudflare Managed Ruleset is deployed on the zone. On Pro and up, check that the relevant rules are set to Block rather than Log. This is edge protection that buys time; it doesn’t cover direct-to-origin traffic and isn’t a substitute for patching.

Cloudflare CTO Dane Knecht confirmed on X that the rules target these vulnerabilities and that attacks have begun:

PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free. We are seeing early attacks emerging and are updating mitigations as new vectors show up. This is a STOPGAP only. Patch as soon as the PHP Foundation releases the update at 14:00 UTC today.

— Dane Knecht, Cloudflare CTO (on X)

If you are paid Cloudflare customer you need to make sure you haven’t disabled the WAF or set new rules to be in log only mode.

— Dane Knecht (on X)

A WooCommerce store or any site with a media library will feel the multipart block immediately, so stage these carefully.

Detecting Exploitation

Exploitation most often shows up as PHP starting programs it shouldn’t. Huntress says that pattern appears in nearly every PHP intrusion it handles. Three things to check:

1. Watch for PHP spawning processes

Alert when a PHP worker (php-fpm, php-cgi, apache2, httpd) launches a shell, interpreter or download tool. A one-off look at current process trees:

# Any shell/download tool whose parent is a PHP or web process
ps -ef | grep -E 'php-fpm|php-cgi|apache2|httpd' | grep -E 'sh |bash|python|perl|curl|wget|nc '

In command lines, reverse-shell and recon markers like /dev/tcp/, fsockopen, mkfifo, whoami, id and uname -a are worth a closer look.

2. Check for new files and cron jobs

After the release, scan for recently dropped PHP files and changed cron entries:

# PHP files changed in the last 2 days (plugin updates show up too)
find /var/www /home -name '*.php' -mtime -2 -type f 2>/dev/null

# Recently changed cron jobs
ls -lt /var/spool/cron/crontabs/ /etc/cron.d/

If you find something, isolate the server, preserve the web server and PHP logs, and look for web shells, new files in the web root, new cron jobs and new user accounts.

3. Monitor with process-watcher

If a server has no EDR, Florian Roth’s free process-watcher logs every program a PHP process starts, with its full command line, so you can spot a shell being spawned. It runs as a small agent on Linux (kernel 5.15+, root) and can optionally kill suspicious child processes, though on WordPress that risks breaking mail(), which goes through a shell. It records after the fact and blocks nothing, so treat it as a detection layer, not a patch. See its README for the full setup.

FAQ

What versions of PHP will get the security fix?

Only PHP’s four supported branches: 8.2, 8.3, 8.4 and 8.5. PHP will publish the exact fixed version numbers with the October 21 release. According to The Hacker News, the latest releases before the fix were 8.5.11, 8.4.26, 8.3.35 and 8.2.34, so the patched versions will be newer than those. PHP 8.1 and older are end of life and won’t get a fix, so plan to upgrade rather than wait. Keep in mind that PHP 8.2 only gets security fixes until December 31, 2026.

Is WordPress itself vulnerable?

No, the bugs are in PHP, the language WordPress runs on. A fully updated WordPress site is still exposed if its server runs a vulnerable PHP build.

Will a security plugin like Wordfence protect me?

Don’t rely on it. Sansec says the attack appears to hit PHP itself, before your WordPress code or any plugin runs, so it has to be fixed at the server level. Security plugins run inside PHP, and they can’t reliably detect an attack whose details aren’t public. An edge WAF like Cloudflare’s emergency rules may block some attempts before they reach PHP, but patching PHP is the fix.

Is it being exploited in the wild?

Not as of October 21. Huntress hasn’t seen exploitation in its partner environments, watchTowr lists none reported, and the flaws aren’t in CISA’s Known Exploited Vulnerabilities catalog. No public exploit code is known, though a short exploitation video was briefly posted online and then removed, and Cloudflare’s CTO reported early attacks emerging against sites behind Cloudflare. Expect that to change fast: when CVE-2024-4577, an earlier PHP flaw, went public in 2024, Akamai saw exploit attempts within 24 hours (The Hacker News). Sansec expects mass attacks within 15 minutes of this release.

Will my host patch this automatically?

Most managed WordPress hosts and control panels build and push PHP updates for you, but timing varies. Check your host’s status page or ask support. On a self-managed VPS, you patch it yourself. Sansec recommends asking your host today to stand by. If you’re on PHP 8.1 or older, ask them to backport the fix or move you to a supported version.

I’m on PHP 7.4. What should I do?

PHP 7.4 is end of life and won’t get a fix, like everything below 8.2. Upgrade to PHP 8.2 or newer (8.3 is the better target), or restrict public access to the site until you can.

Updates

This post will be updated once PHP publishes the release, with fixed versions and technical details.

• October 21, 2026: Initial post, published before the PHP release.

Sources

• CERT-EU Security Advisory 2026-018
• PHP news archive: upcoming security release
• Huntress: php2shell rapid response
• The Hacker News: PHP2Shell, two unpatched critical PHP RCE flaws
• Sansec: Critical PHP RCE
• watchTowr: PHP Remote Code Execution FAQ
• Mallory: PHP RCE rapid response
• KloudBoy: PHP2Shell analysis
• Syhunt: php2shell-protection toolkit
• Cloudflare changelog: Managed Ruleset emergency release
• Cloudflare changelog: Free Ruleset emergency release
• Florian Roth: process-watcher PHP quick start