Rockwell Logix Firmware Flaw Allows Instant Controller Crash—Patches Released

Rockwell Automation began pushing out firmware updates on July 14, 2026 for nearly its entire Logix controller line after its internal testing uncovered three separate vulnerabilities that let a remote attacker force a programmable automation controller into a major non-recoverable fault. CISA amplified the urgency two days later with advisory ICSA-26-197-06, assigning a CVSS 4.0 base score of 9.2 to the most severe entries and warning that an unauthenticated, low-complexity network attack could halt an industrial process until on-site personnel physically recover the device.

The Flaws: What Rockwell and CISA Disclosed

The advisory bundles three CVEs that share a common consequence but target different product families:

• CVE-2025-12011 affects the older 5370 and 5570 series: CompactLogix 5370, Compact GuardLogix 5370, ControlLogix 5570, and GuardLogix 5570 controllers running firmware version 35.015 or earlier. A remote user can load an invalid project file that triggers a classic buffer copy without bounds check (CWE-120), pushing the unit into a major non-recoverable fault (MNRF).
• CVE-2025-12012 moves the risk to newer 5380, 5480, and 5580 families: CompactLogix 5380, Compact GuardLogix 5380, CompactLogix 5480, ControlLogix 5580, and GuardLogix 5580. Here, invalid file data written to the controller can produce the same unrecoverable state.
• CVE-2025-11698 zeroes in on recovery images and boot firmware for the 5380, 5480, and 5580 lines. Devices with boot firmware older than 1.072 may be kicked into an MNRF by specially crafted file data, meaning that even if the main application firmware is patched, a lingering outdated recovery image still creates a pathway to a crippling outage.

Rockwell told CISA it found the issues during routine testing. As of July 16, none of the three CVEs had been listed as known exploited in the wild, but the mechanics are straightforward: reach the right service, feed it a malformed payload, and watch the controller lock up.

Which Firmware Versions You Need—Right Now

Remediation is versioned by family and release train, so production lines deliberately pinned to older Studio 5000 Logix Designer releases don’t necessarily have to jump to the absolute latest. Here is what you need to target, according to Rockwell’s published guidance:

The split matters operationally. Updating the controller’s application firmware alone won’t close the recovery-image exposure. Administrators must treat boot firmware as a separate configuration item in asset records and change plans.

What’s at Stake for Your Facility

A major non-recoverable fault is not a nuisance alarm. An ordinary operational fault can often be cleared from an engineering workstation or HMI. An MNRF requires a local responder to physically interact with the controller—recover it, download the project again, and verify that the machine or process can safely return to service. In safety-rated GuardLogix applications, that verification cycle is especially long because restoring communications doesn’t by itself validate that the safety logic can protect people again.

For a plant, warehouse, utility, or any OT environment running these controllers, one intentionally crafted MNRF can halt a production line, disable a process, or gate a critical utility until a technician arrives with a known-good project backup, the correct recovery image, and the authority to restart. If the attacker can reach multiple controllers simultaneously, the outage scales.

The CVSS vector tells the story: network reachable, low attack complexity, no privileges, no user interaction. That doesn’t mean every controller is automatically a sitting duck. It means the real-world exposure is shaped almost entirely by network architecture. A controller sitting on a flat network with no segmentation, accessible from a corporate VLAN or even the internet, is a single packet away from an MNRF. One sitting behind a properly configured industrial DMZ with only authorized engineering jump hosts is much harder to reach.

The Broader Context: ICS Threats Keep Rising

This isn’t the first time Rockwell has had to push urgent hardening guidance. In March 2026, the company issued an unusual notice after detecting active threat activity against its controllers. That notice’s first recommendation was simple and stayed the same: disconnect devices from the public internet and harden the installed base. The new CVEs add precision to that demand—remote attackers don’t need to exfiltrate data or rewrite logic if they can simply silence the controller.

The vulnerability class itself, a buffer copy without bounds checking, is old but stubborn. It keeps surfacing in real-time operating systems and embedded devices because validation checks add code cycles that can impact determinism, a tradeoff that industrial firmware often avoids. Rockwell’s internal discovery during routine testing suggests the company is investing more heavily in fuzzing and code review, but the sheer number of models covered this week shows how deep the affected code runs across product generations.

For Windows administrators who manage the engineering workstations and servers that sit between corporate IT and the factory floor, this advisory is a prompt to revisit the paths that exist from the domain-joined world into the control network. Jump hosts, VPN groups, remote-support appliances, and shared credentials that can reach EtherNet/IP segments all become a perimeter that matters as much as the controller firmware itself.

Your Action Plan: From Inventory to Recovery

If your first instinct is to rush and apply patches, take a breath. A botched firmware upgrade can cause exactly the same MNRF you’re trying to prevent. Instead, work through these steps in order:

1. Inventory every affected controller—catalog number, current firmware, boot firmware where applicable, project version, network location, process criticality, and approved maintenance window. Don’t rely on the Studio 5000 version installed on the engineering PC; pull the actual controller properties.
2. Assess reachability—trace every path a potential attacker could take to those controllers. Map engineering workstations, remote-support appliances, VPN connections, dual-homed servers, and any IT-managed systems that talk EtherNet/IP. Block unwanted access at the firewall or router while planning firmware updates.
3. Choose your target revision using the table above, matching the branch your facility has validated. If you’re on a major release like 34 or 35, stay within that branch unless you’re prepared to re-validate the entire application with a new Studio 5000 version.
4. Back up everything before touching any controller. A full controller images, project files, and a copy of the currently running firmware should be stored offline and verified.
5. Test the upgrade on representative hardware if at all possible. Watch for compatibility issues with I/O modules, motion devices, HMI terminals, historians, and safety signatures.
6. Schedule the production rollout with a documented rollback and recovery procedure. Have the recovery image for that exact controller revision ready, and ensure personnel know how to use it.
7. After the update, verify that the controller is running the correct firmware, the project downloaded cleanly, and the safety or process functions behave normally.

While firmware work is underway, use network segmentation as the short-term containment strategy. Untrusted traffic should not be able to reach these controllers at all. Firewalls, access control lists, and DMZ architectures are valid compensating controls while patches roll out.

Security monitoring should also be tuned to catch engineering activity that could signal misuse. Project downloads, firmware transfers, controller mode changes, and unexpected write operations are high-value events. Where feasible, retain logs from VPN concentrators, jump servers, and engineering endpoints long enough to investigate if an attempted outage began with unauthorized access.

The Road Ahead

Patches are available today, and no active exploitation has been reported—yet. That window won’t stay open forever. As the OT threat landscape continues to professionalize, vulnerabilities with the kind of immediate disruptive potential seen here have a habit of being weaponized quickly. Facilities that treat this advisory as an inventory and architecture exercise, not just a firmware sprint, will be in a much stronger position when the next advisory lands.

For Windows administrators who find themselves on call for OT incidents, the single most durable takeaway from CVE-2025-12011 and its companions is this: A reliable backup, a tested recovery procedure, and tight control over who can reach the controller are what turn a critical vulnerability from a plant outage into a brief maintenance window.