PHP2Shell: Two critical PHP vulnerabilities require immediate patching

Key takeaways

• PHP2Shell covers two related memory-safety vulnerabilities in core PHP: out-of-memory (OOM) corruption and stale global state across requests.
• Successful exploitation can enable unauthenticated code execution or exposure of sensitive process memory, including credentials and authentication tokens.
• All PHP installations older than 8.2.35, 8.3.36, 8.4.27, or 8.5.12 that are serving web requests are affected, including older branches right back to 5.x. Apache with mod_php carries particularly high risk because an attack can succeed before application code executes.
• Fixed releases as of this writing are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 (or newer). Older versions with no published fixes require upgrading or obtaining a verified vendor backport.
• Temporary mitigations can reduce exposure, but patching is the only complete solution.
• On October 21, the Invicti Application Security Platform added runtime SCA detection of affected PHP versions, with dedicated Critical-severity findings covering both PHP2Shell CVEs.

PHP2Shell: A brief history and disclosure timeline

The research behind PHP2Shell builds on more than two decades of PHP security work. In 2004, security researcher Stefan Esser investigated a dangerous PHP memory-limit vulnerability. A related OOM condition was also reported in 2020. During a 2024 security audit, PHP developers investigated similar behavior but could not establish a practical exploitation path.

In 2026, Calif began an AI-assisted PHP audit through OpenAI’s Patch the Planet initiative. Researchers identified a working RCE path in early August and reported it on August 11. OpenAI independently reported the same underlying problem that day, while Wiz contributed further findings later in August.

On October 20, information about the vulnerabilities circulated ahead of the planned disclosure. According to the PHP Foundation, the initial leak contained CVE identifiers and an incorrect severity score rather than full technical details. A prematurely published demonstration video subsequently exposed limited exploitation information.

PHP brought its planned October 22 security release forward by one day, publishing fixes and an official advisory on October 21.

How do the PHP2Shell vulnerabilities work?

Both vulnerabilities originate in how PHP handles memory and internal state when request processing is interrupted. Normally, PHP allocates memory, initializes internal structures, processes a request, and performs cleanup. Certain fatal errors can interrupt this sequence at unsafe points, leaving partially initialized structures or references to already-freed memory.

The two CVEs describe different consequences of this underlying problem.

CVE-2026-109618: Remote code execution through out-of-memory corruption

PHP traditionally uses a mechanism called longjmp() to interrupt processing when memory allocation exceeds the configured memory_limit. The problem arises when this interruption happens before PHP has fully initialized an internal data structure. During later cleanup, PHP may treat incomplete data as valid, potentially causing memory corruption.

As detailed in Calif’s technical research, attackers can deliberately create this condition using specially constructed multipart form submissions. These crafted requests exploit differences between HTTP request size and the memory PHP consumes internally. Nested form fields and file metadata can expand into large numbers of memory allocations, while requests without a usable declared content length can bypass certain preliminary size checks.

Consequently, a request that appears to respect limits such as post_max_size can still exhaust PHP’s memory allowance. Apache deployments using mod_php are especially exposed because the vulnerable parsing and cleanup steps can occur before application code executes. In this case, no authentication or application-level vulnerability is necessary for the demonstrated attack path.

CVE-2026-109619: Remote code execution through stale global state

The second vulnerability involves references to memory that PHP has already released. PHP workers can process multiple requests, and some internal global variables temporarily reference memory belonging to an individual request. Those references should be cleared before the request’s memory is freed.

If a fatal error interrupts cleanup, a reference may survive. A subsequent request handled by the same worker can then access memory that is no longer valid, creating a use-after-free vulnerability.

Researchers identified multiple variants of this behavior involving session processing, error handling, and other internal operations. Depending on the exploitation path, an attacker may achieve code execution or disclose sensitive process memory without first executing arbitrary code. That memory may include passwords, session tokens, or API keys.

The precise exploitation requirements differ between PHP versions and server interfaces. PHP-FPM is also affected, although some demonstrated attack paths require application-level processing rather than succeeding entirely during request initialization.

Is PHP2Shell being exploited in the wild?

Yes. Multiple security vendors have reported active attempts to exploit PHP2Shell. Cloudflare observed attack traffic targeting its customers, including attackers modifying payloads to evade protective rules. More significantly, Amazon Threat Intelligence identified an exploitation attempt dating back to October 17, four days before the public security release. AWS subsequently detected additional attempts from multiple sources and reports widespread exploitation activity following disclosure.

While these observations confirm active attack attempts, they do not necessarily establish successful compromises of production systems. Huntress had not observed exploitation across its partner base as of late October 21.

However, with working exploits publicly available and exploitation attempts already underway, unpatched internet-facing PHP installations should be treated as urgent remediation priorities.

How to remediate PHP2Shell and reduce exposure

The official PHP security advisory makes the priority clear: Updating PHP is the only complete remediation. Configuration changes and network protections may provide temporary risk reduction for selected exploit paths.

1. Identify vulnerable PHP installations

All PHP versions earlier than 8.2.35, 8.3.36, 8.4.27, or 8.5.12 (depending on the branch) are affected.

Inventory your PHP runtimes across websites, APIs, containers, hosting environments, and third-party applications. Check the PHP versions actually serving web requests, including PHP-FPM pools, Apache modules, and embedded installations. Command-line PHP versions may differ from the runtime used by the web server. Prioritize externally accessible systems and services handling sensitive data, while ensuring that less-visible installations are included in remediation plans.

