PHP2Shell in OT: What to Do When the Patch Isn’t Coming

For a website, a critical PHP flaw is a patching exercise. For an HMI, a protocol gateway, or a controller with an embedded web interface, it can be a multi-year exposure. Here is how to manage the risk you cannot remediate.

On 20 October 2026, details of two critical PHP vulnerabilities leaked ahead of coordinated disclosure. CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell, are each rated CVSSv4.0 base score of 9.2 and can allow unauthenticated remote code execution under susceptible conditions. The PHP project released fixes the next day, in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. [1][2]

For web hosting and enterprise IT, that makes this a patching exercise: inventory, patch, restart, verify – typically within hours or days. In many industrial estates none of those steps fits that timescale, and the first is often undone, because the asset register records an HMI or a gateway, not the web stack inside it. This article sets out why the fix cannot be applied swiftly in OT, what the exposed population looks like, and what asset owners can realistically do when a vendor fix is slow or never comes.

Where things stand, as of 29 October 2026

Exploitation is confirmed. Cloudflare reported signs of exploitation before the patches were released, [5] watchTowr reported exploitation through its honeypot network, [4] and public proof-of-concept code is circulating. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October, with a remediation deadline of 29 October for US federal civilian agencies. [3] The picture is changing quickly, so check current reporting before you act.

Why this matters now

Attackers are already going after exposed industrial devices. A joint US advisory (AA26-231A, 19 August 2026) describes AI-generated scripts, disguised as legitimate monitoring tools, used against internet-exposed PLCs. These attacks concern tooling and exposure, not a patchable CVE. [6] In October, refrigeration controllers at hundreds of French supermarkets were forced into defrost. The controllers were remotely reachable, and the effect was physical. No one has been publicly attributed, and how the attackers got in has not been established. [7][8] We found no public reporting that AI was used in those attacks and none linking AI to PHP2Shell.

The pattern is what matters. An internet-reachable web interface on an OT device is already a target, and PHP2Shell offers one more way through that class of interface.

Which PHP versions are affected

NCSC-NL puts the affected range at PHP 5.4 and later; other sources say PHP 5 and later, and earlier versions have not been assessed. The serving mechanism does not remove the risk: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed installations are all in scope. Risk is considered highest for mod_php, where an unauthenticated request can trigger exploitation before application code runs. [9]

A fixed PHP release is not a fixed product. Distributions and long-term-support vendors may ship their own backports, and an embedded product has the fix only if its vendor has shipped one. The last row of that table is where many embedded industrial devices sit. [10]

Where PHP hides in industrial assets

PHP2Shell has mostly been framed as a website problem. The harder cases are devices where PHP is embedded in a vendor product and the operator cannot update the runtime. In industrial networks that includes:

• HMI and SCADA web front ends
• Protocol gateways, serial-to-Ethernet converters, and remote-access appliances
• Historian, reporting, and KPI dashboards
• Building-management, energy-metering, and power and cooling controllers
• Cameras, access control, and integrator-supplied Linux hosts never adopted into the asset inventory

None of these identifies itself as a PHP system. Many were built and certified years ago, so the embedded runtime is often on an end-of-life branch. NCSC-NL notes that PHP is also embedded in appliances, network devices, and management interfaces where administrators may not be able to update it directly. [9] At the time of writing we had not seen OT vendor advisories on embedded PHP2Shell exposure. Treat that as absence of evidence, not evidence of absence.

What the internet shows

To put numbers behind this, we ran a data search on 29 October 2026 for internet-exposed industrial and building-control devices advertising PHP. The search was generated by modat.io, [15] and Indurex analysed and verified the results. The data describes what an attacker can see from the internet, not any one organisation’s estate.

The search returned 3,088 exposed services on 2,802 hosts in 37 countries. Most are not websites in any ordinary sense: 81% belong to devices that can change a physical output.

For 3,088 verified services the PHP version was end-of-life; the six largest families, shown below, account for 3,029 of them, and no vendor fix had been published for those families at the time of the search. Five of the six families serve the interface over plaintext HTTP on 80–100% of services, and one carries a vulnerability listed in CISA’s KEV catalog on every service in the family. None of that is specific to PHP2Shell. It shows how the exposed population already looks to an attacker.

How to read these numbers

• Results exclude deception infrastructure. Roughly 45% of the raw result set resolved to a small number of cloud-hosted honeypot addresses advertising OT banners; those records were identified and removed before analysis.
• This is a point-in-time snapshot of internet-facing services. It says nothing about internal networks.
• Counts are exposed services, not unique IPs.
• Version identification depends on what a device reveals and can miss vendor backports. End-of-life PHP is not proof of exploitability.
• Results depend on the search platform’s coverage and scan dates.
• Product families are anonymised on purpose.

What a shell on these devices can reach

Consider a hypothetical protocol gateway in a water-treatment plant: a small Linux appliance with a PHP configuration interface on one network and Modbus/TCP to a cell of PLCs on the other. It was commissioned in 2017, runs an old PHP 7 release, has had no firmware update since the vendor stopped releasing them, and appears in the asset register as Comms Gateway 03. That PHP branch has no fix from the PHP project, so only the vendor could provide one.

