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

Introduction

PHP shipped an emergency security release on October 21, 2026, fixing two critical remote code execution bugs in PHP core, CVE-2026-109618 and CVE-2026-109619, which some are calling “php2shell.” The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Details had leaked a day before the planned disclosure, so the usual patch window didn’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 managed WAF rules for these CVEs (covered in the mitigations below), and now that the bug details are public it has detailed how they work, matching on both the request and the origin’s response to catch exploit attempts.

The rules deploy automatically and have been on by default since October 21: Free plans get them through the Cloudflare Managed Free Ruleset, and Pro, Business and Enterprise through the Cloudflare Managed Ruleset. If you’re on Pro, confirm the Cloudflare Managed Ruleset hasn’t been disabled and is set to block, or you won’t be covered. Even so, it buys time, not immunity; Cloudflare itself says to patch PHP regardless.

Hardening Checklist

Patching PHP is the fix, but a few things done ahead of time shrink your exposure and make the patch land faster. A practical pre-patch checklist:

1. Run a supported PHP branch. Make sure every site is on PHP 8.2 or newer (8.3 is a good target) so it will actually receive the fix.
2. Update WordPress core, plugins and themes. This won’t stop the php2shell bug, since that’s in PHP core, not your app, but it’s basic hygiene and limits the damage if a site does get breached. Clear out abandoned plugins while you’re there.
3. Take verified, offsite backups. Back up files and database somewhere off the server (object storage like Backblaze B2, S3 or your host’s remote backups), and keep a portable export you control (for example an All-in-One WP Migration .wpress file). A backup you haven’t test-restored isn’t a backup, so confirm one actually restores.
4. Don’t lean on your WAF for this one. An application firewall helps against known patterns, but php2shell hits PHP’s core before your app runs and its details aren’t public yet. In particular, GridPane’s 7G firewall is solid baseline protection, but to our knowledge it does not block this specific attack. Treat any WAF as a speed bump, not the fix.
5. Turn on automatic security updates so the patch installs fast. On GridPane, servers run unattended security upgrades (checked twice daily) and reboot automatically when required, at a time you can set; see GridPane’s server-updates KB. RunCloud is different: its Patch Manager applies OS and software patches across your servers from one dashboard, but patches are not applied automatically, you trigger them (it does auto-reboot afterward if the patch needs it). So on RunCloud, plan to open Patch Manager and apply the PHP update as soon as it drops.
6. Have a rollback ready. Know how you’ll revert if the update breaks a site: a fresh snapshot, a staging test first, or your host’s one-click restore.

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 your distro’s exact patched build number.

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: says it disabled session.upload_progress on all servers as a temporary mitigation and published two optional nginx templates, and that it will apply PHP patches automatically to 8.2 and newer, so customers need do nothing; it won’t ship patched builds for 8.1 or older and tells anyone still on those to upgrade to 8.2+ (announcement).
• SiteGround: says it assessed PHP’s advance notice and rolled out server-level mitigation rules across all its servers ahead of the official release, disabling the affected functionality on all supported PHP versions; it tells customers their sites are protected with no action needed, and that it’s monitoring the release (announcement).

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: drop a temporary phpinfo.php (<?php phpinfo(); ?>) in the web root, load it in a browser, confirm session.upload_progress.enabled shows Local Value: Off, then delete the file immediately so it isn’t left exposing server details (Shield Security). The directive was 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)

On the hosting side, GridPane published a detailed breakdown of how it is handling php2shell across managed servers, in line with Knecht’s patch-the-moment-it-ships message. Their TL;DR:

• Don’t run sites on PHP lower than 8.2.
• They’ll install PHP package updates as soon as they’re available, using a 15-minute watcher (watching the Ondřej Surý and LiteSpeed repos).
• Put your sites behind Cloudflare and keep the managed rules on.
• Use Migrately to move sites onto Ubuntu 24.04 / 26.04.
• Consider Calvin’s advice and suspend PHP sites until the fix is out. It’s a crapshoot until then, so it’s a real option worth weighing.

