Jherrod ThomasThe Lion of Functional Safety™

June 20, 2026 · 14 min read

IEC 62443-4-2IEC 62061 / ISO 13849-1CWE-440 / CWE-190

When "No Fix Planned" Lands on a Safety-Capable PLC

Two denial-of-service advisories on a compact PLC would normally be a footnote — DoS is the least glamorous bug class, the one everyone files under "availability, deal with it later." But these two landed on the Mitsubishi MELSEC iQ-F FX5, and that family is not a dumb logic box. Bolt on one module and the same CPU runs a control program and a Category 4 / PL e / SIL 3 safety function. When one of the two flaws ships with the words "no fix planned," the question stops being "when do we patch?" and becomes "what reaches a safe state when this controller goes deaf?"

On June 18, 2026, CISA published two advisories against the same product family. Both are remotely triggerable, both stop the module from communicating, and one of them has no patch coming. The engineering story is not the integer overflow. It is that an availability attack against a basic control device is allowed to be a nuisance only if the safety function does not depend on that device staying alive — and most plants have never written down whether that is true.

1. The public record

ICSA-26-169-05 — CVE-2026-8805, MELSEC iQ-F Series FX5-EIP EtherNet/IP module. Per CISA and the Mitsubishi Electric PSIRT, an integer-overflow / wraparound condition (CWE-190) exists in the EtherNet/IP function of the FX5-EIP. A remote attacker who rapidly establishes a large number of TCP connections drives an inconsistency in the module's internal connection-management process, which leads to improper memory access and a denial-of-service condition. CVSS v4 base score 8.7 (High). Affected: firmware version 1.000 and earlier. Mitsubishi is releasing fixed firmware 1.001 or later — so this one is patchable.

ICSA-26-169-06 — CVE-2026-8806, MELSEC iQ-F Series FX5-ENET/IP Ethernet module. This one is an Expected-Behavior-Violation (CWE-440). A remote attacker who continuously sends a large number of communication packets to the module's Ethernet port in a short window raises the processing load to the point that the module's own internal anomaly-detection processing cannot run, and the communication function stops. CVSS v4 base score 7.5 (High). Affected: all versions. Disposition from the vendor: there are no plans to release a fixed version. The recommended mitigation is the familiar trio — firewall, VPN, and network segmentation to keep untrusted traffic off the port.

Two things make this worth more than a patch-Tuesday line item. First, this is not the family's first communication-stack DoS — CVE-2026-1874, -1875, and -1876 hit the same EtherNet/IP and Ethernet modules in March 2026 with UDP-flood DoS conditions. A repeated failure mode in the same comms stack is a design signal, not an accident. Second, and this is the part the trade coverage skipped: the MELSEC iQ-F FX5U and FX5UC CPUs accept the FX5-SF-MU4T5 safety main module, which lets a single iQ-F system perform general-purpose control and safety control to ISO 13849-1 Category 4 / PL e and IEC 61508 / IEC 62061 SIL 3. The platform under attack is, in a large installed base, a safety-capable platform.

So the real exposure is not "a PLC drops offline." It is "a controller that may be coordinating a safety function — or sharing a panel, a network segment, and an engineering workstation with one — can be made deaf from the network, on demand, with no patch on one of the two paths."

2. The standards lens

There are two standards families in play, and the whole point is that they meet here.

On the security side — IEC 62443. A DoS that halts a control device's communications is precisely what IEC 62443-4-2 (technical security requirements for components) covers under its availability family. CR 7.1 (Denial-of-service protection) requires the component to maintain essential functions when subjected to a DoS condition, and CR 7.2 (Resource management) requires it to limit the use of resources by security functions to protect against resource exhaustion. CVE-2026-8806 is a clean CR 7.2 / CR 7.1 failure: an attacker exhausts processing capacity until the device's own anomaly detection — a security function — cannot run, and the comms function falls over. The fact that the vendor will not fix it does not erase the requirement; it relocates the requirement to the system integrator under IEC 62443-3-3, specifically SR 7.1 / SR 7.2 (the same DoS-protection and resource-management requirements at the system level) and the zone-and-conduit model of IEC 62443-3-2. If the component cannot defend itself, the conduit must.

On the safety side — IEC 62061 and ISO 13849-1 (and IEC 61508 underneath). Here is the clause that matters and that nobody quotes in a CVE writeup: a safety-related control system must reach or maintain a safe state in the presence of faults, including the loss of its inputs and communications. In ISO 13849-1 terms, the safety function has a defined behavior on loss of the signal path; in IEC 62061 terms, communication errors within or to the SCS are a recognized failure mode that must be detected and must drive the function to its safe state within the process safety time. A network-induced comms halt is, from the safety function's point of view, just another communication failure — and the standard already demands a de-energize-to-safe response to it. The bug becomes a safety problem only in architectures where the safety function was quietly allowed to depend on the same attackable communication path as basic control. That dependency is the missing artifact.

The crossover, stated plainly: IEC 62443 says the device should not fall over to a DoS; IEC 62061 says it does not matter that it did, provided the safety function was independent of it and the safe state is the failure mode. A correct design satisfies both. A common design — flat network, safety logic and process logic on the same CPU and same conduit, safe state assumed rather than specified — satisfies neither and only looks fine because no one has flooded the port yet.

