PHP2Shell: Decade-Old PHP RCE Chain Explained

What is PHP2Shell?

PHP2Shell is the name Wiz Research gave to a chain of memory-safety flaws in the PHP core engine. Each bug on its own is a classic use-after-free; stitched together across a worker's request lifecycle, they produce memory disclosure and arbitrary code execution without authentication. The flaws live in PHP itself, which means the application running on top — WordPress, Drupal, Joomla, Laravel, Symfony, or any first-party PHP code — is incidental. Clean, modern application code offers no defence.

The root cause: fatal errors that don't clean up

PHP processes HTTP requests on long-lived worker processes under FPM or mod_php. Each request has a short-lived "request heap" that is destroyed and recreated between requests. When a fatal allocation failure (out-of-memory) interrupts a request mid-flight, PHP tears down the request heap — but a handful of global state pointers are left dangling at process scope:

• BG(unserialize) — state for the upload-progress unserializer
• EG(last_fatal_error_backtrace) — the backtrace captured when the fatal fired
• CG(map_ptr_last) — OPcache's shared-memory frontier marker

The next request handled by the same worker reads from or writes through these pointers. The memory they reference has already been freed and may now hold attacker-controlled bytes, which turns ordinary PHP functionality into a UAF primitive. This is the single mechanism behind both CVEs; the two CVE IDs reflect two distinct exploitation surfaces.

The four exploitation primitives

What's actually affected

Wiz demonstrated RCE against the latest container images of WordPress, Drupal and Joomla with no application-layer modification — just the vanilla PHP that ships with the image. Because the bug is in PHP, the real affected list is "any PHP application running under FPM or mod_php on a vulnerable PHP version." That includes:

• WordPress, Drupal, Joomla, MediaWiki, Nextcloud, OwnCloud
• Magento, PrestaShop, OpenCart, WooCommerce (via WordPress)
• Laravel, Symfony, CodeIgniter, CakePHP applications in production
• phpMyAdmin, Roundcube, SquirrelMail, Zabbix, Icinga web UI
• Hosted PHP on Hostinger, Bluehost, SiteGround, Kinsta, WP Engine, GoDaddy

PHP versions affected: every branch released in the last decade, back to PHP 5.4. CVSS up to 9.2.

Timeline

Why did this survive a decade in the open-source PHP core?

The flaw sits at the intersection of three code paths that very few reviewers hold in their head at once: PHP's fatal-error handler, the global request-cleanup path, and specific extensions (upload-progress, OPcache) that interact with request-scope state. Static analysers do not model cross-request state. Fuzzers struggle because triggering the bug requires chaining two HTTP requests with a controlled out-of-memory failure between them.

Wiz credits frontier AI models for closing the gap. The quote from the writeup: "Frontier models substantially reduced that barrier, turning a longstanding flaw into an exploit." This is a worth-watching pattern — not that AI invents novel bug classes, but that it compresses the cost of adapting known-but-impractical primitives to specific heap layouts and PHP versions from months of specialist work into hours.

What to do in the next 48 hours

1. Patch PHP. Apply the 21 Oct 2026 security releases from php.net or your distribution's package feed (Debian, Ubuntu, Red Hat, Amazon Linux, Alpine). Managed hosts (WP Engine, Kinsta, Hostinger, SiteGround) typically patch within hours — confirm your plan's SLA.
2. Restart FPM pools. The dangling-state class means a worker process compromised before the patch stays compromised until it restarts. systemctl restart php8.2-fpm and watch for request errors during the drain.
3. Audit OPcache contents. Clear OPcache (opcache_reset() via a CLI script or restart the FPM pool) in case cross-worker type confusion left poisoned entries.
4. Hunt for exploitation. Look back 48 hours for: unusually large PHPSESSID cookies in access logs, bursts of HTTP 500s on multipart upload endpoints, repeated out-of-memory errors in php-fpm logs, and new outbound connections from webserver processes to unfamiliar IPs.
5. Rotate secrets on any host where exploitation looks plausible — database passwords, API keys loaded into PHP via getenv(), OAuth client secrets.

How TigerGate helps

• Server Vulnerability Monitoring flags vulnerable PHP builds on every Linux host and cloud VM, prioritized by CISA KEV and EPSS once the CVEs land on those feeds — and by eBPF runtime-reachability so you see which hosts are actually running PHP in production vs. just having it installed.
• Container Security scans WordPress, Drupal, Joomla, Laravel and custom PHP images for the vulnerable PHP binary before they reach your registry and admission controller.
• eBPF runtime detection watches for the exploitation side-effects: anomalous child processes spawned by php-fpm or Apache, unexpected outbound connections, writes to /tmp or /dev/shm followed by execution.
• Compliance evidence maps the PHP patch to SOC 2 CC7.1 vulnerability lifecycle, PCI DSS 6.3.3 (critical patch within 30 days) and CERT-In VAPT reporting — the audit trail your next auditor will ask for.

Sources

• Wiz Research: PHP2Shell — PHP RCE, 21 October 2026
• PHP 8.x ChangeLog, security releases 21 October 2026
• CVE-2026-109618 and CVE-2026-109619 at NVD (pending)