Jherrod ThomasThe Lion of Functional Safety™

September 7, 2026 · 14 min read

IEC 61511-1 §8.2.4 / §11.2.10IEC 62443-3-3 SR 5.1 / 7.1 / 7.2CVE-2026-9637 / CWE-119

When the Safe State Became the Payoff: The Rockwell Logix CIP Fault Advisory (ICSA-26-244-03) Through an IEC 61511 and IEC 62443-3-3 Lens

A GuardLogix 5580 that receives one malformed CIP message goes to a major nonrecoverable fault. Outputs de-energize. The safety instrumented function does exactly what its safety manual promises. That is the whole problem. The controller is behaving correctly and the plant is down, and the only thing an attacker needed to produce that outcome was a route to TCP port 44818 and no credentials at all.

Most weeks the ICS advisory feed is a list of things that could go wrong. This one is a list of things that go right — right into a trip. CISA published four Rockwell Automation advisories across September 1 and September 3, 2026, and the interesting one is not the critical-scored remote code execution people expected. It is an availability-only denial of service against the platform that runs a large fraction of the world's safety instrumented functions, self-reported by the vendor, with no workaround.

Availability-only findings get triaged down in IT. In a functional safety context that instinct is backwards, and this advisory is a clean worked example of why.

1. The public record

On September 1, 2026, CISA published ICSA-26-244-03, "Rockwell Automation Logix Platform," disclosing CVE-2026-9637. The defect is classified CWE-119, improper restriction of operations within the bounds of a memory buffer: the affected firmware does not correctly validate input length while processing Common Industrial Protocol messages. It carries a CVSS v3.1 base score of 7.5 and a CVSS v4.0 base score of 8.7, and it was self-reported to CISA by Rockwell Automation (1898 and Co. advisory brief, September 3, 2026; CISA ICSA-26-244-03).

The affected set is the part that matters:

| Controller family | Role | Affected firmware | |---|---|---| | ControlLogix 5580 | Process / discrete control | V33 and earlier; V34.011–V34.014; V35.011–V35.013; V36.011–V36.012 | | CompactLogix 5380 | Machine control | same | | GuardLogix 5580 | SIL 3 / PL e safety controller | same | | Compact GuardLogix 5380 | SIL 3 / PL e safety controller | same |

Corrected firmware is V34.015, V35.014, V36.013 and V37.011, with the target release determined by the family already installed. There is no workaround. Exploitation requires only network reachability to the controller's CIP service, exposed over EtherNet/IP on TCP and UDP 44818, and UDP 2222 for implicit I/O messaging. CIP explicit messaging on these controllers accepts unauthenticated requests by default in most deployed configurations, so no credentials, no engineering-workstation foothold and no operator interaction are required. A single malformed message places the controller into a major nonrecoverable fault (MNRF): the controller halts, outputs go to their configured fault state, and it stays there until somebody physically power cycles it.

The 1898 and Co. brief puts the operational consequence plainly: where GuardLogix and Compact GuardLogix are in scope, "the induced fault will drive the safety instrumented function to its de-energized state, producing an unplanned shutdown that carries its own startup risk, equipment stress, and process disruption."

Two days either side of that, the same platform's tooling took its own hits:

Rockwell also patched a privilege escalation in the Redundancy Module Configuration Tool, an elevated file-access flaw in FactoryTalk Activation Manager, and RCE plus DoS in FactoryTalk Historian, per SecurityWeek's roundup of the batch — which also notes that Rockwell's own advisory SD1792 flags CVE-2026-9637 as exploited in the document header while stating it is not exploited everywhere else, "likely an error" (SecurityWeek, September 2, 2026). CISA reports no known public exploitation.

So: the safety controller can be tripped remotely, the comms driver that talks to it can be crashed remotely, and the tool that writes firmware into it ships with a world-writable install directory. That is not four unrelated bugs. That is one architecture.

2. The standards lens

IEC 61508-2 gives you credit for the safe state. It does not ask who can command it.

