Skip to content
PHP2Shell: Inside the Worst PHP RCE in Years (CVE-2026-109618 & CVE-2026-109619)
DWG-16227
MOD-04 · Cybersecurity

PHP2Shell: Inside the Worst PHP RCE in Years (CVE-2026-109618 & CVE-2026-109619)

An unauthenticated remote code execution chain hit every major PHP SAPI — here's what happened and how to patch it

Siddh Mistry Siddh Mistry November 09, 2026 Updated November 09, 2026 4 min read
Designer
Siddh Mistry
Module
MOD-04 — Cybersecurity
Runtime
4 min read
Documentation Length
789 words / 4736 chars
Revision
REV-I
Version Released
v1.0

PHP2Shell CVE-2026-109618 CVE-2026-109619

The headline

On October 21, 2026, the PHP core team shipped an out-of-band security release for two critical vulnerabilities — CVE-2026-109618 and CVE-2026-109619 — now widely known by their project name, PHP2Shell. Both allow unauthenticated remote code execution, and PHP’s own advisory says every installation serving web requests is at risk: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed are all in scope.

That’s basically the entire PHP hosting ecosystem — WordPress, Laravel, Magento, Drupal, ThinkPHP, and every hand-rolled legacy app sitting on a shared host.

What’s actually broken

This isn’t a simple injection bug — it’s a use-after-free chain buried in PHP’s memory management, and it’s been there since PHP 5.4.

In plain terms:

  1. The setup (mod_php): PHP can leave dangling pointers when an allocation blows past memory_limit, or a fatal error interrupts cleanup. On Apache’s mod_php, the worker process survives the crash and gets reused for the next request — but some old request’s memory (like session data) never got properly destroyed. A later request can end up reading memory that should have been freed.
  2. The PHP-FPM twist: FPM usually kills the whole worker on a startup failure, so that trick shouldn’t work there. But researchers found a second path through PHP’s unserializer (BG(unserialize)). If an out-of-memory error hits after the request has already started — say, during session_start() or unserialize() — FPM’s worker survives, but it’s left holding a stale pointer into freed memory.
  3. The reclaim: Attackers then send a crafted multipart file upload (abusing session.upload_progress) that runs before PHP’s normal request setup. This lets them overwrite that freed memory with their own fake data structures — forging a fake PHP object whose “destructor” is system().
  4. The fire: When the session is cleaned up at the end of the request, PHP calls that fake destructor — and the attacker’s shell command runs. The worker crashes right after, but FPM just respawns it, and the attacker already has their output.

No login, no plugin, no uploaded .php shell required — just HTTP requests at a PHP app that uses sessions.

PHP2Shell attack chain: ARM, RECLAIM, FORGE, FIRE

Who’s affected

Branch Vulnerable Patched
PHP 8.4 8.4.0 – 8.4.26 8.4.27
PHP 8.3 8.3.0 – 8.3.35 8.3.36
PHP 8.2 8.2.0 – 8.2.34 8.2.35
PHP 8.1 / 8.0 every release ⚠️ no official patch (EOL)
PHP 7.x every release ⚠️ no official patch (EOL)
PHP 5.x every release ⚠️ no official patch (EOL) — limited to a related session-file attack

If you’re still running PHP 7.x or 8.0/8.1 in production, this is the wake-up call to migrate — there is no fix coming for EOL branches.

What to do right now

  1. Patch immediately. Upgrade to PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or later. This is the only complete fix.
  2. If you can’t patch yet (temporary, partial mitigation only):
    • On PHP-FPM: set session.upload_progress.enabled = 0 and memory_limit = -1.
    • On mod_php: set memory_limit = -1.
    • Understand that removing memory_limit trades one risk (RCE) for another (memory exhaustion / DoS) — patch as soon as you can and don’t treat this as a fix.
  3. If you’re on a managed platform (AWS, Azure App Service, etc.), check whether the platform already auto-patched — most major cloud PHP runtimes rolled out fixes within 24 hours of disclosure.
  4. Watch your logs for unusually large multipart/session traffic hitting PHP endpoints — that’s the fingerprint of exploitation attempts in the wild.

It’s not just PHP2Shell — a rough month for PHP security

A few other PHP-ecosystem CVEs have landed recently and are worth knowing about if you’re running a PHP stack:

  • CVE-2025-63888 / CVE-2025-63889 — Two vulnerabilities in ThinkPHP 5.0.24’s template engine: a remote code execution bug via the template file driver, and an arbitrary file-read bug via crafted template paths. If you’re still on ThinkPHP 5.0.x, it’s end-of-life and these won’t be the last.
  • CVE-2025-63828 — An HTTP header injection vulnerability in the Backdrop CMS (PHP-based) password reset flow, allowing session hijacking via a manipulated Host header. No fixed version exists yet.

The pattern across all of these is the same: legacy PHP code paths, memory-handling edge cases, and unvalidated input in places developers assumed were “internal.” If there’s one takeaway, it’s this — patch cadence matters more for PHP than almost any other stack, because so much of the internet still runs on it.

Bottom line

PHP2Shell is a textbook example of how a decade-old memory bug can resurface as a pre-auth RCE once someone puts the right pieces together. If you run anything on PHP — and odds are you do, even indirectly — check your version today:

1
php -v

If it’s not 8.2.35+, 8.3.36+, 8.4.27+, or 8.5.12+, that’s your next task.

§ 05 SECTION

Related Documents

Other specifications filed under the same module.

§ 06 SECTION

Field Notes & Comments

Session-local discussion — comments here are not persisted to a server in this build.

Loading discussion module…