CISA advisory ICSA-25-352-07, corresponding to Rockwell Automation’s own bulletin SD1766, documents two fuzzing-derived vulnerabilities in the Micro800 family of nano and micro PLCs — specifically the Micro820, Micro850, and Micro870 controllers. Both flaws let a network-adjacent attacker knock a controller into a fault state using nothing more than malformed packets, no credentials or engineering software required.
Micro800-series controllers are commonly deployed as standalone machine controllers, packaging line controllers, and skid-level automation on pumps, compressors, and small process units — often at the edge of a plant network with less rigorous segmentation than a Level 2/3 DCS. That deployment pattern is what makes availability-impacting bugs in this product line disproportionately disruptive: a single fault can stop a machine, but a scripted sweep against every internet- or corporate-network-reachable Micro800 unit in a facility can take out several production lines at once.
The two CVEs
CVE-2025-13823 (IPv6 stack fault, CVSS v4.0 7.1 high) affects the Micro850 and Micro870 controllers running firmware V23.011 and earlier. When the IPv6 stack receives a sequence of malformed packets, the controller drops into a recoverable fault, reporting fault code 0xFE60 on the diagnostic display. Control execution stops until an operator manually clears the fault and restarts the program — there is no automatic recovery. Rockwell’s advisory notes the issue was found through internal fuzz testing of the IPv6 network stack rather than through active exploitation.
CVE-2025-13824 (malformed CIP handling, CVSS v4.0 8.7 high, CWE-763 release of invalid pointer or reference) is the more serious of the two and hits all three models — Micro820, Micro850, and Micro870 — across a wider firmware range: V23.011 and below, plus the older V12.013 and V14.011 branches. A malformed Common Industrial Protocol (CIP) packet triggers improper handling that drives the controller into a hard fault: the fault LED goes solid red and the unit becomes fully unresponsive, requiring a power cycle or physical intervention to restore operation. Because CIP is the native explicit-messaging protocol these controllers use for programming, HMI polling, and peer-to-peer messaging over EtherNet/IP, any device that can reach the controller’s IP address on the standard CIP port can attempt the trigger — this includes IT-side systems, misconfigured VLANs, and, in the worst case, internet-exposed units.
Why this matters for OT practitioners
Neither CVE requires authentication, and Rockwell has not published a CVSS v3.1 score, only the newer v4.0 metric — worth noting if your risk-scoring process still keys off v3.1 fields, since some ticketing and vulnerability-management pipelines silently drop CVEs lacking that score. The CVSS v4.0 vector for CVE-2025-13824 (AV:N/AC:L/AT:N/PR:N/UI:N) confirms remote, low-complexity, no-privilege exploitation with high impact to availability and no impact to confidentiality or integrity — this is a pure denial-of-service class bug, not a path to code execution or data exfiltration.
That distinction matters for triage: these are not RCE chains, but in a Purdue Level 1/2 environment where the Micro800 is directly driving actuators or conveyor logic, an unauthenticated remote crash is operationally equivalent to pulling the e-stop, minus the safety review. Facilities running these controllers on a shared IT/OT VLAN, or exposing CIP (port 44818 TCP/UDP) through a poorly scoped firewall rule for remote programming access, are the most exposed.
Mitigations
Rockwell has not indicated firmware fixes are available for all affected versions at time of publication; the advisory’s primary mitigations are compensating controls:
- Disable IPv6 on Micro850/Micro870 units where the feature is not operationally required — this fully closes the CVE-2025-13823 attack surface.
- Restrict CIP/EtherNet/IP traffic (TCP/UDP 44818, TCP 2222) to known engineering workstations and HMI hosts using access control lists on the switch or firewall in front of the controller, rather than relying on network flatness.
- Segment Micro800 controllers behind an industrial firewall or unmanaged switch boundary consistent with IEC 62443 zone/conduit design, rather than bridging them directly to a corporate-routed subnet.
- Confirm no Micro800 units are reachable from the public internet — Shodan and Censys queries for exposed EtherNet/IP endpoints remain a reliable way to catch this in under an hour.
- Monitor for repeated fault-and-recover cycles or unexpected 0xFE60 codes in maintenance logs, which can indicate probing rather than a genuine hardware issue.
CISA and Rockwell both note there is no evidence of public exploitation and no known public proof-of-concept as of publication, but the low bar to trigger — malformed packets against a well-documented, widely deployed protocol — means detection engineering should not wait for a firmware patch. Asset owners running Micro800 controllers in safety-adjacent or continuous-process roles should treat network segmentation as the primary control until Rockwell ships corrected firmware.