Most attacks on industrial organizations do not start in the control system. They start on an internet-facing server and move inwards. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a timely example: a flaw in the PHP runtime that can give an attacker code execution on a web server or appliance. Whether that becomes an operational incident depends almost entirely on what the compromised system can reach. This article walks through the path, stage by stage, and the controls that break it.
For the vulnerability itself, affected versions and vendor status, see PHP2Shell explained.
Stage 1: the foothold on an edge system
The first target is anything running vulnerable PHP that an attacker can reach: a company website, a customer portal, a VPN or firewall management page, a monitoring dashboard in the DMZ, or the web console of an industrial router at a remote site. Exploitation gives the attacker the privileges of the web worker process, and typically a web shell to come back to.
What breaks it: an up-to-date inventory of internet-facing and boundary systems, fast patching for anything with a fix, and management interfaces that are simply not reachable from the internet. An attacker cannot exploit a console they cannot connect to.
Stage 2: credentials and identity
A web shell on its own is limited. The next step is credentials: configuration files with database or LDAP passwords, cached hashes, API keys and tokens. Palo Alto Networks' Unit 42 described this phase in its PHP2Shell threat brief: in an intrusion against a European government entity, an attacker using AI-driven tooling reached password hashes and MFA secrets within two hours, set up an NTLM relay towards Active Directory and attempted to become Domain Admin. (The brief focuses on what happened after initial access; treat it as an illustration of attacker speed rather than proof of how that intrusion began.)
Two hours is the important number. It is far shorter than the time most organizations need to notice a web shell.
What breaks it: no shared or reused credentials between the DMZ, the corporate domain and OT; service accounts with the least privilege needed; secrets kept out of web-readable files; and separate identity for OT so that a compromised corporate domain does not hand over the control network. See Identity & Access.
Stage 3: pivoting towards OT
With domain credentials, the attacker looks for the bridges into industrial networks:
- Remote access paths used by engineers and vendors: jump hosts, VPNs and remote desktop gateways.
- Dual-homed systems with one network card in IT and one in OT, often historians, engineering workstations or old file servers.
- Shared infrastructure such as backup servers, antivirus consoles or patch servers that manage both worlds.
- The boundary devices themselves. If the compromised PHP system is the firewall or gateway between IT and OT, as with affected PAN-OS based appliances, the attacker is already standing in the conduit.
What breaks it: a real industrial DMZ with no direct IT-to-OT traffic; every allowed flow documented in a zones and conduits model; one controlled, monitored path for remote access with MFA and approval (secure remote access for OT vendors); and boundary devices whose management interfaces sit on a separate management network.
Stage 4: inside the control network
Once inside, an attacker can map the process network, read historian data, and reach engineering workstations that hold project files and programming software. From there the possible impact ranges from data theft and ransomware on Windows hosts to manipulation of control logic, the scenario OT security exists to prevent. Many industrial protocols have no authentication, so the controls that matter are the ones that decide who can reach the network at all.
What breaks it: segmentation inside OT (cell and area zones, not one flat network), application allow-listing on engineering workstations, change control for logic and configuration, and monitoring of east-west traffic so that unusual connections to controllers are noticed.
Stage 5: detection and response
The SANS Five Critical Controls for ICS put incident response and network visibility next to defensible architecture for a reason: prevention fails eventually. For PHP2Shell, practical detection starts with:
- PHP worker processes (php-fpm, lsphp, httpd) starting shells, scripting interpreters or download tools.
- Unexpected outbound connections from web servers and appliances.
- Bursts of memory-exhaustion or fatal errors in PHP logs.
- New accounts, new scheduled tasks or new remote access sessions in the DMZ and OT.
Your incident response plan should say who decides to isolate OT from IT, how, and how quickly. Practise that decision before you need it.
Mapping the controls to IEC 62443
| Attack stage | IEC 62443 foundational requirement | Practical control |
|---|---|---|
| Foothold on edge system | FR 3 System integrity, FR 5 Restricted data flow | Patch and harden boundary systems; no internet-exposed consoles |
| Credentials and identity | FR 1 Identification and authentication, FR 2 Use control | Separate OT identity, least privilege, MFA |
| Pivot towards OT | FR 5 Restricted data flow | Industrial DMZ, documented conduits, single remote access path |
| Inside the control network | FR 5 Restricted data flow, FR 3 System integrity | Internal zoning, allow-listing, change control |
| Detection and response | FR 6 Timely response to events | OT monitoring, logging, rehearsed isolation |
A 30-day plan for OT teams
- Week 1: inventory every web-managed system at the IT/OT boundary and in the DMZ; close internet access to management interfaces; patch what can be patched.
- Week 2: review credentials shared between IT, DMZ and OT; rotate secrets on any system that ran vulnerable PHP; confirm remote access goes through one controlled path.
- Week 3: validate the conduits between IT and OT against your zones and conduits documentation; remove dual-homed hosts and undocumented flows.
- Week 4: run a tabletop exercise on "web server compromised, attacker heading for OT", and fix the gaps it reveals.
How OTVista helps
OTVista makes this plan traceable. The Zones & Conduits module shows every path between IT and OT, Remote Access records who can reach what and how, and findings link straight to owned remediation tasks. If you want help, a practitioner can run an OT cybersecurity assessment or an architecture review in the tool for you. You can also start with the free Quick Check.
Related: AI-assisted attacks on OT: what actually changed.
Sources: Palo Alto Networks Unit 42 threat brief on CVE-2026-109618 and CVE-2026-109619 (October 2026); Siemens ProductCERT SSA-566512; IEC 62443-3-3 foundational requirements; SANS Institute, Five ICS Cybersecurity Critical Controls. The attack stages describe a general pattern for defence planning, not a specific confirmed incident in an industrial environment.
Topics: OT cybersecurity attack vectors, IT OT convergence security, SCADA security, ICS attack path, PHP2Shell OT, OT incident response, industrial DMZ