The SANS Institute's 2024 ICS/OT survey reported that the use of cloud-based HMIs among respondents using cloud services for industrial operations had increased from 22% in 2023 to 32% in 2024. Remote telemetry analysis increased from 40% to 56% over the same period. These figures do not mean that the same percentage of plants exposes control systems to the public internet. They do show that remote monitoring and remote interfaces are real, evolving parts of industrial operations. (SANS, 2025 analysis of the 2024 survey)

This matters when a vulnerability appears in a widely used web runtime.

On October 21, 2026, PHP disclosed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known collectively as PHP2Shell. Under the relevant conditions, these flaws can allow an unauthenticated attacker to execute code on an affected system. The PHP project has released fixes for affected versions.

Critical vulnerabilities in widely used software seem to arrive at regular. At this point, we can only hope the good guys(or a good AI) finds the next one first.

A web application running an affected runtime can therefore become an entry point. But if that application is part of an industrial environment, what does compromising it actually give an attacker? Does it provide a route to the production process, or could the impact remain limited to the application and its data?

The answer depends on how the application is connected to the rest of the environment, and what it is allowed to do.

From a web application to an industrial process

Consider a manufacturing plant where staff use a web interface to monitor production status and review process measurements. The interface could be a custom-built application running PHP or Node.js, or a web-facing service connected to a larger industrial system. We are not assuming that a particular commercial SCADA product uses either runtime.

Behind the interface, a SCADA system helps operators monitor and control the process. PLCs execute control logic and interact with equipment such as motors, valves, and sensors. A historian stores process data for later analysis.

These systems exchange information, but they do not necessarily share the same permissions or network access. A web application that displays a temperature reading does not automatically have permission to change the temperature setpoint.

A typical design may place an external-facing application in an OT demilitarized zone (DMZ), separated from the control network. Selected process data can be made available through a restricted service, rather than giving the web application a direct connection to the PLCs.

Illustrative architecture. The placement of the historian and the mechanisms used to replicate data vary between plants.

The DMZ is not another network segment. Its purpose is to mediate communications between systems with different trust requirements. The application may be allowed to read a particular data service while being blocked from connecting to supervisory servers or controller networks.

Now suppose the web application is vulnerable to PHP2Shell and an attacker successfully exploits it.

CVE-2026-109618 is particularly relevant because it involves PHP's handling of an out-of-memory condition during request processing. Under the affected conditions, an error-handling path can leave internal request data partially initialized, leading to memory corruption during cleanup. The vulnerability can allow remote code execution in affected deployments. Its exploitability varies by deployment, so we should not assume every PHP installation is equally vulnerable.

Once code execution is achieved, the attacker operates within the capabilities of the compromised process. If the PHP worker runs under a restricted service account, that account's permissions still matter. The attacker may be able to access application files, read credentials available to the process, or interact with services the application uses. They do not automatically gain administrator privileges or control over every system reachable from the host.

The next question is network reachability. Can the compromised process contact only the application's data service, or can it also reach supervisory services? And if it reaches one, does the identity it can use have permission to perform the operation the attacker wants?

These are separate conditions. Code execution does not automatically grant network access, and network access does not automatically grant control authority.

The same compromise, two different outcomes

Consider two configurations of the same monitoring application. The PHP runtime and the initial compromise are identical. Only the application's access to other industrial services changes.

In the first configuration, the application reads replicated telemetry through a read-only service. Its network rules prevent it from reaching supervisory write services, and its identity cannot issue control commands. A compromise could expose data, disrupt the portal, or allow an attacker to manipulate what the portal displays. But there is no established path from that compromise to PLC control.

In the second configuration, the application has a legitimate integration with a supervisory API that accepts write operations. The application can reach that service, and its identity has permission to submit those operations. If the compromised process can use those privileges, an attacker may be able to submit unauthorized commands through the integration.

The initial vulnerability is the same. The available access and authority are different.

This second configuration is not just a theoretical possibility. In SANS's 2024 ICS/OT cybersecurity survey, among respondents using cloud services for industrial operations, 31.6% reported using a cloud-hosted HMI for remote control, while 28.4% reported using cloud services for remote control of engineering field devices. These are separate, potentially overlapping categories, so they should not be added together. The figures also do not mean that these systems were exposed directly to the internet. They do show that remote control is an actual use case, not simply a hypothetical extension of monitoring. (SANS, 2024 State of ICS/OT Cybersecurity, p. 10)

Even then, process impact is not guaranteed. The supervisory service may restrict which tags or operations the application can change, and controller logic or other protective mechanisms may limit the consequences.

The point is that a remotely accessible interface can be designed for monitoring alone, or it can expose functions that affect the process. We should not treat these as equivalent just because both are described as web-based HMIs.

There is another distinction worth making here: changing what operators see is not the same as changing the physical process.

Stuxnet provides a well-documented example of why that distinction matters. Its attack against industrial centrifuge systems modified PLC behavior. Analysis of the earlier Stuxnet 0.5 variant showed that it recorded normal operating values and replayed them during an attack on centrifuge-feed valves, making the process appear normal to operators even while the control system was being manipulated. (Symantec's analysis of Stuxnet 0.5)

Stuxnet was not a PHP or Node.js web-runtime attack, and we should not present it as one. Its relevance here is narrower: it demonstrates that an attacker can manipulate a physical process while concealing the change from the people monitoring it.

For a compromised web application, the distinction works in both directions. An attacker might alter the portal's displayed data without changing the process. Alternatively, if the attacker can exercise write authority through a supervisory service, the attacker may be able to affect the process itself. A plant must account for both loss of view and loss of control.

Where the boundary matters

Patching the vulnerable runtime remains the immediate priority. At least until the next vulnerability comes along to compete for that spot! The PHP project has published fixes, and organizations should identify affected deployments and follow the applicable vendor guidance. This is particularly important for industrial appliances where the runtime is bundled with a product and updates must be delivered or validated by the vendor.

But patching addresses the entry point. The architecture determines how far a compromise might extend.

A monitoring application should have only the access its function requires. If it needs to read process measurements, it should not automatically receive credentials that allow it to change setpoints. If write operations are genuinely required, those permissions should be explicit and limited to the necessary functions.

Network rules should enforce the intended communication paths. An application that needs a read-only data service does not also need unrestricted access to SCADA servers, engineering workstations, or PLCs. And if a supervisory API must be reachable, it should enforce its own authorization checks rather than trusting every request from a permitted network.

These controls address different parts of the problem. Segmentation can prevent a compromised application from reaching a service; least privilege can limit what the application can do when it reaches one. Neither makes the other unnecessary.

The same reasoning applies to monitoring and recovery. If the portal is compromised, operators need to know whether its displayed information can still be trusted. Recovery plans should cover the application and its dependencies, while the plant maintains procedures for operating when monitoring is unavailable or unreliable.

The question raised by PHP2Shell is therefore not whether every vulnerable web application can control a factory. It cannot be assumed to. The question is what that application is connected to, which credentials and permissions it holds, and whether those capabilities provide a route from web compromise to supervisory control.

In one environment, the incident may remain limited to a web application and the data it can access. In another, a write-capable integration may create a path to unauthorized operations.

Understanding the difference is what allows us to assess the risk beyond the vulnerability itself.