PHP2Shell in OT: What's Confirmed Affected, Where PHP Hides, and How to Triage It

PHP2Shell looks like a web server problem. For most of the internet, it is. For OT environments, the more important question is not "do we run PHP websites" but "which of our firewalls, routers, monitoring boxes, and embedded devices have a PHP web interface we never think about."

That is a harder question to answer, and it is the one this briefing is built around. Below is what is confirmed, what is likely, what is not affected, and a triage plan sized for a small team.

• What it is: Two flaws in the PHP runtime itself, CVE-2026-109618 and CVE-2026-109619. Both allow unauthenticated remote code execution. CVE-2026-109619 also leaks worker process memory, which can contain credentials and API keys. PHP rates both CVSS v4 9.2.
• Why a login page does not help: In PHP's confirmed attacks, the bug triggers while PHP is still setting up the incoming request, before the application's own code (including its login check) runs. PHP rates Apache mod_php as the highest-risk setup, with remote code execution demonstrated for both CVEs. PHP-FPM is confirmed for CVE-2026-109619, and PHP assesses FrankenPHP and LiteSpeed as likely susceptible. PHP rates attack complexity as high, but watchTowr and others have publicly reproduced the bugs, so that is limited comfort.
• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, released October 21. Branches 7.4, 8.0, and 8.1 get source-only backports (no packaged release). PHP 5.4 through 7.3 get nothing.
• Exploitation: Amazon observed an exploitation attempt on October 17, four days before disclosure, and multiple actors since. watchTowr, VulnCheck, and Cloudflare all report attempts. CISA had not observed exploitation as of its October 21 alert. No confirmed compromise has been published. Neither CVE is in the KEV catalog as of the October 21 catalog release.
• Why it will linger in OT: One internet scan (Modat) estimates roughly 79% of exposed PHP services run unsupported branches. Embedded devices ship whatever PHP version the vendor froze into the firmware, and that firmware is rarely updated.

These are vendor statements, not inference. Statuses are as of October 22 and will change, so check the linked advisory before you close a ticket.

As of this writing, no major ICS vendor (Siemens, Schneider Electric, Rockwell, ABB, Moxa, WAGO, Phoenix Contact) and no CERT@VDE advisory has published a PHP2Shell statement. That is not a clean bill of health. It means the questions have not been answered yet.

PHP is rarely in the control layer itself. It shows up in the web interfaces wrapped around it. Here is where to look, by environment.

Every sector: the IT/OT boundary. Firewalls and remote-access gear are the highest-value targets because they sit on both networks. Palo Alto and pfSense are confirmed above. Juniper J-Web is PHP-based (CVE-2023-36844 was a PHP flaw in J-Web), and other appliance management UIs may be too. Check each vendor's advisory page directly.

Every sector: monitoring in the OT DMZ. Zabbix, Cacti, Nagios XI, LibreNMS, Icinga Web, and Observium front-ends are all PHP applications. These boxes are often the one web server that can reach both corporate and control networks, and they are often installed once and forgotten. Here the fix is the operating system's PHP package (via your Linux distribution's security update), not an application update. Several distributions shipped patched packages on disclosure day.

Water and wastewater, small municipal utilities. The common pattern is a pfSense or OPNsense box as the OT firewall, a cellular router for remote sites, and a Linux monitoring server. Start there. Industrial cellular routers from vendors such as NetModule and Phoenix Contact (TC ROUTER) have used PHP-based web interfaces according to public documentation.

Electric, renewables, and EV charging. Telecontrol RTUs, PV data loggers, and EV charge controllers are where the long tail lives. Public documentation shows PHP in products such as Mitsubishi Electric smartRTU, Contec SolarView Compact (previously exploited by Mirai botnets), and some EV charge controllers. These devices are frequently internet-reachable for remote monitoring and rarely see firmware updates.

Manufacturing. Linux-based edge controllers and HMI panels are the likely exposure. Public documentation shows PHP in the web-based management of WAGO PFC100/PFC200/CC100 controllers and Touch Panels, and in Kunbus Revolution Pi tooling.

Building automation and physical access. BMS supervisory controllers and access control panels with web UIs. ABB Cylon Aspect and Nice Linear eMerge E3 are documented PHP-based products.

What is not in scope. Windows/.NET and Java OT software does not run PHP and is not directly affected. AVEVA PI Vision and PI Web API (ASP.NET on IIS) and Inductive Automation Ignition (Java) are examples. The indirect risk still applies: if your historian shares a DMZ with a vulnerable Zabbix or pfSense interface, an attacker who lands on the PHP box is now next to the historian.

Sized for a small team. Each tier assumes the one before it is done.

Today

