TL;DR: PHP2Shell has been the target of widespread attack attempts since its disclosure on October 21, 2026, with first attempts seen as early as October 17 according to Amazon. A login does not protect you, and there are no official updates for PHP 8.1 and older. In industrial sites, PHP sits in the web interfaces of controllers, industrial routers and firewalls, as well as EV chargers and energy equipment whose firmware is rarely updated. Operators should cut these web interfaces off from the internet now. Vulnerable PHP web interfaces will in all likelihood still be found in industrial sites well beyond 2030.
This is an English adaptation of my German original.
On October 21, 2026, the PHP team closed two critical vulnerabilities known as PHP2Shell. Both allow remote code execution without authentication. The BSI (German Federal Office for Information Security) warns at level 3 (orange). The discussion so far mostly centers on websites and online shops. From an OT perspective, what matters is what happens inside the plants, for operators and machine builders in the DACH region and beyond.
The attacks are already running
Broad attack attempts have been under way for some time. According to Amazon, the first attack attempt on its honeypots was seen on October 17, four days before disclosure. Cloudflare observed attempts even before the announcement and a sharp increase after it.
The US agency CISA had not observed exploitation at the time of disclosure. Mass scanning and attack attempts are documented. How many of them succeeded is unknown.
PHP processes the crafted request before the actual application even starts. A password on the web interface does not stop the attack.
According to Sansec, the faulty code originates from PHP 5.4, i.e. from 2012. Since then, PHP has found its way into a great many devices.
Where PHP hides in OT devices
Public documentation indicates PHP in the web interface of devices such as the following. This is not a list of affected products: whether and how a device is affected by PHP2Shell is for the respective vendor to assess. Most of the vendors listed here have not yet published a statement on PHP2Shell.
- Controllers and HMI: WAGO PFC100, WAGO PFC200, WAGO CC100, WAGO Edge Controller, WAGO Touch Panels (Standard, Advanced, Marine); Kunbus Revolution Pi with PiCtory
- Routers and switches: NetModule NB800, NB1601, NB1800, NB1810, NB2800, NB2810, NB3701, NB3800, NG800; Phoenix Contact TC ROUTER 4002T, 4102T, 4202T; TC CLOUD CLIENT 2002T, 2102T; FL SWITCH 2000 series; FL NAT 2008
- Firewalls (status per vendor advisories as of October 22, 2026): Palo Alto PAN-OS 10.2 to 12.2 and Panorama (affected according to the Palo Alto advisory, fix pending); OPNsense (fixed in 26.7.7 and 26.4.2p3 according to OPNsense); Netgate pfSense (update released); Juniper J-Web on SRX and EX (PHP-based web interface); Citrix, Ivanti and F5 BIG-IP use PHP according to heise, whether they are affected is open; Fortinet is checking FortiADC, FortiSIEM and FortiClient EMS, FortiOS is not affected
- EV chargers: eCharge Hardy Barth cPH2 and cPP2; Salia PLCC charge controller (according to ONEKEY)
- Energy, PV, smart meters, telecontrol: Contec SolarView Compact; Ezylog PV server; volkszaehler.org; Mitsubishi Electric smartRTU and INEA ME-RTU
- Building and access control: ABB Cylon Aspect (NEXUS, MATRIX-2, ASPECT-Enterprise); Schneider Electric U.motion Builder; Nice Linear eMerge E3
- Monitoring in OT networks: Nagios XI, Cacti, LibreNMS, Zabbix frontend
In our research, we found no public evidence of PHP for: Ignition, Copeland XWEB Pro, Kieback&Peter DDC4000, the Samson TROVIS district heating controller, Solar-Log, Danfoss AK-SM 800A, Siemens SCALANCE and RUGGEDCOM, as well as smart meter gateways. No evidence does not mean ruled out.
All sources and ongoing updates are in the incident situation report on PHP2Shell (German).
PHP alone does not make a device vulnerable
Whether a device is actually vulnerable depends on the PHP version and the operating mode, and on whether the web interface is reachable at all. Only the vendor can assess this. Operators can find the current status in vendor advisories and at CERT@VDE.
Why the vulnerability stays in industrial sites for years
It is not new that such vulnerabilities have long-lasting effects. For Log4Shell, according to Tenable, almost a year later 72 percent of organizations were still vulnerable. An earlier php-cgi vulnerability was used by ransomware a few days after the patch and still a year later. With Contec SolarView, a PHP vulnerability in this PV monitoring product was exploited by Mirai a year after the exploit appeared. Devices were later also hijacked for banking fraud.
PHP2Shell will likely follow a similar pattern, just in stages. Until the end of 2026, mass scans and botnets are likely to dominate. Firewalls and VPN access are likely to be the main focus, because they open the way into the network. In 2027 and 2028, the large vendors are likely to deliver updates, but operators will probably only apply them in maintenance windows. To make things worse, PHP 8.2 reaches end of life at the end of 2026, and 8.3 at the end of 2027. From 2029, a remainder is likely to stay, mainly devices without vendor support. This is exactly what botnets and criminals can then be expected to use.
The longest-lived vulnerable systems will in all likelihood be charge controllers with old PHP versions, PV loggers, telecontrol stations in water and district heating, building automation and access control, and industrial routers in machines running without a maintenance contract. For production and maintenance, this means: the router in the control cabinet, through which the machine builder has had remote maintenance access for years, belongs at the top of the list.
What the CRA means for machine builders
Since September 11, 2026, manufacturers must report actively exploited vulnerabilities as an early warning within 24 hours and in detail within 72 hours. Once active exploitation is confirmed, this can also apply to machine builders if they place the machine on the market as a product with digital elements and the vulnerability sits in a purchased controller or router. If you do not know where PHP is installed, you cannot report on time. We support the reporting process and supplier inquiries with CRA as a Service.
What operators should do right now
- Cut the web interfaces of controllers, remote maintenance routers and firewalls off from the internet and make them reachable only via VPN or a jump host.
- Firewalls first: update OPNsense and pfSense; for PAN-OS, restrict management to trusted internal addresses until the fix is available.
- Inventory devices with web interfaces, including firmware version, and ask the vendor for the PHP version and update date. Where this overview is missing, an OT asset inventory helps.
- Check exposed systems for anomalies from October 17 onward. If you find traces, contact our OT emergency response.
Securing for the long term
For the time after the emergency, operators are best advised to follow the SANS Five ICS Cybersecurity Critical Controls. Applied to PHP2Shell, this means: an ICS-specific incident response plan and a defensible architecture with a dedicated management network. Add passive attack detection in the OT network (see attack detection), secure remote access with multi-factor authentication, and risk-based vulnerability management with an SBOM at procurement. Continuously matching vendor advisories against your own inventory has become feasible even for small teams with AI support.
Quickly done in IT, far from done in industrial sites
In IT, PHP2Shell will in all likelihood be largely dealt with in a few weeks. In industrial sites, the vulnerability will remain well beyond 2030: the devices run for a long time and are rarely updated. Besides, hardly anyone knows that PHP is inside them at all. Operators should therefore by no means wait until the vendor delivers an update. Anyone who isolates the web interfaces now removes most of the risk, even before the update arrives.
Max Gilg, OT cybersecurity expert from Rosenheim, OT-Cyber.de
Sources: PHP advisory, BSI warning 2026-297981-1032, CISA alert of 10/21/2026, Amazon Threat Intelligence, Cloudflare, SANS ISC, Sansec, Palo Alto advisory CVE-2026-109618, Fortinet FG-IR-26-186, Cisco cisco-sa-php-october26, OPNsense, NCSC-NL php2shell, ONEKEY, heise, Kaspersky ICS CERT, Tenable, VulnCheck. All individual sources are in the situation report.
Want to keep track of advisories against your own asset inventory? See KI-Lagebild für Ihre Anlagen.
Original (German): https://ot-cyber.de/blog/php2shell-in-ot-anlagen-warum-die-luecke-jahre-bleibt.html
Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).
Top comments (0)