Defending Against PHP2Shell

This blog post analyzes the PHP2Shell exploit and explores defensive approaches for threat detection, threat hunting, and incident response.

Security researchers from OpenAI, Calif, and Wiz identified a pair of critical vulnerabilities in the PHP interpreter that allow unauthenticated remote code execution (RCE). These vulnerabilities, codenamed “PHP2Shell,” relate to memory corruption caused by flaws in state management and control flow handling. The PHP Foundation has disclosed CVE-2026-109618 (RCE via out-of-memory) and CVE-2026-109619 (RCE via fatal errors) and issued the corresponding patches. These CVEs have been assigned a CVSS score of 9.2, indicating critical severity.

PHP powers over 70% of internet-facing websites. Popular applications such as WordPress, Joomla, and Drupal rely on PHP. These vulnerabilities exist in the underlying interpreter and are not specific to any single application. PHP versions from 5.4 through 8.5.11 are vulnerable.

The exploit enables attackers to achieve remote code execution (RCE) or access sensitive process memory without executing code. An attacker can dump the web server process memory, obtain cached secrets and tokens, and read sensitive files on the operating system. Beyond these initial steps, post-exploitation activities depend on the attacker’s skill level and goals. For example, if a PHP web application connects to a database server, an attacker who gains RCE on the web app can find cached database connections. This allows for lateral movement, pivoting from the web tier to the application or data tier to exfiltrate stored data.

The original bug in PHP dates back to 2004 when security researcher Stefan Esser published information about a remote memory-limit vulnerability. Finding viable exploits required chaining multiple flaws involving memory reuse across requests in PHP. Security researchers used AI to perform highly targeted analysis on the source code of the C libraries comprising the Zend PHP interpreter. The AI models evaluated the PHP interpreter source code to track the state of memory pointers in infrequently executed exception branches, uncovering subtle memory corruption issues. In addition, the researchers leveraged AI to generate exploit payloads for each step of the exploit sequence.

The PHP Foundation has released patches for these CVEs. Security teams must prioritize patch application as a primary preventive control to reduce the exploitable attack surface.

These vulnerabilities impact PHP versions starting with 5.4, which dates back to 2012. Patches are available for supported versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Applications running PHP versions from 5.4 through 8.1 have no available patches. Legacy applications and IoT cameras are common in most organizations and represent an attack surface that cannot be secured through patching alone.

The vulnerabilities reside in the core Zend engine of the PHP interpreter. The exploit does not depend on the security of the application layer. When an attacker gains RCE on the web server and executes post-exploitation commands in the shell, application logs will not capture this activity. Forensic analysis becomes difficult when the PHP application runs on an embedded device, such as an IoT camera, due to ephemeral storage and limited telemetry. The complex nature of these vulnerabilities means relying solely on log analytics for detection is insufficient.

The exploit sequence involves two stages: pre-RCE and post-RCE. During the pre-RCE stage, decoys serve as a threat detection mechanism to provide visibility into exploit attempts. Organizations can tailor these decoys across multiple PHP versions to mirror legacy software and internal production stacks. They can be deployed on internet-facing assets or deep within the enterprise perimeter. For threat detection, these decoys capture evidence of the exploit and gather telemetry on the payload.

For the post-RCE stage, decoys serve as a source of threat intelligence. High-interaction decoys allow security teams to engage with the attacker and observe post-exploitation steps within a controlled, instrumented environment. These decoys capture attacker tactics, techniques, and procedures (TTPs), including executed post-exploitation commands, Stage 2 malware artifacts, and attempted command-and-control (C2) communication.

Security operations workflows integrate the telemetry captured by the decoys. Response actions include blocking source IP addresses at the perimeter firewall and isolating compromised source endpoints within the enterprise network.

The captured threat intelligence triggers further investigation and response workflows. Typical response actions include adding Stage 2 malware hashes to an EDR block list, blocking C2 communication, and adding compromised credentials to a credential block list.

Security teams can use this threat intelligence to formulate threat hunting hypotheses, such as searching for similar indicators of attack (IoA) patterns across production servers and workstations.

Figure 1: Internet-facing decoys and generated threat intelligence to counter PHP2Shell exploit attempts

Figure 2: Internal decoys for PHP2Shell threat detection and automated response