1. Lock down firewall management. For Palo Alto, restrict the management interface and any management profiles on data-plane interfaces to trusted internal IPs or a jump host, and enable the Threat Prevention signatures. For pfSense and OPNsense, confirm the GUI is not reachable from WAN or any untrusted interface, then update.
2. Find anything PHP-backed that is reachable from the internet. Pull your external exposure list (or run a Shodan/Censys search on your own IP ranges) and look for web interfaces on firewalls, routers, RTUs, loggers, and chargers. CISA's guidance is blunt: if you cannot update a PHP system, or it runs PHP 8.1 or older, take it offline until it can be patched. For an embedded OT device, "offline" usually means "remove internet and corporate reachability," not "power off."
3. Apply IPS or WAF signatures where you have them. Palo Alto, Fortinet (OT IPS 37.316), Sophos, and Cloudflare have all shipped coverage. Treat these as stopgaps.

This week

1. Patch what has a patch. pfSense, OPNsense, and the PHP packages on your Linux monitoring servers (Zabbix, Cacti, Nagios XI, LibreNMS). Restart every PHP worker after the update.
2. Inventory PHP web interfaces inside the boundary. Every device and server with a web management page on the OT side or in the DMZ. For each one, record: vendor, model, firmware, whether it is PHP-based (vendor docs or vendor answer), and what can reach it.
3. Send the vendor question (template below) to every embedded vendor on that list.
4. For systems you cannot patch, apply PHP's interim settings where you control the PHP configuration. For CVE-2026-109618, set memory_limit=-1 administratively, and enforce request size limits at the web server or proxy, since PHP's memory cap is now off. Do not substitute RLIMIT_AS or RLIMIT_DATA limits, which recreate the failure the bug depends on. For CVE-2026-109619, set session.upload_progress.enabled=0, and on PHP 8.5 also fatal_error_backtraces=0. Restart every worker afterward. PHP is explicit that none of these fully closes either bug. For appliances you cannot reconfigure, segmentation is your control.

This month

1. Look back for signs of compromise, starting October 17. Successful exploitation can be quiet: the worker may keep running and return HTTP 200. The clearest evidence is a PHP worker process (php-fpm, httpd, apache2, lighttpd) spawning shells or download tools such as sh, bash, curl, or wget, or making new outbound connections. For CVE-2026-109618, researchers point to Allowed memory size ... exhausted fatal errors reported at Unknown on line 0 (meaning PHP failed before any script ran), oversized multipart POSTs, and Apache Segmentation fault child crashes. PHP warns that clean logs cannot prove you were not hit, so a host with suspicious traffic and quiet logs still deserves a closer look.
2. Track the long tail. Put every "vendor has not answered" device on a recurring review. This will not resolve in a week. PHP 8.2 support ends at the end of 2026, which means more embedded firmware will fall off the patched branches over the next year.

Copy, adjust, and send. A written answer is also your evidence.

We use [product, model, firmware version] in our environment. Please confirm in writing:

1. Does this product include PHP? If so, which version?
2. Is the product affected by CVE-2026-109618 or CVE-2026-109619?
3. If affected, which interfaces are exposed (web management, API, other), and what is the fixed firmware version or expected date?
4. What mitigations do you recommend until a fix is available?

Write down what you checked and what you did while you are doing it. Vendor statuses on this one will keep changing for months, and a running record means you pick up where you left off instead of starting over each time an advisory updates. It is also the evidence an audit will ask for anyway. Keep it simple:

• Date you assessed it, with links to the PHP, CISA, and vendor advisories you used.
• Your PHP inventory, including the "not PHP" and "unknown" entries. An honest unknown with a vendor ticket number is better than a blank.
• Actions taken with dates: management interfaces restricted, signatures enabled, packages updated, devices isolated.
• Vendor correspondence: who you asked, when, and what they said.
• Open items with an owner and a next review date.

If you fall under AWIA, NERC CIP-007 patch management, or a similar framework, this is the same record those programs expect for evaluating and responding to a security patch.

• PHP: RCE via OOM corruption (CVE-2026-109618)
• PHP: RCE via stale global state (CVE-2026-109619)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Palo Alto Networks: CVE-2026-109618
• Netgate: Critical PHP Security Update
• Fortinet: FG-IR-26-186
• Sophos: sophos-sa-20261021-php2shell
• Tenable: php2shell FAQ
• watchTowr: PHP2Shell
• The Hacker News: exploitation attempts four days before disclosure
• Datadog Security Labs: PHP2Shell detection and analysis
• Cloudflare: WAF protections for PHP2Shell
• CERT-EU Security Advisory 2026-018
• Canadian Centre for Cyber Security AL26-026
• OT-Cyber.de: PHP2Shell in OT sites (source for products documented as PHP-based)