Rockwell Automation users running CompactLogix, ControlLogix, Compact GuardLogix, or GuardLogix controllers should move quickly to inventory and update affected firmware after CISA published advisory ICSA-26-197-06 covering three critical denial-of-service vulnerabilities that can force a controller into a major non-recoverable fault.
The immediate concern is not data theft or remote logic manipulation. It is availability: an attacker able to reach the relevant controller services may be able to submit an invalid project or file payload and leave a programmable automation controller in an MNRF state. In a plant, utility, warehouse, or other operational-technology environment, that can mean a process stops until personnel can recover the controller and restore its project.
CISA published the advisory on July 16, 2026, following Rockwell Automation’s disclosure two days earlier. Rockwell’s advisory identifies CVE-2025-12011, CVE-2025-12012, and CVE-2025-11698; the National Vulnerability Database records Rockwell’s CVSS 4.0 base score of 9.2 for the first and third issues, categorizing them as critical.
CVE-2025-12011 affects CompactLogix 5370, Compact GuardLogix 5370, ControlLogix 5570, and GuardLogix 5570 controllers running firmware version 35.015 or earlier. Rockwell says a remote user could load an invalid project that causes the device to enter a major non-recoverable fault.
That terminology matters. An ordinary operational fault can often be cleared as part of normal troubleshooting. A major non-recoverable fault is a much more serious controller state, and recovery can require an onsite response, controller remediation, and a verified re-download of the correct application. The safety variants make that recovery discipline especially important: restoring communications is not the same as validating that the machine or process can safely return to service.
The associated weakness is classified as CWE-120, the familiar buffer-copy-without-bounds-checking category. The published CVSS vector indicates network reachability, low attack complexity, no required privileges, and no user interaction. That does not mean every controller is equally exposed; it means network segmentation and engineering-workstation access controls are central to reducing practical risk while firmware rollout is planned.
Rockwell said the issue was found internally during routine testing. Neither Rockwell nor CISA lists CVE-2025-12011 as a known exploited vulnerability as of July 16. That is welcome, but it should not be read as a reason to delay: the vulnerability’s chief consequence is a disruptive controller outage, and the affected product families are widely deployed in industrial environments.
A third issue, CVE-2025-11698, is specifically tied to recovery images and boot firmware for the 5380, 5480, and 5580 families. Devices with boot firmware earlier than 1.072 may be forced into the same major non-recoverable-fault condition through invalid file data.
This split is operationally important. Updating the controller application firmware alone may not address a recovery-image exposure. Administrators should treat standard controller firmware and boot firmware as separate configuration items in their asset records and change plans.
That does not remove the need for testing. Firmware upgrades can affect I/O modules, communications devices, motion hardware, safety signatures, and HMI or historian integrations. The sensible approach is to establish the minimum corrected revision for every controller, identify the associated Studio 5000 tooling requirements, back up the running project and controller configuration, test the procedure against representative hardware, then schedule production deployment with an approved rollback and recovery plan.
Start with engineering workstations, jump hosts, remote-support appliances, VPN groups, and any shared credentials that can reach EtherNet/IP control segments. Restrict programming access to authorized workstations and named personnel; remove unnecessary routing between business IT and controller networks; and do not expose PLC management interfaces directly to the public internet.
Rockwell reiterated similar guidance in a March 2026 security notice responding to observed threat activity against its controllers: disconnect devices from the public internet and harden the installed base. For organizations that cannot patch immediately, that principle is the short-term containment strategy. Blocking untrusted traffic from reaching controllers does not correct the bug, but it can substantially reduce the number of systems able to trigger it.
Security monitoring should also distinguish between routine controller traffic and engineering activity. Project downloads, firmware transfers, controller mode changes, and unexpected write operations are high-value events. Where the environment permits, retain logs from VPN concentrators, jump servers, firewalls, remote-access gateways, and engineering endpoints long enough to investigate whether an attempted outage began with unauthorized access.
The next milestone is not merely reaching a corrected firmware number. It is demonstrating that each controller can be recovered safely if an update fails or an MNRF occurs: a known-good project backup, access to the correct recovery image, documented steps, and personnel authorized to return the process to operation. In this advisory, that recovery readiness is the difference between a vulnerability patch and an avoidable production outage.
The immediate concern is not data theft or remote logic manipulation. It is availability: an attacker able to reach the relevant controller services may be able to submit an invalid project or file payload and leave a programmable automation controller in an MNRF state. In a plant, utility, warehouse, or other operational-technology environment, that can mean a process stops until personnel can recover the controller and restore its project.
CISA published the advisory on July 16, 2026, following Rockwell Automation’s disclosure two days earlier. Rockwell’s advisory identifies CVE-2025-12011, CVE-2025-12012, and CVE-2025-11698; the National Vulnerability Database records Rockwell’s CVSS 4.0 base score of 9.2 for the first and third issues, categorizing them as critical.
A bad project can become a production outage
CVE-2025-12011 affects CompactLogix 5370, Compact GuardLogix 5370, ControlLogix 5570, and GuardLogix 5570 controllers running firmware version 35.015 or earlier. Rockwell says a remote user could load an invalid project that causes the device to enter a major non-recoverable fault.That terminology matters. An ordinary operational fault can often be cleared as part of normal troubleshooting. A major non-recoverable fault is a much more serious controller state, and recovery can require an onsite response, controller remediation, and a verified re-download of the correct application. The safety variants make that recovery discipline especially important: restoring communications is not the same as validating that the machine or process can safely return to service.
The associated weakness is classified as CWE-120, the familiar buffer-copy-without-bounds-checking category. The published CVSS vector indicates network reachability, low attack complexity, no required privileges, and no user interaction. That does not mean every controller is equally exposed; it means network segmentation and engineering-workstation access controls are central to reducing practical risk while firmware rollout is planned.
Rockwell said the issue was found internally during routine testing. Neither Rockwell nor CISA lists CVE-2025-12011 as a known exploited vulnerability as of July 16. That is welcome, but it should not be read as a reason to delay: the vulnerability’s chief consequence is a disruptive controller outage, and the affected product families are widely deployed in industrial environments.
The advisory covers newer platforms and recovery images too
The CISA notice is broader than the headline 5370/5570 project-loading flaw. CVE-2025-12012 affects CompactLogix 5380, Compact GuardLogix 5380, CompactLogix 5480, ControlLogix 5580, and GuardLogix 5580 controllers. Rockwell says a malicious user could write invalid file data to an affected controller, again potentially producing an MNRF.A third issue, CVE-2025-11698, is specifically tied to recovery images and boot firmware for the 5380, 5480, and 5580 families. Devices with boot firmware earlier than 1.072 may be forced into the same major non-recoverable-fault condition through invalid file data.
This split is operationally important. Updating the controller application firmware alone may not address a recovery-image exposure. Administrators should treat standard controller firmware and boot firmware as separate configuration items in their asset records and change plans.
The firmware targets are specific
Rockwell’s remediation guidance is versioned by family and release train:- CompactLogix 5370, Compact GuardLogix 5370, ControlLogix 5570, and GuardLogix 5570 should be updated to version 35.016, 36.011, or later.
- CompactLogix 5380, Compact GuardLogix 5380, CompactLogix 5480, ControlLogix 5580, and GuardLogix 5580 should be updated to version 34.014, 35.013, 36.011, or later.
- Recovery images for the 5380, 5480, and 5580 families should use boot firmware 1.072 or newer.
- Rockwell says systems using controller firmware 36.013, 37.011, or later already include the corrected boot firmware.
That does not remove the need for testing. Firmware upgrades can affect I/O modules, communications devices, motion hardware, safety signatures, and HMI or historian integrations. The sensible approach is to establish the minimum corrected revision for every controller, identify the associated Studio 5000 tooling requirements, back up the running project and controller configuration, test the procedure against representative hardware, then schedule production deployment with an approved rollback and recovery plan.
Engineering access is the real defensive boundary
The CVE-2025-12011 description refers to a remote user loading an invalid project. In practice, security teams should interpret that as a prompt to examine every path into the control network and every system capable of programming a Logix controller.Start with engineering workstations, jump hosts, remote-support appliances, VPN groups, and any shared credentials that can reach EtherNet/IP control segments. Restrict programming access to authorized workstations and named personnel; remove unnecessary routing between business IT and controller networks; and do not expose PLC management interfaces directly to the public internet.
Rockwell reiterated similar guidance in a March 2026 security notice responding to observed threat activity against its controllers: disconnect devices from the public internet and harden the installed base. For organizations that cannot patch immediately, that principle is the short-term containment strategy. Blocking untrusted traffic from reaching controllers does not correct the bug, but it can substantially reduce the number of systems able to trigger it.
Security monitoring should also distinguish between routine controller traffic and engineering activity. Project downloads, firmware transfers, controller mode changes, and unexpected write operations are high-value events. Where the environment permits, retain logs from VPN concentrators, jump servers, firewalls, remote-access gateways, and engineering endpoints long enough to investigate whether an attempted outage began with unauthorized access.
Treat recovery as part of the patch
For Windows administrators supporting operational technology, the practical work begins with an accurate inventory. Do not rely solely on the version of Studio 5000 installed on an engineering PC; collect controller catalog numbers, controller firmware, boot firmware where applicable, project version, network location, process criticality, and the approved maintenance window.The next milestone is not merely reaching a corrected firmware number. It is demonstrating that each controller can be recovered safely if an update fails or an MNRF occurs: a known-good project backup, access to the correct recovery image, documented steps, and personnel authorized to return the process to operation. In this advisory, that recovery readiness is the difference between a vulnerability patch and an avoidable production outage.
References
- Primary source: CISA
Published: 2026-07-16T12:00:00+00:00
- Related coverage: securityweek.com
Rockwell Automation Patches Vulnerabilities in ICS Controllers and Software - SecurityWeek
Rockwell Automation informed customers that patches are available for several vulnerabilities affecting its ICS controllers and software.www.securityweek.com
