PHP2Shell: How Two Critical PHP Flaws Leaked Early, and What to Patch Today

PHP2Shell is the name for two critical flaws in PHP itself that can let an attacker with no login run code on a web server. The PHP project shipped the fixes on October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, one day earlier than planned, after the CVE numbers leaked online. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619.

This piece walks through how the disclosure unfolded and what has happened since. Then it covers what to do by hosting type, how to confirm the PHP version serving your site, and what a firewall can do. Facts are as of the evening of October 21, 2026.

The short version: update the PHP runtime and restart PHP. A WordPress, Drupal or plugin update does not fix this. On a managed host, get written confirmation that the host has patched. On PHP 8.1 or older, you need a vendor backport or an upgrade, and a WAF only buys time.

What PHP2Shell is, in plain terms

PHP2Shell covers two bugs in how PHP handles a request. Neither is in WordPress, Drupal or any plugin.

CVE-2026-109618, "RCE via OOM corruption." When PHP runs out of memory, it jumps out of whatever it was doing. If that happens while internal request data is only half set up, the cleanup step can treat the leftovers as valid. The GitHub advisory says crafted multipart form uploads can push a request out of memory while it still looks within PHP’s limits.

CVE-2026-109619, "RCE via stale global state." PHP reuses worker processes. Some state from a finished request can survive after its memory is freed. The second advisory says a later request on the same worker may use that stale state before PHP resets it.

PHP rates both 9.2 on CVSS v4.0. NVD scores the first 9.8 on CVSS 3.1, and Red Hat rates it 8.1. The leaked posts claimed 10.0.

Calif, one of the research teams, says on its PHP2Shell writeup that it confirmed pre-authentication RCE on WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4 and several other apps.

Which PHP setups face the most risk

PHP’s security advisory says all PHP installations serving web requests are at risk. The risk differs by how PHP runs, which is called the server API or SAPI.

The php.net advisory also lists php-cgi as at risk. Red Hat’s statement on its CVE page says standard RHEL deployments use PHP-FPM, which makes code execution difficult in practice. FPM sites still need the patch.

The PHP2Shell timeline, from audit to private report

The problem was spotted before it had a name. Calif’s writeup lists a 2020 PHP bug report, #78876, in its history of the issue.

The Wiz-run PHP2Shell site credits Wiz Research, Amy Burnett of OpenAI Codex Security and Ryan A. of Calif. It says Google’s Gemini team helped with discovery and patch checks.

Why the fix took 71 days and stayed private

From Calif’s first report on August 11 to the release was 71 days. The work stayed private under coordinated disclosure. Researchers report quietly, the project builds a fix, and distributions and LTS vendors get patches early. PHP’s advisory confirms they did. The target public date was October 22.

The PHP Foundation’s release post is candid about the earlier stall. It says "the delay was a structural failure, caused by both the security team’s decision process and its lack of resources." The Foundation says the team is moving to majority decisions so hard trade-offs stall fixes less.

How the PHP2Shell embargo broke

The Foundation says only the CVE numbers leaked at first, with no technical details. A video changed that.

Why not release at once? The Foundation says distributors were still packaging fixes, so many users would have had no easy update.

Where the sources disagree on dates

Several dates differ by source.

• Planned disclosure. The Foundation says October 22 at 14:00 UTC. watchTowr’s FAQ cites a social post that said 18:00 CEST.
• Cloudflare’s head start. Cloudflare says its rules went live "about 9 hours ahead of public disclosure." By PHP’s 14:00 UTC release time, the gap was about 11 hours.
• Release date. php.net’s announcements say October 21. The 8.5.12 ChangeLog says October 22.
• Oldest affected version. Wiz, Cloudflare and Sansec say PHP 5.4 or later. Calif also says 7.3 or later for mod_php. The advisories list only 8.2 to 8.5.

What has happened since the release

Exploitation. watchTowr’s PHP2Shell FAQ says exploitation was observed in the wild as of October 21. The Hacker News reported that watchTowr saw none at 11:26 UTC and "active exploitation attempts" at 14:19 UTC. Cloudflare’s blog post says it saw attack traffic, with attackers changing payloads to slip past its rules. SecurityWeek reported that Sansec expected mass exploitation within 15 minutes of the patch. No source had reported a confirmed break-in as of The Hacker News’ latest update.

KEV status. watchTowr’s FAQ, last updated October 21, said neither flaw was in CISA’s Known Exploited Vulnerabilities catalog. The NVD record showed no KEV entry as of its October 21 update. We could not reach CISA’s catalog on the evening of October 21 to check again. Our first MCP flaw in KEV post explains what a listing triggers.

Government guidance. The UK’s NCSC published guidance on October 21. It says to update, and to "consider taking the system offline" if mitigations cannot be applied.