A GuardLogix going to MNRF and de-energizing its outputs is the textbook de-energize-to-trip behaviour that the safety manual promises and that the SIL 3 claim is built on. Every functional safety argument I have ever written for a de-energize-to-trip architecture treats "controller faults, outputs drop, process goes safe" as the good branch of the fault tree. IEC 61508-2 §7.4.3 and the diagnostic architecture behind it exist to make that branch reliable.

What none of that machinery asks is whether an unauthenticated party on a routed network can select that branch on demand. That question lives in a different standard, and in most projects, a different binder.

IEC 61511-1:2016 §8.2.4 is the clause that was supposed to catch this. It requires a security risk assessment of the SIS — not the plant network generally, the SIS — identifying the devices in scope, the threats, the vulnerabilities, the consequences, and the countermeasures. A properly executed §8.2.4 assessment on a GuardLogix-based SIS asks exactly one question that would have surfaced this exposure years before CVE-2026-9637 existed: from which network zones is the CIP service on this safety controller reachable, and what is the consequence of an arbitrary party reaching it? The answer, in most plants, is "the whole Level 2 zone" and "a spurious trip."

IEC 61511-1 §11.2.10 is the second one. The SIS design must consider spurious trips, because a spurious trip is not a free lunch: it stresses equipment, it forces a startup transient that is often the most hazardous state the process ever occupies, and — the part nobody writes down — it teaches operators that the SIS is the thing that keeps costing them a shift. Bypass culture is grown, not born. An attacker who can induce spurious trips at will is not producing a nuisance; they are producing a slow attack on the integrity of the safety layer itself.

IEC 62443-3-3 is where the system-level controls live, and this advisory implicates three specific SRs:

IEC 62443-4-1 SVV-3 — robustness and fuzz testing of every externally reachable interface — is the process requirement that should have found a CIP length-validation defect before release. This is not an exotic memory-safety bug requiring a novel technique. It is the first thing a protocol fuzzer finds.

And IEC 61508-3 §7.4.4, offline support tools, is the clause hanging over ControlFLASH. A firmware flashing utility for a SIL 3 controller is a T3 tool by any honest reading: its output is the executable that runs the safety function. §7.4.4.4 wants a T3 tool to have a specification or manual, evidence of fitness for purpose, and — critically — controls on the tool's integrity. "Everyone has write access to the install directory" is not a defensible T3 justification, and I have never seen a safety case that named ControlFLASH in its tool classification list at all.

3. A worked snippet

Here is the fault tree I would put in front of a process safety review, drawn for the top event that actually matters to the operator.

TOP: Unplanned process shutdown from SIF de-energization,
     with SIF unavailable until manual intervention
                        |
                       OR
      +-----------------+------------------+
      |                 |                  |
  [G1] Genuine      [G2] Random HW     [G3] INDUCED FAULT
  process demand    fault -> safe      via CIP interface
  (credited, in     state (credited,   (NOT in the LOPA,
   the LOPA)         in the PFDavg)     NOT in the PFDavg)
                                             |
                                            AND
                        +--------------------+--------------------+
                        |                                         |
                 [B1] Attacker has                        [B2] Controller
                 IP reachability to                       firmware in
                 TCP/UDP 44818 or                         affected range
                 UDP 2222                                 (V33 / V34.011-014
                        |                                  / V35.011-013
                       OR                                  / V36.011-012)
             +----------+----------+
             |                     |
      [B1a] Flat or         [B1b] Conduit exists
      permissive L2/L3      but rule set never
      routing to SIS zone   verified by test

Note what G3 does to the numbers. PFDavg is a claim about random hardware failure on demand. It says nothing about an attacker choosing the trip time. So the SIL claim survives intact and is simultaneously irrelevant — the metric that degrades is the one nobody put a target on.

The IEC 62443-3-2 risk row, filled the way I would actually fill it:

