← All writing

VULNERABILITY

PHP2Shell: Here's what you need to know

4 min read

Read on Medium

Updated 21 October 2026, after the official PHP security release.

Most vulnerabilities live in an application: a WordPress plugin, a Laravel package, a misconfigured upload form. This one is different. PHP2Shell is the name for two critical bugs in the PHP interpreter itself. If your server runs a vulnerable PHP version, the app on top doesn't matter.

Roughly 7 in 10 websites run PHP, including every WordPress, Drupal, Magento and Joomla site. Security researcher Kevin Beaumont has called it one of the biggest vulns in years.

TL;DR

  • What: two unauthenticated remote code execution bugs in PHP core, CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2
  • Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35
  • Affected: every version before those, on any setup that serves web requests
  • Exploited: yes, attacks were reported before the patch even shipped
  • Fix: update. There is no configuration workaround.

What broke

Both advisories are now public on GitHub. At a high level:

CVE-2026-109618: RCE via OOM corruption (GHSA-w8hw-w9fx-j79w). When PHP runs out of memory, it can bail out of a request while internal request data is only partly set up. The cleanup code that runs afterwards then trusts that half-built data as if it were valid.

CVE-2026-109619: RCE via stale global state (GHSA-6wmf-4rv5-p3rp). Some state that belongs to one request can outlive the memory behind it. The next request handled by the same worker process can touch that stale state before it gets reset.

Both are memory-safety bugs in request lifecycle handling, which is exactly why they're so dangerous: they sit before your application code. A working exploit has shown that a single unauthenticated request can trigger the attack before any app code runs.

I'm not going into exploitation details beyond what the advisories say. Plenty of servers are still unpatched tonight.

Who's at risk

Every PHP installation that serves web requests:

  • PHP-FPM
  • Apache with mod_php (highest risk, per the PHP team)
  • php-cgi
  • FrankenPHP
  • LiteSpeed

If you only run PHP on the command line for scripts and never expose it to web traffic, you're in a much better position, but patch anyway.

How we got here

The short version: the embargo broke.

  • 20 Oct: A Hacker News post says two critical PHP bugs are about to drop. The PHP security team posts an advance notice and moves the release a day earlier. watchTowr confirms the leak is real and reproduces one bug. CERT-EU publishes the CVE IDs.
  • 21 Oct, morning UTC: Cloudflare reports early attack attempts and ships WAF rules for the known vectors to all customers, including free.
  • 21 Oct, 13:34 UTC: The two GitHub security advisories go public.
  • 21 Oct, ~14:00 UTC (7:30 PM IST): PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The UK's NCSC is now telling organisations to patch immediately, and to take offline anything they can't patch right away.

What to do

  1. Update. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distros and LTS vendors got the patches ahead of time, so check your vendor's packages first.
  2. On Remi's repo? It won't have updates today. Switch to your distro's packages or build from source.
  3. On PHP 8.1 or older? Those branches are end-of-life. The PHP team published minimal source backports for 7.4, 8.0 and 8.1 because of how severe this is, but the real answer is upgrading. Also note that 8.2 reaches end-of-life on 31 December 2026.
  4. Don't rely on config changes. Early php.ini workarounds were walked back. Some settings narrow the attack surface, but none close it. WAF rules cover known vectors only.
  5. Inventory everything. Containers, CI images, staging boxes, shared hosting, that one forgotten admin panel. Restart PHP-FPM workers after updating so no old process keeps serving requests.
  6. Hunt for compromise. Attacks started before the patch. Look for web shells, unexpected PHP files, new admin users and odd outbound connections.

The bigger lesson

Two things stand out to me.

First, a broken embargo flips the race. Coordinated disclosure exists so defenders get the fix at the same moment attackers learn the bug exists. This time attackers had a roughly 24-hour head start.

Second, this is a supply chain problem. Most teams don't think of PHP as a dependency. It's "just there", baked into a base image or bundled by a host. But it's a dependency like any other, and the teams that patched fastest today were the ones who already knew where it ran. As forensics expert Hal Pomeranz put it, there will be a long tail of forgotten, unmaintained installs that never get fixed.

If you don't have an SBOM or some inventory of your runtimes, this is the week to start.

Sources: PHP GHSA-w8hw-w9fx-j79w · PHP GHSA-6wmf-4rv5-p3rp · Help Net Security · UK NCSC · watchTowr FAQ · Huntress · Aikido · CERT-EU advisory 2026-018

More writing Read on Medium