How the PHP2Shell Vulnerabilities May Affect CPS Environments

The PHP project published security advisories and updates on Oct. 21 for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities collectively known as PHP2Shell. The flaws affect PHP’s memory management and can enable unauthenticated remote code execution or disclosure of sensitive information in vulnerable deployments. For organizations operating cyber-physical systems (CPS), including operational technology (OT), internet of things (IoT), and the internet of medical things (IoMT), potential PHP2Shell exposures include web interfaces and supporting applications used to manage and monitor operational environments.

Claroty products are not affected by PHP2Shell. We are actively monitoring developments, adding relevant detections, and expanding vulnerability coverage for affected products as new technical information and vendor advisories become available. These efforts help customers identify potentially affected assets, investigate suspicious activity, and prioritize remediation across their CPS environments.

This blog will explain:

• What are the PHP2Shell vulnerabilities

• What PHP2Shell means for CPS including operational technology (OT), internet of things (IoT), medical devices (IoMT) and building automation/management systems (BAS/BMS)

• How to find affected assets in CPS environments with Claroty xDome and Claroty CTD

• Hunting and detecting PHP2Shell exploitation

What are the PHP2Shell Vulnerabilities?

CVE-2026-109618 and CVE-2026-109619 are critical vulnerabilities in PHP’s memory management, both assessed CVSS v4.0 criticality scores of 9.2. 

• CVE-2026-109618 occurs when an out-of-memory error interrupts processing before internal request data is fully initialized, leaving cleanup routines to access invalid memory. 

• CVE-2026-109619 involves global state retaining pointers to freed request memory, creating a use-after-free condition when a subsequent request handled by the same worker accesses that state.

Depending on the deployment, an unauthenticated attacker can exploit these flaws through crafted HTTP requests to execute code with the PHP worker’s privileges, potentially accessing sensitive data or modifying resources available to that account. A separate application coding flaw is not always required: exploitation against Apache’s mod_php has been demonstrated before application code executes. 

PHP’s core team and the Cybersecurity & Infrastructure Security Agency (CISA) urges developers to update to the latest secure versions of PHP; fixes were also backported to versions 8.2-8.5. Installations where legacy, unsupported versions of PHP are deployed should be taken offline, according to the National Security Agency (NSA), or isolated by firewall rules or behind a VPN. 

PHP, meanwhile, has published its own advisory with details on the vulnerabilities, how to update to secure versions of the language, and information for organizations unable to update immediately.

Organizations should identify affected PHP deployments and apply the appropriate PHP or vendor updates listed below:

Affected PHP Versions and Fixes

What PHP2Shell Means for CPS Environments

PHP is commonly associated with servers hosting websites, but it can also power the web interfaces and APIs that support CPS deployments. These services may run on conventional servers, virtual machines, appliances, or embedded Linux devices. Where they rely on an affected PHP runtime, the potential consequences extend to the operational visibility, administrative access, and workflows they support.

Depending on the product and deployment, this can also include historian reporting and monitoring applications in OT environments, building-management and security-camera interfaces in IoT environments, medical imaging and PACS applications in healthcare, and network-management platforms or remote-maintenance portals. 

Some of the impacts are severe. For example, an attacker in control of a web interface used to configure assets such as PLCs or IoT devices such as smart meters and electric vehicle chargers, could extract credentials, tokens, and certificates from memory using CVE-2026-109619. 

Edge devices such as industrial routers and switches running embedded PHP are also at risk for compromise; these devices direct traffic between field devices and external networks. An attacker exploiting these devices could gain root access to critical networking hardware. Some IoT management panels that use PHP could also be exploited by an attacker who would then be able to run a malicious over-the-air update to gain control of a device. 

In a healthcare context, some PACS imaging systems contain PHP as part of their installation and would be vulnerable unless patched; the impacts range from code execution on the system, lateral movement onto the hospital or OT networks, and a compromise of patient data. 

Operational Impact Can Extend Beyond Affected Systems

A compromised supporting application can affect operations involving equipment that does not itself run PHP. For example, losing a monitoring service could reduce visibility across multiple assets while the equipment continues functioning. Where the compromised service can modify data, the integrity of operational records or information used for decision-making could also be affected. The extent of the disruption depends on the application’s responsibilities, the workflows relying on it, and whether alternative ways of working remain available. Compromise of a supporting application can therefore have operational consequences without giving an attacker direct control of the underlying equipment.

Management Interfaces Can Provide Access to Other Systems

An affected management interface may be reachable from a compromised internal host or a maintenance connection, even without direct internet exposure. Successful code execution runs with the PHP service account’s privileges, potentially exposing credentials, configuration data, and resources accessible to that account. Further compromise depends on the permissions and network connections available. Reliable exploitation can require adaptation to the deployment’s PHP build, configuration, and memory behavior. Some demonstrated attack paths also reach vulnerable processing before application authentication, so the presence of a login page does not establish that the underlying service is protected.