| Field | Value | |---|---| | Zone | SIS zone (GuardLogix 5580, Compact GuardLogix 5380) | | Conduit | EtherNet/IP CIP, TCP/UDP 44818, UDP 2222, from BPCS zone | | Threat | Unauthenticated malformed CIP explicit message | | Vulnerability | CVE-2026-9637, CWE-119, length validation absent | | Unmitigated likelihood | High — no credentials, no user interaction, network vector | | Consequence | Spurious trip of all SIFs on the controller; MNRF until on-site power cycle | | Unmitigated risk | Intolerable | | Countermeasure 1 | Firmware to V34.015 / V35.014 / V36.013 / V37.011 | | Countermeasure 2 | Conduit restricted to enumerated engineering sources, verified by test | | Countermeasure 3 | CIP anomaly detection correlated with controller mode transitions | | Residual risk | Tolerable with 1 + 2; Countermeasure 2 alone is Undesirable | | Target SL-T | SL 2 (conduit), driven by SR 5.1, SR 7.1, SR 7.2 |

4. Derived requirements (excerpt)

Stable IDs, written the way they would enter a requirements tool rather than a slide.

CSR-LOGIX-001 — SIS conduit source restriction. CIP explicit messaging to any GuardLogix 5580 or Compact GuardLogix 5380 in the SIS zone shall be permitted only from an enumerated allow-list of engineering workstation addresses. All other CIP traffic on TCP/UDP 44818 and UDP 2222 crossing the BPCS-to-SIS conduit shall be denied by default. Verification: active traffic test from at least three non-allow-listed sources in each adjacent zone; firewall configuration review alone is not acceptable evidence. (IEC 62443-3-3 SR 5.1)

CSR-LOGIX-002 — Firmware baseline and applicability determination. Every ControlLogix 5580, CompactLogix 5380, GuardLogix 5580 and Compact GuardLogix 5380 in the asset inventory shall carry a recorded firmware revision and an applicability determination of Affected / Not Affected / Unknown against CVE-2026-9637. Any controller whose revision cannot be confirmed shall be classified Affected. Target: 100 percent of SIS-zone controllers determined within 35 calendar days of advisory publication, consistent with the NERC CIP-007-6 R2 patch evaluation window where applicable.

CSR-LOGIX-003 — Safety application re-validation on firmware change. Firmware upgrade of a GuardLogix or Compact GuardLogix controller shall trigger re-validation of the safety application per the site functional safety management plan before the controller is returned to service, including a proof test of every SIF executing on that controller. Rationale: the upgrade is a modification under IEC 61511-1 §17, not a patch.

CSR-LOGIX-004 — Induced-versus-genuine fault discrimination. Controller transition to MNRF shall generate an alarm that is correlated, within the same investigation record, against network telemetry for malformed or oversized CIP messages and against CIP explicit messaging from non-sanctioned sources, retained for a minimum of 90 days. Rationale: a fault from a failing power supply and a fault from a crafted message are indistinguishable in the controller log alone. (IEC 62443-3-3 SR 6.1)

CSR-LOGIX-005 — Offline support tool classification. ControlFLASH, RSLinx Classic and the Redundancy Module Configuration Tool shall be entered in the project tool classification register as T3 offline support tools per IEC 61508-3 §7.4.4, with recorded version, installation-directory ACL, and evidence that no non-administrative principal holds write permission on the install path. Verification: ACL export per engineering workstation at each safety-lifecycle gate.

5. What the headline really tells us

The headline says a denial of service was patched in some PLCs. The missing artifact says something narrower and more uncomfortable.

Somewhere in most of the plants affected by this advisory there is a safety requirements specification that names a safe state, a safety manual that certifies the controller will reach it, a LOPA that credits the SIF with a risk reduction factor, and a PFDavg calculation that survives audit. What there is not, in the same binder, is a single line stating who is permitted to command the safe state, and by what path. IEC 61511-1 §8.2.4 has required a security risk assessment of the SIS since 2016 — a decade this year — and in the assessments I have reviewed, that clause is most often satisfied by a reference to the corporate OT security policy rather than by an enumeration of the SIS's own conduits.

CVE-2026-9637 did not create that gap. It just made it cheap to demonstrate. The defect will be gone in a firmware cycle. The missing document will still be missing.

If you take one action from this: open your SIS security risk assessment, find the sentence that enumerates the conduits into the safety zone, and check whether anyone ever tested the rule set instead of reading it. If there is no such sentence, the advisory is not the finding. The binder is.

Sources

— Jherrod Thomas, The Lion of Functional Safety™