3. A worked snippet

TARA-style threat scenario (IEC 62443-3-2 style risk row)

| Field | Value | |---|---| | Asset | MELSEC iQ-F FX5U CPU + FX5-ENET/IP module, line-control zone; FX5-SF-MU4T5 safety module on same CPU | | Threat | Network flood of the FX5-ENET/IP Ethernet port (CVE-2026-8806, CWE-440) | | Attack vector | Adjacent network — any host able to route packets to the module's IP (compromised HMI, engineering laptop, flat OT/IT bridge) | | Vulnerability | No input-rate limiting; anomaly-detection starves under load; comms function stops. No vendor fix. | | Consequence (control) | Loss of process control / view; line stops or freezes mid-cycle | | Consequence (safety) | If the safety function shares the path or its safe state is not de-energize-on-comms-loss: hazardous motion is not commanded to safe state within process safety time | | Likelihood | High — remotely triggerable, public CVE, trivial to weaponize, no patch on this module | | Unmitigated risk | High | | Treatment | Conduit-level DoS protection + verified independent safe state (see requirements) |

Fault tree — top event: hazardous machine motion not driven to safe state

TOP: Hazardous motion persists after comms loss
        │  (AND — both must hold)
        ├── Comms path to controller halted
        │       │ (OR)
        │       ├── CVE-2026-8806 flood on FX5-ENET/IP  [no fix]
        │       ├── CVE-2026-8805 TCP exhaustion on FX5-EIP [fix: fw 1.001]
        │       └── CVE-2026-1874/-1875/-1876 UDP flood  [prior, same stack]
        │
        └── Safe state depends on the halted path
                │ (OR — any one defeats independence)
                ├── Safety function executed on same CPU as basic control
                ├── Safe state requires a network message to assert
                ├── No de-energize-to-trip on loss-of-comms timeout
                └── Safety + control share one conduit / one zone

The tree is deliberately an AND at the top. The DoS alone is an availability incident — annoying, not dangerous. It becomes a safety event only when the right branch is also true. That right branch is entirely an architecture decision, made (or skipped) long before any CVE existed.

FMEA excerpt (S / O / D with AIAG-VDA-style Action Priority)

| Item / Function | Failure mode | Effect | S | O | D | AP | Action | |---|---|---|---|---|---|---|---| | FX5-ENET/IP comms | Comms halt under packet flood (CVE-2026-8806) | Loss of control + view; safe state at risk if dependent | 9 | 6 | 4 | High | Conduit DoS filtering; independent safe state; loss-of-comms watchdog | | FX5-EIP comms | TCP-exhaustion DoS (CVE-2026-8805) | Loss of EtherNet/IP I/O exchange | 7 | 5 | 3 | High | Apply fw 1.001; rate-limit at conduit | | Safety function (FX5-SF) | Safe state not asserted on comms loss | Hazardous motion continues | 9 | 3 | 5 | High | De-energize-to-trip watchdog; STO wiring independent of Ethernet |

Severity 9 reflects the safety-capable deployment, not the base-control one. If you run the FX5 with no safety module and no hazardous actuator, drop S accordingly — but then justify in writing that no safety function rides this controller. That justification is itself a required work product.

4. Derived requirements (excerpt)

Stable IDs, traceable to the clauses above.

REQ-FX5-005 is the cheap one and the one that closes the loop. The exploit is public and trivial: flood the port. That means the failure condition is also a one-line bench test. The only reason it would first surface on a live line instead of on the bench is that nobody wrote the test.

5. What the headline really tells us

Read the security version and it is "two DoS bugs in a Mitsubishi PLC, one unpatched." Read the engineering version and it is two missing artifacts.

The first missing artifact is a conduit. IEC 62443 has said since its first edition that a component which cannot defend its own availability must be wrapped by a system that defends it for it. "No fix planned" is not the end of the obligation — it is the moment the obligation moves to the zone-and-conduit design. A flat OT network where an HMI or a wandering engineering laptop can reach a controller's Ethernet port directly is the precondition that turns a vendor's "no fix" into your outage.

The second missing artifact is a safe-state independence claim. The deepest fact in these advisories is not the CVSS score; it is that the affected family is safety-capable. IEC 62061 and ISO 13849-1 already require the safety function to ride to a safe state on loss of communications, on a path independent of the basic control system. If that claim is written down and tested, CVE-2026-8806 is an availability incident and nothing more. If it is assumed but never specified, the same packet flood is a path to hazardous motion — and the standard that would have caught it was on the shelf the whole time.

Neither fix needs a new standard. IEC 62443, IEC 62061, ISO 13849-1, and IEC 61508 already say everything that needs saying. They just do not fill themselves out. The discipline of drawing the conduit, writing the loss-of-comms safe-state requirement, and running the flood-to-safe-state test on the bench is the difference between a design-review finding this quarter and an incident report with a stopped — or worse, a not-stopped — machine attached.

— Jherrod Thomas, The Lion of Functional Safety™

Sources