We added a fifteen-minute watcher that checks for updated PHP packages and installs them via unattended-upgrades, rather than the usual twice-daily security check. The watcher keeps ticking over and retrying in case the package repositories have difficulty. We also added suggested php.ini mitigations, though we think those probably do very little.

But what about EOL PHP version packages, will those be coming? That question is twofold.

First, EOL PHP versions on supported distributions. We use the Ondřej Surý repos for php-fpm and LiteSpeed’s repos for lsphp. Ondřej Surý has a general policy to maintain packages for in-life distributions, including backports, which is why we can provide older EOL packages during builds: 7.4, 8.0 and 8.1 on 22.04; 8.0 and 8.1 on 24.04; 8.1 on 26.04. As far as we know, that is best effort. LiteSpeed provides older EOL lsphp packages for 22.04 (7.4, 8.0, 8.1) and 24.04 (8.1); since those come from their repo, we anticipate they’ll backport the fix from the supported PHP versions. In both cases it would be rude of them not to, but if they don’t, we’ll need to look at the backport ourselves.

Second, EOL PHP versions on unsupported distributions. Honestly, there is little reassurance we can give here. This is the end of the line. We can’t even build 20.04 boxes to test things on our stack anymore. If we did backport, the versions would be tested against vanilla boxes, but it is an option.

We did push something for session.upload_progress.enabled = Off, but as far as we can tell it is not a panacea and may not help much. On our app we rolled out nginx rules to disable specific POST and encoded form types, but those would break WordPress. Cloudflare has included mitigation in its managed ruleset, which is forced on for free accounts; on paid accounts you’ll need to make sure it is enabled.

— GridPane

GridPane’s Jeff Cleverley also shared early testing against an unpatched 8.2.34 box. The short version: under PHP-FPM the generic multipart attack crashes the worker at startup rather than achieving code execution, and the stale-state flaw (CVE-2026-109619) would need an application-specific way to surface stale state after a request starts. So FPM is more resilient to the off-the-shelf attack than mod_php — which matches PHP’s own “risk highest for mod_php” note — but the binary is still vulnerable, so patch regardless. His test notes:

PHP CLI/FPM/extensions: 8.2.34

• session.upload_progress.enabled: On
• Remote hostname probe: poison 502, trigger 302, recovery 302
• FPM worker 430237 exited with code 70 and was replaced by 430269
• No stale state crossed into the second request
• No remote command execution or /tmp file write occurred
• Local persistent-SAPI verification produced SIGSEGV for both primitives, confirming the downgraded binary is vulnerable

This PHP version is affected, but the generic multipart OOM sequence terminates the FPM worker during startup. Exploiting GHSA-6wmf-4rv5-p3rp through FPM would require an application-specific way to publish stale state after successful request startup.

— Jeff Cleverley, GridPane

GridPane founder Patrick Gallagher followed up with an operational status update. Servers on Ubuntu 26.04 already have the fix; 22.04 and 24.04 will get backported packages, but that could mean hours of extra waiting as builds roll out to the largest installed bases first. If you’re not on 26.04 yet, GridPane points to its Migrately tool to make the move. His early, informal read — with a fuller writeup promised once the dust settles — was cautiously optimistic for GridPane’s stack:

It’s still early but it looks like we’ve possibly dodged this bullet. If you’re on 26.04 then you should already have the update. … As best as I can see, if you’re running our stack, one of these exploits couldn’t touch you at all and the other one seems to be so narrow that it’s probably also a non-starter.

— Patrick Gallagher, GridPane

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

6. Take the Site Offline

The surest way to remove exposure on a site you can’t patch yet is to stop serving it to the public. If a site is stuck on an EOL PHP branch with no backport, or you simply can’t take the risk until the update lands, taking it offline (or putting it behind a login) leaves nothing for an unauthenticated attacker to hit. Both major control panels make this a couple of clicks.

