PHP2Shell: When the Runtime Became the Attack Surface

The new PHP vulnerabilities show why application security must account for what happens before application code even starts.

PHP powers nearly 70% of websites whose server-side programming language can be identified, according to W3Techs. That reach makes PHP2Shell a security problem that extends across applications, organizations, and hosting providers: the vulnerabilities sit inside the runtime those websites depend on to execute their code.

On October 21, PHP released fixes for the two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which can allow unauthenticated attackers to execute code remotely. Exposure depends on the deployed PHP version and configuration. PHP’s maintainers identified Apache’s mod_php as the highest-risk configuration, with a demonstrated attack that triggers before any application code runs.

That means an application can have carefully written code, updated dependencies, and strong authentication while remaining exposed through the interpreter underneath it. When exploitation begins during request processing inside PHP itself, the application’s security checks may never get a chance to intervene. Understanding that execution path is central to understanding both the attack and the protection it requires.

The attack path runs through PHP’s error handling

CVE-2026-109618 involves how PHP exits an operation when memory allocation fails.

PHP uses longjmp() to escape the current execution context during an out-of-memory error. That abrupt exit can interrupt an operation while request data is only partially initialized. Request shutdown may then process the incomplete data as though initialization succeeded.

With mod_php, shutdown runs even after request startup fails. Automatic request parsing can therefore reach the vulnerable sequence before the target PHP script executes.

The dangerous transition happens inside trusted interpreter code. The application does not need to implement an unsafe upload handler for this particular path to become reachable.

A partially initialized structure becomes trusted input

In one identified path, PHP increments a hash table’s element counters before allocating and initializing a new entry’s key. If that allocation triggers a fatal error, initialization stops, but the updated count remains.

During cleanup, PHP treats the entry as live. It can process leftover allocation contents as a valid structure.

Calif technical research also documented how compact multipart input can expand into much larger internal allocations. A request that fits within a configured body-size limit can still create substantial memory pressure inside the interpreter.

This is why request size and runtime memory consumption cannot be treated as equivalent. The parser transforms incoming data into structures whose size and lifetime depend on implementation details.

Those details become security-critical when execution stops halfway through an update.

The next request can inherit the previous request’s failure

CVE-2026-109619 involves references that survive after their underlying request memory has been freed.

PHP workers retain global state between requests. Some of that state points to memory owned by an individual request and must be cleared before that memory disappears.

If cleanup is interrupted or state is repopulated after its reset, a later request can encounter a dangling reference before normal initialization replaces it. PHP’s advisory describes this as a producer and consumer relationship: one operation leaves stale state, and a subsequent operation acts on it.

Session upload-progress handling provides one confirmed path because it can run before ordinary session initialization. The application does not need to call session_start().

The deployment model matters. PHP-FPM terminates a worker after a startup failure, preventing that exact sequence from persisting. The validated FPM session path instead depends on a suitable application operation after successful startup.

A failed request does not automatically imply a clean process. But different PHP deployments must be assessed against the paths they actually expose.

The warning signs existed before the full impact was established

The PHP Foundation says its team found early signs of the OOM problem in 2024 while addressing findings from an external audit. A potential exploit was considered, but no concrete path had been established.

A fix also involved difficult trade-offs around compatibility, performance, and extensions. Work stalled and restarted.

Reports in August 2026 established the practical remote code execution risk and made remediation the team’s highest priority. The Foundation explicitly acknowledged shortcomings in its decision process and resourcing.

That history matters because uncertainty about exploitability can persist while vulnerable code remains deployed.

Calif describes using an AI assistant to examine allocation behavior, identify interruption points, and generalize one finding into a broader search for similar state-management failures.

The defensive implication is clear: difficulty demonstrating an exploit today provides limited assurance about what another researcher or attacker can establish tomorrow.

Attack traffic is already adapting

Cloudflare reported observing attack traffic targeting its customers and attackers modifying payloads in attempts to bypass protections. That establishes attempted exploitation, not successful compromise of every targeted system.

For security teams, the investigation must connect incoming traffic to what happened inside the affected service.

Did a suspicious request reach a vulnerable worker? Did execution continue after a fatal error? Did the process perform unexpected file operations, launch a command, or expose sensitive data?

A request log alone cannot answer all of those questions.

A dependency inventory is only part of the answer

SCA and vulnerability management remain essential for identifying affected software and coordinating updates. But an assessment centered on Composer packages is incomplete when the vulnerable component is the PHP interpreter.

The inventory needs to include the runtime, its deployment configuration, and the instances actually serving traffic.

The response also needs execution evidence. A vulnerability record tells defenders that software may be exposed. It does not show whether a particular request changed execution or what happened afterward.

That distinction becomes especially important when the attacker’s entry point sits below the application’s own business logic.

Connecting runtime visibility to prevention

Raven’s approach centers on observing execution inside running applications. Its Application Detection and Response capabilities provide library, function, and call-path context to support investigation of abnormal execution and runtime changes. PHP is among its supported languages.

That context matters when an attacker operates through trusted software. The process name may remain familiar. The application may still be serving requests. The security question is what code executed and how that behavior departed from its intended operation.

Raven’s Runtime Prevention is designed to identify and block abnormal execution without depending exclusively on a known CVE or exploit signature. It adds an execution-focused control alongside vulnerability identification and patch deployment.

PHP2Shell sets a demanding standard for that protection. Coverage must account for native runtime behavior and paths that execute before application initialization. A control that only blocks shell creation cannot address every memory-disclosure scenario.

Protection against these specific paths requires validation against the affected deployment and configuration.

Patch the runtime and examine the execution

PHP released fixes in 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Organizations using distribution packages should verify their vendor’s fixed package or backport. PHP’s maintainers state that configuration changes can reduce exposure to specific paths, but updating is the complete solution.

The OOM fix also illustrates the depth of the problem. It replaces abrupt OOM exits with a soft failure at a safe execution point and a hard process exit at a higher memory threshold. The purpose is to prevent shutdown from operating on invalid intermediate state.

The immediate action is to deploy the fix.

The enduring lesson is that the software trusted to execute an application is itself part of the attack surface. Security coverage must extend through the code that parses requests, allocates memory, and handles failures.

Raven takeaway: Protecting an application means understanding what it does at runtime, even before the application gets control.

PHP2Shell shows how trusted code can become an attacker’s entry point. Explore Raven in your environment and see how runtime visibility and prevention help detect and prevent abnormal execution.

‍

Sources:

• PHP security announcement and remediation guidance
• CVE-2026-109618: RCE via out-of-memory corruption
• CVE-2026-109619: RCE via stale global state
• Calif Research: A tale of two PHP remote vulnerabilities
• PHP Foundation: Security release, discovery, and disclosure timeline
• Cloudflare: PHP2Shell protections and observed attack traffic
• W3Techs: PHP usage statistics