PHP2Shell industrial OT products: what vendors have warned and why inventory decides

The PHP2Shell patch was published on 21 October, but working out which PHP2Shell industrial OT products are affected means reading the vendors' advisories. Those advisories do identify industrial products hit by PHP2Shell. SecurityWeek reports affected industrial products and advisories published by Siemens, Schneider Electric, ABB, Rockwell Automation and Johnson Controls [3].

That is why the bottleneck is not downloading an update. It is the inventory: knowing which embedded components in the plant run a PHP interpreter and what each vendor has said about them.

PHP2Shell went from probing to working shells within days

PHP2Shell is the name that groups the critical flaws CVE-2026-109618 and CVE-2026-109619. According to SecurityWeek, both allow unauthenticated remote code execution (RCE), and PHP fixed them on 21 October after some of the information leaked onto the Internet [1]. BleepingComputer adds that the PHP security team had asked administrators the day before to get ready to install the updates as soon as they were available [2].

Attackers got ahead of the patch. SecurityWeek places the first exploitation attempt on 17 October, before a fix existed, and reports that Cloudflare has since recorded a massive volume of attempts [3]. For days, no security company confirmed successful code execution. According to the same outlet, however, researchers had already developed exploits capable of bypassing address space layout randomization (ASLR) [1].

The change came on 24 October. According to SecurityWeek, the sensors of Adel Karimi, a researcher at Perplexity, recorded 35 shells launched against his honeypots, 32 of them from a single IP address [1]. The attackers chained HTTP requests: some exhausted PHP's memory, others leaked its contents, and the last one executed a command. Karimi considers that the activity is consistent with exploitation of CVE-2026-109618 [1].

BleepingComputer gives a more precise account of the case. Karimi's honeypots, run by the head of detection and response at Perplexity, recorded confirmed remote code execution against an Apache mod_php installation running PHP 8.4.26 [2]. The server's response included a decoded cookie dump. A function address calculated from that dump using the public exploit's offsets later appeared in the execution payload. Karimi described it as confirmed RCE with exploitable memory leakage, not as a mere crash followed by a suspicious process [2].

The researcher himself cautioned that his setup was deliberately favorable, with a single mod_php worker. According to Karimi, his results do not measure the exploit's reliability with other numbers of workers, PHP builds or applications [2]. Marcus Hutchins, of Expel, called it the highest-quality confirmation he had seen so far [2]. For its part, the US Cybersecurity and Infrastructure Security Agency (CISA) added a Sigma detection rule to its alert on 23 October. According to SecurityWeek, on the morning of 26 October it had not yet included the flaws in its Known Exploited Vulnerabilities (KEV) catalog [1].

All of this happened in an especially crowded week. The weekly roundup from The Hacker News describes critical remote-execution flaws appearing everywhere and security teams with more urgent patches than they can absorb [5]. Among them is CVE-2026-111497, known as Node2Shell, a flaw in Google's Brotli decompression library that could also allow unauthenticated remote code execution. According to the same roundup, it has been fixed in libraries and platforms that depend on Brotli, such as Node.js, Python or Envoy [5]. If you are looking for the web context of the problem, you can read our general analysis of the PHP2Shell vulnerabilities. What matters here is something else: what happens when that PHP is not on a website but on the plant floor.

Industrial vendors have already published advisories, but their answers differ

According to SecurityWeek, several major industrial vendors have confirmed that some of their industrial and operational technology (OT) products are affected. Others are still assessing their exposure, and others have concluded that they are not affected [3]. According to SecurityWeek, the fixed PHP versions the outlet cites are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 [3]. In an industrial environment, though, those versions mean little if you do not know which version each device runs.

The OT vendor advisories for PHP show how deeply the interpreter can be hidden. According to SecurityWeek [3], the most illustrative cases are these:

• Schneider Electric declares EcoStruxure Security Expert, ProLeiT LINEoptimize and EcoStruxure Control Engineering as affected. A fixed version exists for the first, and ProLeiT support offers a remediation for the second. Users of the third can, for now, only apply mitigations.
• Siemens states that Ruggedcom APE1808 devices running certain versions of Palo Alto Networks' PAN-OS are affected. It refers customers to its support channel for patch information and to the operating system vendor's workarounds.
• ABB warns that deliveries of its manufacturing execution system (MES) that include DokuWiki, used to display help pages, are affected. Its subsidiary B&R declares the APROL process control system affected up to version R 4.4-65, with patches planned for 26 and 29 October.
• Rockwell Automation is still reviewing whether any of its products depend on a vulnerable version of PHP. At the date of its advisory, none had been confirmed as affected.
• Johnson Controls has published patches for several Illustra lines and has fixed Visonic PowerManage in version 5.0.45.