Hidden Software Dependencies Complicate Exposure Assessment

PHP may be bundled within a larger application, an embedded software package, or an optional feature, making its presence difficult to identify from a product name or hardware inventory alone. Two deployments of the same product may consequently have different exposure because their installed components, configuration, or patch status differ. An affected PHP component also does not establish that every deployment is equally exploitable: reachable request-processing paths and runtime conditions influence whether an attack can succeed. The software’s presence, its susceptibility to these vulnerabilities, and its potential operational impact are related but distinct aspects of the risk.

How Claroty Finds, Prioritizes Affected Assets for Patching

The next step is to turn this assessment into a prioritized patching plan. Claroty xDome and Claroty Continuous Threat Detection (CTD) support that process through asset visibility, vulnerability insights, and network communication context. Combined with product advisories and operational knowledge, these insights help security teams determine which assets need further investigation and which require urgent remediation.

Identify Potentially Affected Assets

Use asset inventory and vulnerability information to identify devices, supporting servers, and management applications that warrant review. Confirm whether an affected PHP component is installed and whether the deployed software already includes a fix, using product advisories and available software records. Where the component version or patch status remains unknown, keep the asset in scope for investigation, prioritizing verification for systems that are exposed or critical to operations.

Identify Affected Assets and Verify Patch Status

xDome and CTD use vendor advisories to match affected products and models to assets in your environment. Review the vulnerability findings associated with CVE-2026-109618 and CVE-2026-109619 to identify potentially affected devices. Check each matched asset’s available version and patch information against the vendor’s guidance, and confirm any gaps with the asset owner to determine which devices require remediation.

Confirm Who Can Reach The Affected Service

Confirm whether the web interface or API using PHP is enabled. Use communication visibility in xDome or CTD to review observed access, then establish whether the service is reachable from the public internet, internal networks, or maintenance connections. Consider existing access restrictions when assessing exposure, and resolve gaps with the responsible team. A service’s network location alone should not determine its priority.

Prioritize by Operational Risk

Combine the confirmed exposure with the PHP service account’s permissions and the operational functions that depend on the application. Give greater urgency to affected services whose compromise could disrupt critical workflows, expose sensitive resources, or provide access to other systems. Internal services supporting essential operations may also require urgent remediation. Use these findings and existing protections to agree on a patching order with operations teams.

Hunting and Detecting PHP2Shell Exploitation

In CPS environments, focus PHP2Shell hunting on the web interfaces and APIs of potentially affected management, monitoring, and reporting systems. Where HTTP details are visible, investigate multipart POST requests with excessive repeated headers or unusually long field names, particularly when followed by HTTP 500 server errors. Check whether these upload requests fit legitimate firmware updates, configuration changes, or maintenance activity. Another relevant indicator is an unusually large or malformed PHP session cookie (PHPSESSID) returned by the service: a demonstrated PHP2Shell attack path can disclose process memory through that field. Correlate these findings with the asset’s operational role and any new connections it initiates to engineering workstations, other management systems, or unfamiliar external destinations. Such activity warrants investigation, especially when it crosses expected operational boundaries, but does not by itself prove compromise. These HTTP indicators require visible traffic or suitable web logs; connection records alone cannot reveal the request contents or rule out memory disclosure.

Recommendations and Remediation

We recommend these five mitigation measures to address the PHP2Shell vulnerabilities.

• Apply vendor-supported updates. Update affected devices, applications, and supporting servers according to the vendor’s advisory. Coordinate deployment with operations teams, validate changes against critical workflows, and plan any required maintenance window and recovery procedures.

• Verify that remediation is complete. Complete any required service restart, redeployment, or device reboot specified by the vendor. Confirm that the running software includes the PHP fix and that essential monitoring, management, and operational functions continue working as expected.

• Restrict access while patching is pending. Where a fix is unavailable or cannot yet be deployed, use network segmentation to limit access to affected services. Remove unnecessary external access and allow only the inbound and outbound connections required for management and operations. Restrict communication with internal hosts as well as external networks. These controls reduce exposure but do not replace patching.

• Continue monitoring and hunting. Monitor network traffic for the PHP2Shell indicators described above and unexpected communications involving affected assets. Give particular attention to internet-facing services, perimeter networks, DMZs, and connections into operational networks. Retain relevant logs to support investigation of activity before and after remediation.

• Investigate suspected compromise. If exploitation is suspected, preserve relevant evidence and involve incident-response and operations teams in containment and recovery decisions. Assess whether attackers established continued access or exposed credentials or other sensitive information. A successful update alone does not establish that a previously compromised system is secure.

Talk to an expert about PHP2Shell, and Claroty xDome.