An attacker who can reach the interface and meets the exploit conditions gets code execution as the web-server user. Whether that matters to the process depends on five gates, each of which must be verified, not assumed.

Gate 4 is where protocol precision matters. Classic Modbus/TCP has no authentication and no per-request session. If the PLCs accept writes from the gateway’s address, they cannot tell an approved write from a malicious one by source or function code alone. A read-only gateway, write-protected PLCs, source allow-listing, function-code filtering, or Modbus/TCP Security can each break the chain. The risk is conditional, not automatic.

One more point for incident response: a web shell stored in a persisted configuration partition may survive a firmware upgrade, depending on the product. A closed change ticket does not prove a device is clean.

That is also why CVSS is the wrong sorting key here. Both CVEs score 9.2 whether the device is a redundant operator display or the sole gateway into a high-pressure unit. The score describes the vulnerability. Only the process context describes the risk.

Why this cannot be fixed overnight

In IT, the response is inventory, patch, restart, verify. In OT, each step meets a constraint:

• Patching depends on the vendor and may include rebuilding firmware and validating it against the application, and in some sectors re-certifying it. That takes months. For end-of-life products, it may never happen.
• Restarting a controller, protocol gateway or HMI during operation is rarely an option. Change windows typically follow yearly turnarounds and planned outages.
• Replacing hardware means procurement, capital approval, and commissioning: this is a multi-year project, not an incident response.

NIST SP 800-82 Rev. 3 frames OT security as improving protection while respecting performance, reliability, and safety requirements. [12] It is the right lens for a patch decision.

The mitigation trap

PHP’s interim measures are vulnerability-specific, and neither is a fix. For CVE-2026-109618, the primary interim measure is to remove the per-request memory limit (memory_limit=-1), enforced administratively with all workers restarted. That is the opposite of “tighten memory limits”. For CVE-2026-109619, PHP says there is no complete generic configuration mitigation. Disabling session upload progress at server level, before request parsing, blocks one confirmed path only. [1][2] NCSC-NL warns that such measures do not remove the vulnerability and that exploitation attempts can still cause denial of service. [11]

On a vendor appliance, these are untested changes to a certified system. Removing a memory limit, for example, could let one request exhaust a constrained device. Trial them on a spare unit and get approval from the vendor before pushing to production.

Government guidance for systems that cannot be updated is to isolate them. NCSC-NL advises that internet-facing PHP applications be isolated, [9] and reports of CISA guidance go further, saying unpatchable systems should be taken offline. [3] In OT, taking a device offline is itself an operational decision, so the realistic equivalent is to restrict who can reach it.

The vulnerable PHP instances in many industrial estates will therefore stay vulnerable for the planning horizon. The question is not how fast the patch can be applied: it is how the risk is governed while it cannot be.

What asset owners should do, in order

Understand and map the exposure, reduce reachability, deploy monitoring across layers, and fix it the right way when a vendor fix is available. Each step reduces risk or improves evidence. Only a fixed, correctly deployed update removes the vulnerability.

Step 1: Understand the exposure and the consequence

Knowledge is key, so gathering information is the first step. SBOMs can play a part, but they only show what is installed, not what is reachable. Knowing your component and understanding its reachability will together define the exposure.

• List every asset with an HTTP or HTTPS management interface, and confirm product, firmware, and vendor support status.
• Ask each vendor for an SBOM, or a written statement on the PHP version and whether it is bundled. Record unanswered requests as open uncertainty.
• Check NCSC-NL’s inventory of products with a PHP dependency. It is incomplete by its own description, so absence is not evidence. [9]
• Use passive observation and approved discovery. Headers such as X-Powered-By can help but are often suppressed, and fragile OT devices should not be probed outside a test plan.
• Map who can reach each exposed interface.

With the asset list compiled, prioritise it by consequence: what does the device supervise, what can it write to, and what happens if it is lost or manipulated? A gateway with write authority into a safety-adjacent cell outranks an internet-facing dashboard with none.

Step 2: Reduce reachability

Restrict the sources that can reach each web interface, remove enterprise and internet exposure that is not strictly required, and route remote access through a controlled, audited path. IEC 62443-3-3 organises system security requirements under seven foundational requirements, including restricted data flow. [14] An HTTP-aware proxy or firewall in front of the interface can help, but only partly: filters target known exploit patterns, and attackers mutate payloads. [5]

Segmentation reduces opportunities for exploitation. It does not remove the vulnerability. Where a device is end of life and no fix will ever arrive, segmentation becomes the permanent control, and it should be recorded as one, along with an owner, the residual risk, and a review trigger.

Step 3: Monitor across three layers

Where no patch exists, detection is the remaining control. The following signals are investigative heuristics, not validated PHP2Shell signatures, and they need a baseline from normal operation. Tooling built to look like legitimate monitoring software passes any check on tool names, [6] so baseline by source, function, and timing.

Network layer

• Bursts of requests to a management endpoint that normally sees little traffic, and large or malformed multipart POST requests
• Requests to .php paths from sources other than the engineering workstations that normally use the interface
• New outbound connections initiated by the device, and OT protocol operations from unexpected sources

