> marcin_borowski

> php2shell — a memory-safety rce in php's core hits ~70% of the web

// october 21, 2026

PHP2Shell — a Memory-Safety RCE in PHP's Core Hits ~70% of the Web

PHP2Shell — a Memory-Safety RCE in PHP's Core Hits ~70% of the Web

What do you call a vulnerability that doesn't depend on what you wrote in PHP — because the bug lives in PHP itself? On 21 October 2026 the PHP team shipped a patch for a pair of flaws that Wiz Research and OpenAI have grouped under the name PHP2Shell. Estimates put the affected share at nearly 70% of the web. Not because 70% of sites run one vulnerable framework, but simply because that many sites run PHP at all.

What it actually is

PHP2Shell is two vulnerabilities, tracked as:

  • CVE-2026-109618 — a use-after-free in the upload-progress unserializer. CVSS 3.x 9.8 (critical). Enables unauthenticated code execution and reads from process memory.
  • CVE-2026-109619 — a use-after-free in the fatal-error backtrace plus a type confusion in OPcache. CVSS 3.x 8.1. Corrupts PHP's shared state and leads to RCE.

The key point is that the flaws live in the core engine, not in WordPress, Drupal, Joomla, or MediaWiki. The application on top can be written flawlessly — you're still vulnerable, because the bug sits one layer lower. Every PHP release of the last decade, all the way back to 5.4 (2012), is affected by at least one of them.

What's going on under the hood

The common thread is error handling — specifically, how PHP copes when a request ends unexpectedly, for example on an out-of-memory error. In those situations the engine's internal state can be left corrupted, and a subsequent request or worker inherits that state from its predecessor.

In practice:

  • CVE-2026-109618 — an attacker sends a crafted upload with progress data that lands in a use-after-free and lets them read the PHP process's memory. That memory can hold passwords, tokens, API keys, and certificates belonging to other requests or to the server itself.
  • CVE-2026-109619 — via the fatal-error backtrace and a type confusion in OPcache, an attacker corrupts PHP's shared state, which leads to code execution.

Wiz demonstrated pre-auth RCE against WordPress, Drupal, and Joomla — but those are just representative targets. You don't need any of those CMSes to trigger the exploit, because the vulnerable code is in PHP itself.

Where it came from, and why only now

The underlying memory bugs had sat in the code for years. The problem was that building a working exploit required a complex chain of steps and painstaking tuning to a specific server's memory layout. For years that was considered practically infeasible — and inaction rested on that assumption.

That changed when AI models entered the picture: Wiz used its own Wiz Atlas tool alongside Gemini 4 Argon and GPT-5.6 Sol, while researcher Ryan Austin of Calif worked within OpenAI's "Patch the Planet" project. The crucial difference: a model can analyze failed attempts, iterate, and adapt an exploit to different versions and configurations in hours rather than weeks.

This is the moment where AI changes the economics of exploitation — complexity stops being an effective barrier.

The timeline from report to publication:

19 Aug 2026            Wiz discovers the first vulnerability
20 Aug 2026            RCE confirmed on Drupal
21 Aug 2026            RCE confirmed on WordPress
24 Aug 2026            report reaches the PHP security team
21 Sep 2026            PHP confirms and begins coordinating the patch
21 Oct 2026            patched releases ship + public disclosure

How to fix it

The short version: update PHP. Now. The patched releases cover the 8.2, 8.3, 8.4, and 8.5 branches — those are exactly the ones that received the emergency fix on 21 October. Older versions (5.4–8.1) are out of support and won't get an official patch, so the only sensible option is to migrate to a supported branch.

Concretely:

# Ubuntu/Debian — move to a supported release and apply the patch
sudo apt update
sudo apt upgrade php8.3 php8.3-fpm      # or 8.4 / 8.5

# verify the version afterwards
php -v

If you can't apply the patch immediately (say, a legacy system you need to test first), vendors have shipped out-of-the-box mitigations — Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft, and Vercel all prepared WAF rules that block typical exploit signatures as a stopgap. That's a crutch, not a cure, but it's better than nothing until you can upgrade.

Checklist:

  1. Update PHP to 8.2/8.3/8.4/8.5 with the October patch.
  2. If you still run PHP 5.4–8.1, plan a migration — you won't get a patch.
  3. Until you can update, enable your provider's WAF rules.
  4. Rotate tokens and secrets if the server could have been exposed — reading process memory means credentials may have leaked with no trace in the logs.

What it means more broadly

Wiz puts it bluntly: PHP2Shell may be for the AI era what Heartbleed was to 2014 and Log4Shell to 2021. Not because it's one spectacular hole in one place, but because it undermines a foundational assumption: that something hard to exploit is, in practice, safe.

That assumption just stopped being true. When AI drops the cost of finding and weaponizing an exploit by an order of magnitude, "complex, therefore safe" stops being a strategy and becomes a gamble. Patching the core of the languages the web runs on hasn't been this urgent in a long time.

[ << back_to_home ]