2. Install patched PHP versions and restart workers

Upgrade to the appropriate fixed release for each branch (versions current as of Oct 22, 2026):

• PHP branch 8.2 → 8.2.35
• PHP branch 8.3 → 8.3.36
• PHP branch 8.4 → 8.4.27
• PHP branch 8.5 → 8.5.12

Linux distribution and long-term support vendors may provide backported fixes through their package repositories.

Note that PHP 8.1 and earlier no longer receive regular security updates from the PHP project. For organizations unable to migrate immediately, the PHP security team has provided minimal source backports for versions 7.4, 8.0, and 8.1.

After updating, restart Apache, PHP-FPM, and other persistent PHP workers, then verify the versions running in production. For containerized or managed deployments, rebuild and redeploy affected images or services as necessary, and verify that the updated PHP runtime is actually being used.

3. Isolate systems that cannot be patched immediately

If immediate patching is not possible, restrict public access to vulnerable applications. Where practical, serve a static maintenance page without invoking PHP. Application-level maintenance modes may be ineffective because the vulnerable request processing can occur before application code runs.

Keep web application firewall (WAF) protections enabled, but do not rely on them as a permanent defense. Exploitation may involve complex request sequences and internal state that simple request signatures cannot fully assess.

4. Apply temporary PHP configuration mitigations

For systems that can’t be updated, the PHP project provides several measures that can interrupt some known exploitation paths:

• Set memory_limit=-1 to remove the predictable PHP memory-limit failure used by confirmed attacks.
• Disable session upload progress using session.upload_progress.enabled=0.
• On PHP 8.5, set fatal_error_backtraces=0 to block a specific demonstrated path.
• Restrict request sizes, multipart submissions, and unnecessary upload functionality.

Deploy these measures carefully because they can impact application behavior or reliability.

Disabling PHP’s memory limit transfers memory-exhaustion handling to the operating system, which can affect system availability. Setting container or cgroup memory boundaries can help minimize the consequences. Note that PHP specifically warns against using RLIMIT_AS or RLIMIT_DATA as substitutes because they can trigger vulnerable allocation failures.

Apply settings administratively, ensure applications cannot override them, and restart affected workers. Again, none of these changes eliminates every attack variant.

5. Harden request handling and monitor for compromise

Review post_max_size, upload_max_filesize, input nesting limits, and web server restrictions on multipart requests. Enforce limits even where requests lack a usable Content-Length.

Temporarily blocking multipart submissions may be useful to reduce exposure, but it can also disrupt legitimate uploads and business workflows.

Monitor suspicious multipart traffic, abnormal PHP failures, worker crashes, and unexpected process activity. Investigate possible data exposure as well as code execution, since memory disclosure may occur without leaving a conventional webshell.

After patching, verify application functionality, restore appropriate memory safeguards, and rescan affected assets.

How Invicti helps identify vulnerable PHP installations

Invicti responded to PHP2Shell on October 21 by adding detection of vulnerable PHP versions through its runtime software composition analysis (SCA) capability, with dedicated Critical-severity findings for both CVE-2026-109618 and CVE-2026-109619.

Expanding Invicti’s dynamic application security testing (DAST) capabilities, runtime SCA identifies known vulnerable components and technologies in running applications. For security issues like PHP2Shell, this helps security teams detect potentially affected PHP installations and prioritize the necessary updates.

By combining runtime SCA with DAST and application security posture management (ASPM), the Invicti platform helps organizations connect component vulnerabilities with their broader application security findings and remediation workflows. This is particularly valuable for vulnerabilities such as PHP2Shell, where the weakness exists in the underlying runtime rather than specific application code.

Customers should investigate any PHP2Shell findings by verifying the installed versions and applicable vendor patches, updating affected runtimes, restarting PHP workers and other processes using the vulnerable runtime, and confirming that the patched versions are active.

PHP2Shell shows the growing impact of AI-assisted security research

PHP2Shell demonstrates how AI-assisted vulnerability research can uncover critical failure patterns in mature, extensively studied software. Researchers used AI to revisit historical vulnerability classes, identify related weaknesses, and accelerate the complex process of developing and testing exploitation hypotheses.

However, the discovery also illustrates the continuing importance of specialist expertise. Calif’s researchers drew on decades of PHP vulnerability research, selected promising areas to investigate, interpreted model findings, and validated the resulting memory-corruption chains. The PHP security team and other researchers then had to develop, verify, and coordinate safe fixes across a widely deployed software ecosystem.

AI tools can greatly increase the productivity of experienced researchers and developers, but access to a capable AI tools alone does not guarantee meaningful vulnerability discoveries. Deep technical understanding, appropriate tooling, and rigorous validation remain essential.

Final thoughts

There’s an important distinction between the severity of PHP2Shell and the practical difficulty of exploiting it. Both vulnerabilities involve complex memory-safety issues, with exploitation paths that can depend on the PHP version, server configuration, and application behavior. Successful exploitation is not inevitable on every vulnerable installation.

At the same time, working exploits are publicly available, active exploitation attempts have been observed since at least October 17, and some attack paths can succeed through a single unauthenticated request. With PHP running on millions of web servers and multiple ways to trigger the underlying flaws, even technically complex vulnerabilities can translate into significant risk at scale.

This combination of technical complexity, widespread exposure, and potentially severe impact makes immediate remediation essential. Organizations running PHP should identify affected runtimes, install security updates, restart affected workers and services, and verify that the patched versions are active.