The list continues with other vendors. Belden acknowledges that all versions of NetModule NRSW are affected, still without a patch, and recommends disabling the web interface. Hitachi Energy is still investigating, while Moxa has determined that none of its products is affected [3].

A practical idea follows from these advisories: an advisory is not a patch. Likewise, a product "under evaluation" is not a healthy product, but one whose status is still unknown. While that uncertainty lasts, compensating measures are the way to act.

The real bottleneck is the inventory of embedded components

The global figures are impressive, but they do not solve a plant's problem. According to BleepingComputer and Infosecurity Magazine, PHP powers around 70% of websites on the Internet [2][4]. BleepingComputer cites VirusTotal estimates of more than 5.1 million PHP hosts exposed on the Internet and roughly 3.8 million with at least one port open to attack [2].

Those figures refer to the use of PHP on websites and to PHP hosts exposed on the Internet; they should not be used as a count of OT products. That is precisely why the useful question is not "have we patched PHP?" but "which devices in the plant include a PHP interpreter, in which version, and who updates it?"

Why the PHP patch is not applied blindly in OT

The vendors' examples sketch two very different situations. In ABB's case, the customer must update the PHP packages on the servers hosting DokuWiki [3]. In others, such as HMS Networks' Netbiter devices, the fix arrives as a firmware update from the vendor [3]. On the Ruggedcom APE1808, Siemens identifies as affected the devices running certain versions of Palo Alto Networks' PAN-OS [3].

In the editorial team's view, this mix explains why in OT it is not enough to install the PHP 8.4.27 patch wherever it turns up. Before modifying an internal component of an industrial device, it is advisable to check the vendor's instructions. It is also advisable to plan with the operations lead when to apply the changes. The reasonable path is to identify the device, find the advisory that applies to it and do what the vendor indicates. If there is no guidance, compensating measures remain. Building that visibility is the foundation of any industrial OT security strategy.

What to ask each equipment vendor

For each device or application with a web interface in the plant, it is advisable to get answers to these questions from the vendor or the integrator:

1. Does the product include a PHP interpreter? If so, in which version?
2. What is the advisory status for this product: affected, under evaluation or not affected?
3. Is there a patch, a fixed version or a documented mitigation? Who must apply it: the vendor, the integrator or your team?
4. Is the web interface exposed to untrusted networks, or can it be disabled without affecting operations?

Not every PHP advisory demands the same urgency: a table to prioritize

The same week brought another PHP flaw that should not be confused with PHP2Shell. According to Infosecurity Magazine, the PHP security team warned on 23 October about CVE-2026-115560, another remote execution vulnerability that will not be fixed until the next release [4]. The reason is that it only occurs with an unusual combination of configuration and code. The application must set session.serialize_handler to php_binary or php_serialize, change it to php at runtime with ini_set() before calling session_start(), and keep session upload progress enabled [4]. As a mitigation, PHP recommends setting session.upload_progress.enabled=0, the same measure it already advised on 21 October in the CVE-2026-109619 advisory [4].

The comparison helps order the work:

From there, the priority order we propose for the plant's devices is an editorial criterion, not a standard. First, the products the vendor declares affected and whose interface is reachable from untrusted networks. Next, those affected in isolated segments and those still under evaluation with exposure. Last, those declared not affected, whose advisory should be filed as evidence. If your organization falls within the scope of the European NIS2 Directive, it is also worth reviewing how this documented prioritization fits with the NIS2 requirements for the industrial and OT sector.

Until the vendor's patch arrives, detection holds the defense

For devices without a patch or under evaluation, the measures that matter are those that do not depend on the vendor. The first is to limit which web interfaces are reachable and from where, in line with Belden's recommendation to disable the web interface while no fix exists [3]. It also helps to watch for anomalous processes and traffic on the servers and devices that run PHP, and to follow each supplier's advisories closely.

Karimi's case shows why monitoring matters. Karimi documented the remote execution through the response with leaked memory and the later payload that used an address derived from it [2]. While you wait for the patch, it is advisable to reinforce visibility over the activity of the affected devices. HMS Networks, for example, has stated that it fixed or removed vulnerable PHP versions from its Talk2M services and its Argos documentation server, and that it found no indicators of compromise [3]. It is advisable to keep logs that make it easier to search for indicators of compromise.

Patching PHP is the easy part. The hard part is knowing which industrial devices carry it inside, and whoever has that inventory and their vendors' advisories will decide with an advantage. If your team needs support to gain that visibility on an ongoing basis, a managed monitoring and response service (SOCaaS/MDR), with an external security operations center (SOC), can complement the inventory while vendors finish publishing their fixes.