Distributions. Ubuntu USN-8948-1 shipped October 21 for 22.04, 24.04, 26.04 and 26.10. Debian’s tracker shows fixes for bookworm and trixie, with sid still unfixed when we checked. PHP told remirepo users to switch, since that repo would not update on release day.

Managed hosts and shared cPanel hosting

On managed WordPress or Drupal hosting, the host patches PHP. Your job is to confirm it. Here is what each host’s status page or docs said on the evening of October 21.

• Kinsta. Its status page logged patches rolling out on October 21, reaching 7.4, 8.0, 8.1, 8.2, 8.3, 8.4 and 8.5 by 23:25 UTC. It says Cloudflare mitigations stay in place for now.
• Pantheon. No PHP security notice on its status page or in its release notes.
• Acquia. No PHP incident on its status page.
• WP Engine. Its status page did not load for us, so we cannot report its position.

Silence on a status page does not mean a host is unpatched. Ask in writing which PHP builds run your sites.

Shared cPanel hosts often run CloudLinux alt-php or cPanel’s ea-php builds. CloudLinux’s October 21 post says Imunify360 ruleset 8.83 blocks the public exploit shape. It calls that a virtual patch, not a fix. Ask your host for the patched alt-php or ea-php package and its release date.

VPS, self-managed servers and containers

On your own server, update the distribution’s PHP packages, then restart PHP-FPM and Apache.

• Ubuntu. Apply USN-8948-1. Releases older than 22.04 get fixes through Ubuntu Pro, per Ubuntu’s CVE page.
• Debian. bookworm’s php8.2 is fixed in 8.2.35-1~deb12u1. trixie’s php8.4 is fixed in 8.4.27-1~deb13u1.
• RHEL and clones. Red Hat’s CVE page did not list fixed packages when we checked. Watch its errata.

Containers. Restarting an old container does nothing. Rebuild from a patched base image and redeploy. When we checked, the docker-library pages for the official php image did not yet list patched tags. Check the tags, build with docker build --pull, then run php -v inside the new container.

How to confirm the PHP version that serves your site

The PHP that answers web requests can differ from the command-line PHP.

1. phpinfo(). Upload a file that calls phpinfo(), load it in a browser, and read "PHP Version" and "Server API." Delete the file right after.
2. WordPress. Go to Tools, then Site Health, then Info, then Server.
3. Drupal. Go to Reports, then Status report, which lists the PHP version.
4. Command line. php -v reports the CLI binary. On a server, also run php-fpm -v (or the versioned name, such as php-fpm8.3) and check the package version.

Distribution packages keep the old upstream number. Ubuntu 24.04’s fixed package is 8.3.6-0ubuntu0.24.04.13, so php -v still shows 8.3.6. Compare the full package version with the distro advisory, not with 8.3.36.

Why PHP 8.1 and older sites are the hardest PHP2Shell case

The PHP project no longer ships releases for 8.1 and older. For PHP2Shell, it posted minimal source backports for 7.4, 8.0 and 8.1 on GitHub. Those help only people who compile PHP themselves.

That leaves three paths: a distro or LTS vendor backport, a host that patches old branches itself, or an upgrade. Ubuntu fixed php8.1 on 22.04. Kinsta reported patches for 7.4, 8.0 and 8.1. Shared hosts vary, so ask.

The Hacker News, citing Mallory, reported about 884,000 internet-facing hosts showing a PHP 8.1 or older banner on October 20. Those are banner counts, not confirmed vulnerable systems.

PHP 8.2 is next. php.net says it reaches end of life on December 31, 2026. Our Q4 2026 platform calendar lists that date beside the CMS deadlines, and our PHP 8.6 preview covers the deprecations to plan for.

What a WAF can and cannot do about PHP2Shell

A web application firewall can block known attack patterns before they reach PHP. Cloudflare’s PHP2Shell rules are on by default for free plans. Paid plans should confirm the Managed Ruleset is set to block.

A WAF cannot fix PHP. Cloudflare says attackers were already mutating payloads, and it tells customers to patch. CloudLinux says its rules may miss requests that differ from the public exploit.

If you cannot patch today, PHP’s advisory lists stopgaps. They reduce exposure but "do not make an installation safe."

• Set memory_limit=-1 in a way apps cannot override, such as php_admin_value.
• Set a low post_max_size: 8M without uploads, 32M with them.
• Set session.upload_progress.enabled=0, and on PHP 8.5, fatal_error_backtraces=0, then restart every worker.

wp2shell and Click2Shell were WordPress core flaws fixed by a WordPress update. PHP2Shell sits a layer below. AI-assisted research helped find it, and our Plugin4Shell coverage shows the other side of AI tools.

Frequently Asked Questions