Executive Summary
A crafted Common Industrial Protocol (CIP) request sent to affected Rockwell Automation Logix 5370 and 5570 controllers can trigger a denial-of-service condition that escalates to a major nonrecoverable fault (MNRF), which forces the controller out of run mode and stops process logic execution. On a controller driving physical actuators, an MNRF is not a transient glitch. It is a hard stop that requires manual intervention at the asset before production resumes.
Technical Exposure Breakdown
The defect lives in the CIP message handling path, the same protocol stack that EtherNet/IP rides on for nearly all peer-to-peer and HMI-to-controller communication in Rockwell environments. The attack vector is network-reachable: any device or process that can open a CIP session to the controller can deliver the malformed request. No authentication step gates the path, which is consistent with the historical CIP design assumption that the control network is a trusted enclave.
Affected firmware spans a wide installed base. CompactLogix 5370 at or below version 34.016, Compact GuardLogix 5370 at or below 35.015, ControlLogix 5570 at or below 35.015, and GuardLogix 5570 at 36.012 are all called out. The inclusion of the GuardLogix safety controllers is the part operators should not skim past. These are the controllers tasked with safety instrumented functions. An induced fault on a safety controller does not just stop production logic, it removes the supervisory safety layer until the device is recovered.
The condition that an MNRF creates is deliberate controller behavior. When the firmware detects an internal state it cannot recover from, it transitions to fault to avoid executing in an undefined state. That is correct engineering. The problem is that a remote attacker can force that transition on demand, converting a fail-safe design into a remotely triggerable outage.
OT Impact and Compliance Risk
Physically, an MNRF drops outputs to their configured fault state and ends scan execution. Depending on how the fault routine and output module behavior are configured, that can mean valves closing, motors de-energizing, or held last-state on outputs that were not explicitly handled. Recovery requires a connection to the controller, clearing the fault, and a manual mode transition back to run. In a continuous process or a pipeline pumping station, that recovery window is measured in lost throughput and possible product disposition issues.
For compliance, this maps cleanly onto several frameworks. Under IEC 62443, this is a failure of zone and conduit segmentation if a controller is reachable from a lower-trust zone, and it stresses the SR 3.x system integrity requirements. NERC CIP registered entities should treat any affected controller classified as a BES Cyber Asset as carrying a known DoS exposure that must be tracked under CIP-007 patch management and CIP-010 configuration controls. Pipeline operators under TSA SD-02C should map this against their required network segmentation and mitigation measures, since loss of controller availability is a covered operational concern. Water and wastewater utilities subject to AWIA 2018 should fold this into their risk and resilience assessment given the safety controller exposure.
Compensating Controls
Patching is the end state, but firmware updates on production controllers require a maintenance window and validation, so plan compensating controls for the interim. Do not run active scanners against these controllers to confirm exposure. Aggressive CIP probing can itself induce faults, so confirm versions through engineering workstation queries or asset inventory data, not network sweeps.
- Conduit enforcement. Restrict CIP and EtherNet/IP (TCP and UDP 44818, TCP 2222) to an explicit allowlist of engineering workstations, HMIs, and peer controllers. Deny all other sources at the cell or zone firewall.
- Virtual patching. Deploy an inline OT-aware IPS in front of the controller subnet to drop malformed CIP requests before they reach the stack. This is the practical mitigation when a maintenance window is weeks out.
- Suricata rule concept. Build CIP-aware signatures that alert on anomalous CIP service codes and oversized or malformed request payloads directed at controller ports, then move to drop once false-positive rates are characterized against your baseline traffic.
- CIP Security. Where the controller and clients support it, enable CIP Security to authenticate sessions and reject unauthenticated message originators.
Prioritize the GuardLogix and Compact GuardLogix units. A DoS on a safety controller is a safety availability problem, not just a production one.
BreachSpider Intel
BreachSpider tracks CVE-2026-11317 and the broader Rockwell CIP exposure surface across the known exploited vulnerability catalog and vendor advisory feeds, so monitor your affected asset inventory through BreachSpider for exploitation signals and revised firmware availability.