• GridPane: from the site’s management screen, enable HTTP Authentication to put a username and password in front of the whole site, or use Suspend Site to take it fully offline and serve a suspended-site page. Suspend is the hard stop; HTTP auth keeps the site reachable for you and the client while shutting out the public.
• RunCloud: for a password wall, open the web app and go to Tools → Site Authentication, set a username and password, and click Enable HTTP Authentication — wrong or cancelled credentials return a 401 before any PHP runs (docs). RunCloud has no one-click suspend, so to take a site fully offline you point the web app’s Public Path (web app → Settings) at a folder holding a simple maintenance index.html, then Update Stack; restore the original path to bring it back (docs). Note the placeholder is served as 200 OK, and on Git or Atomic deployments the Public Path change can be overwritten on the next deploy.

This takes the site away from real visitors too, so it’s a containment measure for the patch window, not a fix. Reach for it when a site can’t be patched in time and the downtime costs less than the risk.

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. The fix shipped on October 21, 2026 as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, so update to at least those builds. The last releases before the fix were 8.5.11, 8.4.26, 8.3.35 and 8.2.34 (The Hacker News). PHP 8.1 and older are end of life and get no official release; the PHP security team did publish minimal source backports for 7.4, 8.0 and 8.1 for people building from source, but plan to upgrade rather than rely on those. Keep in mind 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?

This has changed since the release. As of October 22, security firms are reporting active exploitation attempts: watchTowr says it is observing attempts against both CVE-2026-109618 and CVE-2026-109619, and SecurityWeek notes several firms began seeing attempts, some even before the fix shipped; the UK’s NCSC issued an alert on October 21. There’s no public confirmation yet that an attempt has succeeded, and the flaws aren’t yet listed in CISA’s Known Exploited Vulnerabilities catalog as of this writing, though a proof-of-concept surfaced through the pre-disclosure leak. For scale, when CVE-2024-4577 went public in 2024 Akamai saw exploit attempts within 24 hours (The Hacker News), and Sansec expected mass attacks within about 15 minutes of this release. Treat every unpatched site as a target and patch now.

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

Update (October 21, 2026): the fix is out. The PHP project has released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which patch both vulnerabilities: CVE-2026-109618 (RCE via out-of-memory corruption) and CVE-2026-109619 (RCE via stale global state). PHP states there is no complete mitigation and that updating is the only safe choice, with the risk highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs. PHP 8.1 and older receive no official release; the security team published minimal source backports for 7.4, 8.0 and 8.1 for anyone building from source. Full details and fixed versions are in the official PHP security advisory.

• October 22, 2026: Updated the exploitation-status FAQ — security firms (watchTowr, SecurityWeek) now report active exploitation attempts against both CVEs, with a UK NCSC alert; no confirmed successful compromises yet.
• October 21, 2026: PHP released the fix (8.5.12, 8.4.27, 8.3.36 and 8.2.35). Added the official advisory summary and link above.
• October 21, 2026: Added RunCloud’s official response (session.upload_progress mitigation, optional nginx templates, automatic patching for PHP 8.2 and newer) to the provider list.
• October 21, 2026: Added SiteGround to the provider responses.
• October 21, 2026: Expanded the GridPane section with Jeff Cleverley’s FPM test findings and Patrick Gallagher’s status update.
• October 21, 2026: Added a sixth mitigation, “Take the Site Offline,” covering GridPane (HTTP Authentication / Suspend Site) and RunCloud (Site Authentication / Public Path).
• October 21, 2026: Added a phpinfo verification step to the upload-progress mitigation (Shield Security).
• October 21, 2026: Added a Hardening Checklist (run a supported PHP branch, update WordPress, keep verified offsite backups, don’t lean on a WAF, turn on automatic security updates on GridPane/RunCloud, have a rollback ready).
• October 21, 2026: Added GridPane’s detailed response alongside Cloudflare’s, including its php2shell TL;DR.
• October 21, 2026: Consolidated the “disable session upload progress” fleet rollout into single copy-paste scripts for Debian/Ubuntu and for RunCloud.
• October 21, 2026: Added the Cloudflare managed WAF mitigation and statements from Cloudflare CTO Dane Knecht.
• October 21, 2026: Initial post, published ahead of 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