PHP

PHP2Shell: Two Unauthenticated RCEs in PHP Core, Reachable Before Your Code Runs

The PHP project shipped fixes for two CVSS 9.8 core vulnerabilities that let an unauthenticated request execute code before any application code runs. If you run self-hosted PHP, update now. The partial mitigations are stopgaps.

Glenn Fryklund

Glenn Fryklund

— 3 min read
Share
PHP2Shell: Two Unauthenticated RCEs in PHP Core, Reachable Before Your Code Runs
A rack server glowing red, the compromised PHP runtime at the core of a self-hosted web app. Rendered with AI.

The PHP project published a security advisory on 2026-10-21 for two critical vulnerabilities in the core interpreter. Both allow unauthenticated remote code execution (RCE), both are rated CVSS 9.8 by NVD, and both sit below the application layer: the attack can trigger before any of your PHP code runs. The fixed releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35, with source backports for 7.4, 8.0, and 8.1.

The two bugs differ in mechanism but are identical in consequence.

CVE-2026-109618 is an out-of-memory corruption. PHP uses longjmp() to abort the current request context when an allocation fails. Some contexts do not account for that jump and leave request memory in an uninitialized state. A later request cleanup then reads or branches on that memory. Multiple OOM strategies can trigger the condition consistently, which is what turns a memory bug into reliable RCE.

CVE-2026-109619 is a stale-global-state bug. PHP global state temporarily points into request memory. In some scenarios that state is not reset, or is repopulated after being reset, so it can refer to request memory even after that memory is freed. A later request handled by the same worker may read or branch on that stale state before normal initialization resets it.

The advisory flags mod_php as the highest-risk deployment, with a demonstrated exploit where a single unauthenticated request triggers the attack before application code runs. The exposure is not limited to mod_php. The advisory names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. If you serve web requests with PHP, you are in scope.

Why this matters for self-hosted operators: PHP is the runtime substrate for a large share of self-hosted SaaS. That includes the products we cover (Zammad, Metabase, TrueConf, Ghost) and a long tail of self-hosted web applications. A core-level unauthenticated RCE, reachable before your application code runs, is a high-urgency exposure for anyone running self-hosted PHP. The "affects ~70% of the web" figure that has been circulating could not be verified against a primary source, so treat it as unconfirmed. The point stands without it.

The advisory offers partial mitigations, and they are stopgaps. Set memory_limit=-1 (preferably via php_admin_value so applications cannot override it) to remove the controllable memory-limit failure behind CVE-2026-109618, and set a low post_max_size. These reduce specific attack paths. They do not fix the stale-global-state bug, and they do not eliminate the OOM path in general. Only an update is a complete fix.

There is a second angle worth recording. Google Cloud's response blog states that its AI agent "Argon made an invaluable contribution to finding the vulnerability, exploit development, attack detection, and validation of the patch." That is a named, vendor-attested example of AI-assisted vulnerability discovery reaching production-grade results: an AI agent found two 9.8 unauthenticated RCEs in one of the most widely deployed server-side languages, developed the exploit, and validated the vendor's patch.

On exploitation status: as of 2026-10-22 there is no CISA KEV entry for either CVE, and no Tier-1 source confirms in-the-wild exploitation. The advisory describes a demonstrated exploit, but "actively exploited in the wild" is unconfirmed. Update on severity and exposure, not on a confirmed active-attack report.

What to do: update PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (or apply the 7.4 / 8.0 / 8.1 source backports). If you cannot update immediately, apply the memory_limit=-1 and low post_max_size stopgaps as a temporary reduction, not a fix.

Sources

This article was drafted with AI/LLM assistance and reviewed by a human before publication. All factual claims were checked against the public sources cited above. The feature image was generated with AI. See How we use AI for the full workflow.

Topics:

Read more