Daniel Blazquez
Senior Product Marketing Manager
On October 21, 2026, the PHP security team disclosed two critical remote code execution (RCE) vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Both vulnerabilities have a Common Vulnerability Scoring System (CVSS) v4.0 score of 9.2 and can be exploited without authentication. Because exploitation occurs before PHP executes application code, application-level authentication and input validation cannot prevent an attack. Even a PHP script that simply returns a response can expose the vulnerable code path.
AWS had observed exploitation attempts as early as October 17, before patches were available. Datadog Security Labs analyzed both vulnerabilities and published a technical breakdown of the vulnerabilities and the exploitation process, including a working reproduction. For teams running PHP applications, responding to PHP2Shell requires identifying affected deployments, applying patches, and investigating whether exploitation occurred before remediation.
Datadog Security helps teams perform these tasks by connecting vulnerability findings, infrastructure inventory, process activity, and security logs in one platform.
In this post, we’ll explain how you can use Datadog to:
Identify vulnerable PHP deployments and prioritize remediation
Detect exploitation attempts and investigate suspicious activity
Track remediation and verify that patches have been deployed
Assess your exposure to PHP2Shell
The Datadog Security Research Feed provides information about emerging vulnerabilities, including affected software versions, exploitation methods, and queries for investigating potential exposure. For PHP2Shell, the Research Feed includes an impact assessment that correlates the advisory with security data from your environment.
The impact assessment summarizes matches across vulnerability findings, library vulnerabilities, threats, and Agent events. You can use these results to determine where to investigate further. For example, if the assessment identifies vulnerable resources and related Agent events, you can open those results to review the affected systems and their activity.
The impact assessment provides a starting point for investigating PHP2Shell across your environment. From there, you can use Datadog Cloud Security to examine vulnerable infrastructure and Datadog Workload Protection or Cloud SIEM to investigate signs of exploitation.
Identify vulnerable PHP deployments and prioritize remediation
PHP2Shell affects the PHP interpreter itself, so remediation requires updating the PHP runtime on affected hosts and container images. Updating Composer dependencies will not address these vulnerabilities.
Cloud Security helps identify affected infrastructure, while Code Security provides additional context about PHP applications and their owners. Together, these products can help security and engineering teams determine which deployments need attention and coordinate the required updates.
Find vulnerable hosts and container images with Cloud Security
To investigate PHP2Shell, you can filter Cloud Security vulnerability findings by CVE-2026-109618 and CVE-2026-109619 to identify affected resources.
You can also use the Infrastructure Package Catalog to search for PHP installations across your infrastructure. Because the catalog maintains an inventory of installed packages independently of vulnerability advisories, you can use it to find PHP deployments even before a specific vulnerability has been added to Datadog’s vulnerability database.
Searching by package name is useful when investigating a vulnerability that affects multiple versions or distributions. It can also help identify PHP installations that require further review but do not appear in the initial CVE results.
Once you’ve identified affected resources, the Runtime Prioritization Engine helps you determine which findings to address first. It considers factors such as whether a resource is publicly accessible or runs in production, whether public exploits are available, and whether there’s evidence of suspicious activity.
For PHP2Shell, internet-facing Apache deployments that use mod_php warrant particular attention. The mod_php execution model runs PHP’s request shutdown procedure even when request initialization fails, which is relevant to the exploitation technique described in the PHP2Shell Security Labs analysis.
Identify affected applications and owners with Code Security
Code Security’s Software Composition Analysis (SCA) provides information about libraries loaded by running services, including those already in production. This runtime context can help teams identify differences between the dependencies recorded in source control and those used by deployed applications.
Code Security also helps identify PHP codebases and the teams responsible for them. By filtering the Library Inventory and Repositories views to the PHP (Packagist) ecosystem in SCA, you can find repositories associated with PHP applications.
Because PHP2Shell affects the interpreter, SCA flags the two CVEs in running services (where it can see the PHP runtime) rather than in repository dependency files. However, repository inventories still help you determine which applications rely on vulnerable PHP runtimes and which teams should participate in remediation.
For example, the team responsible for a container base image may need to update PHP, while the application team may need to validate the service after the updated image is deployed. Repository and ownership information helps coordinate that work.
Detect exploitation attempts and investigate suspicious activity
Patching vulnerable PHP applications and infrastructure addresses the underlying vulnerabilities, but it does not establish whether attackers compromised a system before the patch. Because exploitation attempts were observed before public disclosure, teams should also investigate historical activity on affected systems.
Workload Protection and Cloud SIEM provide complementary ways to investigate PHP2Shell. Workload Protection monitors process activity within workloads, while Cloud SIEM analyzes security events and logs from sources such as web servers, PHP, and Linux auditd.
Investigate suspicious process activity with Workload Protection
Workload Protection monitors process execution to identify suspicious activity in running workloads. Its general-purpose RCE detection can identify application processes that are spawning shells, a behavior associated with successful exploitation of PHP2Shell.
Because the detection examines process behavior, it can identify suspicious execution activity without depending on a particular PHP2Shell payload.
When Workload Protection detects suspicious activity, process information helps responders investigate what occurred. For example, the Investigation Graph can show a shell launched by a PHP or web server process, followed by commands that download additional software, such as malware, or inspect the host.
Responders can use process execution details and command-line arguments to investigate subsequent activity, including reconnaissance, credential access, persistence attempts, and lateral movement.
Process-based detection is especially useful when an attacker modifies an exploit payload to evade signatures based on request content. However, responders should still review the available process and security evidence to determine whether an alert represents successful exploitation.
Detect PHP2Shell activity with Cloud SIEM
Cloud SIEM analyzes logs and security events to identify suspicious activity across monitored infrastructure. For PHP2Shell, Datadog released dedicated detection rules within 24 hours of disclosure and added further coverage as the investigation progressed.
Two general-purpose detections can identify suspicious processes associated with RCE:
Shell spawned by web server or PHP process (def-000-9h1): Uses process activity events and parent process information to identify suspicious shell execution, download utilities, and reconnaissance commands.
Shell spawned by web process (def-000-gn1): Uses Linux auditd process execution logs to identify shells launched by web processes.
The auditd-based detection requires process execution events to be collected. Linux auditd does not record these events by default, so teams must configure the appropriate audit rules. Collecting additional process events can also increase log volume and host overhead.
Cloud SIEM also includes three PHP2Shell-specific detections that examine activity associated with the exploitation process, including memory exhaustion, session decoding failures, and PHP worker crashes.
These detections are useful because they can identify indicators of attempted exploitation even when an attacker does not successfully execute a shell. Memory exhaustion during request initialization, for example, is part of the PHP2Shell exploitation sequence.
Teams can use these detections to investigate suspicious activity in PHP error logs, web server logs, and PHP-FPM logs. The available evidence depends on which log sources and process events are collected. Bits Security Analyst can help automate triage, including for related signals that aren’t directly tied to PHP2Shell.
Workload Protection and Cloud SIEM can help responders investigate different stages of an attack. Log-based detections provide evidence of potential exploitation attempts, while process activity can help establish what happened after an attacker executed code.
Track remediation and verify that patches have been deployed
Remediating PHP2Shell requires more than updating a package or merging a change to a Dockerfile. Teams also need to confirm that the updated PHP runtime has reached the affected workloads.
For containerized applications, that means rebuilding affected images and deploying the updated containers. PHP-FPM workers and Apache processes must also be restarted to load the patched runtime. Otherwise, existing processes may continue running the vulnerable PHP version.
Cloud Security helps teams track this work by reporting vulnerability findings against deployed infrastructure. After applying updates, you can review the remaining PHP2Shell findings to identify hosts or container images that still require remediation.
For example, if an updated container image has been deployed to most replicas but an older image remains in one cluster, the corresponding vulnerability finding can help identify that remaining exposure.
Teams can also use the DDSQL Editor to query PHP package versions across hosts and container images, then save the results in Sheets or Notebooks. Tracking affected resources over time provides a record of remediation progress and helps identify deployments that still require attention.
Datadog Work Management and Workflow Automation can help teams coordinate remediation. Responders can create cases from security signals or vulnerability findings and use the associated resource context during investigations.
Workflow Automation can also trigger notifications or ticket creation based on vulnerability findings and security signals. By using ownership information from the Catalog, teams can route remediation work to the appropriate engineers.
These workflows help security teams track outstanding work while application and infrastructure owners deploy updates and verify their services.
Protect your PHP applications against PHP2Shell
Responding to PHP2Shell requires multiple teams working together to address vulnerable PHP runtimes and investigate possible exploitation. Datadog Security helps teams identify affected infrastructure, prioritize remediation, detect suspicious activity, and track outstanding vulnerability findings.
To remediate the vulnerabilities, upgrade to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12 (or later), or install the corresponding patched package from your distribution. Rebuild affected container images, restart PHP workers, and verify that the updated runtime is deployed across your infrastructure. Review security events from before the patch to investigate potential exploitation.
For more information about the vulnerabilities and their exploitation techniques, read the Datadog Security Labs PHP2Shell analysis. You can also learn more about Cloud Security, Workload Protection, Cloud SIEM, and Code Security.
If you don’t have a Datadog account, sign up for a 14-day free trial to start investigating vulnerabilities and security threats in your environment.