Device and host layer

• Repeated crashes, restarts, or out-of-memory errors; changes to web-root files, accounts, or scheduled tasks; configuration changes with no change record
• A web or PHP worker process spawning a shell or another unexpected child process, where process telemetry exists

These need device-level evidence. Many embedded appliances expose none of it, so use vendor diagnostics and record the blind spot instead of implying coverage.

Engineering and process layer

• Writes or downloads originating from the gateway outside a change window, and setpoint, register, or alarm-threshold changes without a record
• Logic or register maps diverging from the approved baseline, and process behaviour inconsistent with the operating mode

Network and host evidence help answer the question, “Was the device compromised?” Engineering and process evidence help answer, “Did that change anything that matters?”—which is the question operations must settle before a restart. Correlating the two turns weak signals into a stronger one, although a process anomaly alone never proves malice.

Step 4: Fix it the right way, with a vendor-qualified patch

For a vendor-managed product, the preferred remediation is a firmware or patch release that the vendor has tested and approved for your hardware and configuration. Avoid installing an upstream PHP build or distribution package on a vendor appliance unless the vendor explicitly supports it. An unsupported runtime swap can break the product, affect support, or change behaviour in ways nobody has tested. IEC TR 62443-2-3 treats patching as shared work between product suppliers and asset owners, including supplier compatibility information and asset-owner qualification before installation. [13]

• Ask the vendor for its position, the affected firmware, the fixed release, and its compatibility with your configuration. Record the date of the answer.
• Qualify before deployment on a spare unit or test bench: confirm that polling, failover, and gateway mappings still work, and agree on a rollback plan.
• Deploy in a planned window through site change management, starting where redundancy allows.
• Verify afterwards: the installed firmware and runtime, that the vulnerable component no longer serves requests, and that interim settings have been reviewed.

If exploitation is suspected, treat patching and incident response as separate activities: preserve evidence, assess integrity with the vendor, and do not assume a patched device is clean. If no vendor fix will be provided, document the risk treatment, owner, residual risk, and review triggers, and treat steps 2 and 3 as permanent controls.

The takeaway

PHP2Shell is a reminder that criticality in OT environments is not a property of a CVE score. It is a property of an asset’s role, its connectivity, and its place in the process. A vulnerability feed knows the flaw. It does not know what the affected gateway can reach or influence in your plant, and answering that takes an engineering-aware view of OT risk.

References

[1]  PHP project, security advisory GHSA-w8hw-w9fx-j79w (“RCE via OOM corruption”), 21 October 2026. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

[2]  PHP project, security advisory GHSA-6wmf-4rv5-p3rp (“RCE via stale global state”), 21 October 2026. https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

[3]  CISA, Critical Vulnerabilities in PHP Require Immediate Patching (21 October 2026, revised 26 October 2026). https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching

[4]  watchTowr, PHP2Shell FAQ (exploitation observed in its honeypot network). https://watchtowr.com/intelligence/php-cve-2026-109618-faq/

[5]  Cloudflare, protections against php2shell, 21 October 2026. https://blog.cloudflare.com/php-vulnerabilities-waf-protection/

[6]  NSA, CISA, FBI, DOE and EPA, joint advisory AA26-231A, 19 August 2026. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-231a

[7]  The Hacker News, report on the French refrigeration-controller attacks, 13 October 2026. https://thehackernews.com/2026/10/attackers-heat-french-supermarket.html

[8] CERT-FR, CERTFR-2026-ALE-012, Incident de sécurité ciblant les contrôleurs à distance des installations de réfrigération (12 October 2026, updated 13 and 16 October 2026). https://www.cert.ssi.gouv.fr/alerte/CERTFR-2026-ALE-012/ 

[9]  NCSC-NL, php2shell operational information (affected SAPIs, embedded products, CERT-EU range, isolation advice, software inventory). https://github.com/NCSC-NL/php2shell

[10]  NCSC-NL, Security Advisory NCSC-2026-0443 (Dutch), 21 October 2026. https://advisories.ncsc.nl/2026/ncsc-2026-0443.html

[11]  NCSC-NL alert (Dutch): interim measures are insufficient and can cause denial of service. https://www.ncsc.nl/alerts/ernstige-kwetsbaarheden-in-php-bereid-je-voor-op-patchen

[12]  NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023. https://csrc.nist.gov/pubs/sp/800/82/r3/final

[13]  IEC TR 62443-2-3:2015, Patch management in the IACS environment (Technical Report). https://webstore.iec.ch/en/publication/22811

[14] IEC 62443-3-3:2013, Industrial communication networks – Network and system security – Part 3-3: System security requirements and security levels. https://webstore.iec.ch/en/publication/7033 

[15]  Modat, modat.io: internet-exposure search platform (Magnify) that generated the data search used for the exposure figures, 29 October 2026. https://modat.io

Technical note: This article reflects public information available on 29 October 2026. Exploitation status, vendor advisories, and national CERT guidance are changing quickly. The exposure figures are Indurex’s point-in-time analysis of a data search generated by modat.io. The scenario is hypothetical. Validate every assumed access path and control against the actual site architecture before acting.