PHP2Shell explained: what the critical PHP vulnerability means for OT and ICS

PHP2Shell is the name for two critical flaws in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, that can let an unauthenticated attacker run code on a server that processes web requests with PHP. PHP fixed them on 21 October 2026, a day earlier than planned after the identifiers leaked. Most coverage focuses on websites. For operational technology the more important question is where else PHP is running: on firewalls, remote-access gateways, industrial routers, monitoring servers and engineering help systems at the edge of control networks.

What PHP2Shell is, in brief

Both flaws are rated 9.2 (CVSS v4.0) by the PHP security team. According to Tenable's summary of the advisories:

• CVE-2026-109618 is memory corruption in PHP's out-of-memory error handling.
• CVE-2026-109619 is a use-after-free in which state left over from one request can be used by a later request on the same worker. Memory disclosure is a confirmed impact.
• Any PHP installation that serves web requests is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest risk because exploitation can happen before any application code runs.

Affected and fixed versions

Linux distributions, hosting control panels (cPanel, Plesk, DirectAdmin) and cloud providers have shipped their own patched packages.

Is it being exploited?

Reports differ by source, which is normal in the first week. Amazon Threat Intelligence reported a first exploitation attempt against its honeypots on 17 October, four days before disclosure, and further attempts from multiple actors after the release. Rapid7 has seen exploitation attempts and notes that the public proof-of-concept code it tested only worked in narrow lab conditions. CISA published an alert on 21 October urging immediate patching and recommending that systems which cannot be updated quickly, or that run PHP 8.1 or older, be taken offline. Treat it as actively targeted: start any investigation from 17 October.

Why OT and ICS teams should care

Few control systems run PHP in the controller itself. The exposure sits around them, in the devices and servers that connect control networks to everything else:

• Firewalls and gateways at the IT/OT boundary. Palo Alto Networks confirmed that PAN-OS management interfaces are affected. Siemens followed on 23 October with SSA-566512: every RUGGEDCOM APE1808 running PAN-OS 10.2 to 12.2 is affected. Netgate pfSense, popular as a small-site OT firewall, is affected when its web interface or captive portal is exposed.
• Remote access and industrial routers with web management consoles, often reachable from the internet at remote sites.
• Monitoring and documentation servers in the OT DMZ. Network monitoring tools with PHP front-ends, wikis and help servers. ABB, for example, published an advisory for the DokuWiki help server used with its Manufacturing Execution System.
• Engineering and process-control software. B&R published an advisory for its APROL process control system, and HMS Networks, Johnson Controls, Rockwell Automation, Schneider Electric and Moxa have issued statements (some confirming products are affected, others not), according to Patrick Coyle's tracker of control-system advisories.

Two things make this harder in OT than in IT. First, these devices are often missing from the asset inventory as "PHP systems" because nobody installed PHP knowingly: it came inside an appliance. Second, patches arrive through vendors on their own schedule, and installing them needs a maintenance window. Some fixes for industrial products are still weeks away.

What to do this week

1. Find PHP at the edge. List every web management interface on firewalls, VPN and remote-access gateways, industrial routers, RTUs, data loggers and DMZ servers. Record vendor, model, firmware and who can reach it. Your asset inventory is the starting point; if it has no firmware detail, this is the week to add it.
2. Cut reachability first. Restrict management interfaces to a trusted jump host or management network. Nothing in the control network should expose a web console to the internet or to the general corporate network.
3. Patch what has a fix. Linux PHP packages, pfSense and similar appliances, and the DokuWiki and monitoring servers in your DMZ. Restart all PHP workers after updating.
4. Ask your vendors. For every product with a web interface, ask whether it contains PHP, which version, and when a fix is due. Track the answers.
5. Use interim mitigations only where you control PHP. PHP and Rapid7 list temporary settings (an administratively enforced memory_limit=-1, session.upload_progress.enabled=0, and on PHP 8.5 fatal_error_backtraces=0, followed by a worker restart). They reduce exposure but are not a fix, and you should not change appliance internals your vendor does not support.
6. Look back to 17 October. Check logs for PHP worker processes starting shells or download tools, unexpected outbound connections and bursts of memory-exhaustion errors. Clean logs are reassuring, not proof.

The OT vulnerability management approach applies directly: confirm applicability per asset, document the decision, and use compensating controls where patching has to wait.

A note on our own site

otvista.com uses PHP for its contact form. We checked on 26 October: the hosting provider had already moved the site to PHP 8.3.36, a fixed release. If you run your own web servers, check yours the same way: confirm the exact version, not only the branch.

How OTVista helps

PHP2Shell is a test of how well you know what sits at the edge of your OT network. In OTVista, the Asset Visibility module records firmware and software components per asset, Vulnerability Management tracks each advisory against those assets with a recorded decision, and Patch Management plans fixes around maintenance windows. Start with the free Quick Check, or have a practitioner run an OT security architecture review focused on your IT/OT boundary.

For the attack path from a web server into a control network, read the companion article: How a web server flaw becomes an OT incident.

Sources: PHP security advisories (21 October 2026) as summarised by Tenable and Rapid7; CISA alert, 21 October 2026; Siemens ProductCERT SSA-566512 (23 October 2026); Palo Alto Networks advisory CVE-2026-109618; Patrick Coyle, "PHP Fallout in Control Systems" (24 October 2026). Vendor statuses change quickly: check each vendor's advisory before closing a ticket.

Topics: PHP2Shell, PHP2Shell vulnerability, CVE-2026-109618, CVE-2026-109619, PHP vulnerability 2026, OT cybersecurity, SCADA security vulnerabilities, ICS vulnerability management