Rockwell Automation has published an urgent advisory after internal fuzz-testing uncovered two controller defects that can crash or fault Micro800-series devices: an IPv6 stack fault that produces recoverable controller faults (CVE-2025-13823) and a malformed-CIP handling flaw that can drive hard faults (CVE-2025-13824). The issues affect multiple Micro820, Micro850 and Micro870 hardware families and were disclosed by Rockwell on December 9, 2025; national tracking entries show follow-on CVE/NVD entries in mid-December. Administrators must treat these as immediate availability and operational-risk issues — apply vendor-corrected firmware where available, follow Rockwell’s mitigations (including disabling IPv6 when it isn’t required), and harden networks and operational processes until remediation is completed.
Rockwell’s security advisory (SD1766) describes two fuzzing-discovered defects across the Micro800 product family. The first, cataloged as CVE-2025-13823, is rooted in the IPv6 stack on Micro850 and Micro870 controllers and manifests when devices receive multiple malformed IPv6 packets; affected controllers enter a recoverable fault with fault code 0xFE60 and must have that fault cleared to resume normal operation. The second, CVE-2025-13824, stems from improper handling of malformed CIP packets and can cause a hard fault with a solid red Fault LED; after a power cycle the device will report a recoverable fault condition (fault code 0xF019) that requires clearing to recover. Rockwell’s advisory is explicit that these problems were found during internal testing and that corrected firmware releases have been produced for affected hardware. Why this matters: Micro800 controllers are widely used in standalone and small-machine automation, and forms part of many Windows-managed engineering and OT toolchains. Availability failures — even recoverable ones — can halt production, generate safety or quality exceptions, and trigger costly emergency responses. The practical attack surface includes adjacent networks and any channel that can deliver malformed network traffic to controller interfaces. That combination makes these issues operationally important for ICS/OT teams and Windows-based engineering workstations that push configurations or monitor controllers. Broader Rockwell advisory context and the pattern of repeated vendor patches for ICS products underline the systemic nature of patch-and-hardening cycles in industrial environments.
Rockwell’s PSIRT is the escalation path for installation-specific questions (contact listed in the advisory), and the Rockwell advisory and national CVE entries should be used as authoritative references when updating asset inventories, vulnerability trackers, and change-control tickets. Prioritize devices that sit on production-critical lines or are reachable from contractor/third-party zones and schedule remediation windows that include rollback and validation steps. The combination of accessible fault indicators (LEDs and fault codes) and vendor-corrected firmware makes this a manageable risk — provided teams act swiftly and methodically.
Source: CISA Rockwell Automation Micro820, Micro850, Micro870 | CISA
Background / Overview
Rockwell’s security advisory (SD1766) describes two fuzzing-discovered defects across the Micro800 product family. The first, cataloged as CVE-2025-13823, is rooted in the IPv6 stack on Micro850 and Micro870 controllers and manifests when devices receive multiple malformed IPv6 packets; affected controllers enter a recoverable fault with fault code 0xFE60 and must have that fault cleared to resume normal operation. The second, CVE-2025-13824, stems from improper handling of malformed CIP packets and can cause a hard fault with a solid red Fault LED; after a power cycle the device will report a recoverable fault condition (fault code 0xF019) that requires clearing to recover. Rockwell’s advisory is explicit that these problems were found during internal testing and that corrected firmware releases have been produced for affected hardware. Why this matters: Micro800 controllers are widely used in standalone and small-machine automation, and forms part of many Windows-managed engineering and OT toolchains. Availability failures — even recoverable ones — can halt production, generate safety or quality exceptions, and trigger costly emergency responses. The practical attack surface includes adjacent networks and any channel that can deliver malformed network traffic to controller interfaces. That combination makes these issues operationally important for ICS/OT teams and Windows-based engineering workstations that push configurations or monitor controllers. Broader Rockwell advisory context and the pattern of repeated vendor patches for ICS products underline the systemic nature of patch-and-hardening cycles in industrial environments. A technical look: what the CVEs actually do
CVE-2025-13823 — IPv6 stack recoverable fault (Micro850 / Micro870)
- Symptom: Processing multiple malformed IPv6 packets causes the controller’s IPv6 stack to reach an error state resulting in a recoverable fault and fault code 0xFE60.
- Impact: Availability impact only (controller faults); Rockwell rates the CVSS severity as high (CVSS v4: 7.1 / CVSS v3.1: 6.5). The classification maps to CWE-1395 (dependency on a vulnerable third-party component), implicating a third-party network-stack component used inside the firmware.
- Attack vector: Adjacent network — an attacker on the local network segment or any path that can deliver IPv6 packets to the controller could cause the fault. There is no indication that this produces arbitrary code execution; the observable condition is a controller fault that requires a manual/administrative recovery step.
CVE-2025-13824 — Malformed CIP packet handling (Micro820 / Micro850 / Micro870)
- Symptom: Improper handling of malformed CIP packets can create a hard fault (solid red Fault LED). After power-cycling, the controller will boot into a recoverable fault state that reports fault code 0xF019; clearing the fault restores service.
- Impact: Higher severity on Rockwell’s scale (CVSS v4: 8.7 / CVSS v3.1: 7.5) because malformed CIP traffic can render the controller unresponsive until power-cycled and then require operator intervention. This affects device availability and could force manual recovery actions on production equipment.
- Attack vector: Similarly adjacent / network-proximal; CIP is the Common Industrial Protocol used widely in Rockwell devices. The advisory calls out this as a handling defect triggered by malformed CIP frames.
Affected hardware and firmware versions — precise guidance
Rockwell’s SD1766 advisory lists affected product families and the firmware versions where the defects were observed and corrected. Key remediation targets and migration guidance published by Rockwell include:- Micro850 / Micro870 (L50E / L70E):
- Affected: firmware V23.011
- Corrected in: V23.012 (upgrade target).
- Micro850 / Micro870 (LC50 / LC70):
- Affected: V12.013 and lower
- Rockwell’s guidance: migrate to the newer L50E/L70E controllers (L50E/L70E V23.012) rather than patch older hardware series.
- Micro820 (LC20):
- Affected: V14.011 and lower
- Rockwell’s guidance: migrate to the new Micro820 L20E family (V23.011 or later); older LC20 hardware lines should be migrated rather than relied on for long-term support.
Immediate mitigations and vendor solutions
Rockwell’s published mitigations and recommendations are practical and should be followed as an operational priority:- Apply Rockwell-corrected firmware where it exists:
- Update Micro850/870 L50E/L70E devices to V23.012 and newer.
- Where firmware updates aren’t available for legacy models, follow Rockwell’s migration guidance to newer controllers (e.g., move LC50/LC70 and LC20 deployments to the new L50E/L70E / L20E product lines).
- For CVE-2025-13823 (IPv6 stack) specifically, Rockwell advises: disable IPv6 functionality if you do not require it. Disabling IPv6 on affected devices or at the network access layer reduces the attack surface and immediately prevents the malformed IPv6 vector from reaching controllers.
- If you are unable to upgrade or migrate immediately, follow Rockwell’s security best practices: network segmentation, ACLs, firewalling, and limited adjacent-network exposure for ICS devices. Do not expose controller management interfaces to untrusted networks, and ensure engineering workstations are layered behind jump hosts and segmentation.
Risk assessment: impact to Windows/OT environments
- Availability-first impact profile
- Both CVEs primarily affect availability: controller faults and hard faults that disrupt automation. While these don’t appear to allow remote code execution or data theft, the operational consequences can be severe for continuous processes or safety-critical lines.
- Adjacent-network threat model
- The vector is adjacent network for CVE-2025-13823; CIP malformed packets likewise require network access to the controller. Attackers with access to the same network segment (or a reachable routed path) could deliberately send malformed frames to trigger faults. This elevates the need to control lateral movement and contractor access inside plant networks.
- Engineering workstation exposure
- Windows-based engineering workstations commonly interface with PLCs for programming, updates, and diagnostics. If those workstations can reach vulnerable controllers without proper segmentation and hardening, a compromised workstation or malicious file could be a conduit for malformed traffic. Historical Rockwell advisories and community write-ups have repeatedly shown that engineering hosts are high-value targets and a common pivot point in ICS intrusions.
- Operational recovery complexity
- Even where faults are “recoverable,” recovery often requires local operator intervention (clear the fault), and hard faults may require a power cycle. In many environments this means planned downtime, safety checks, and possibly manual reconfiguration — all expensive and disruptive.
Practical, prioritized remediation checklist (operational playbook)
Follow this sequenced plan to reduce risk quickly and then remediate permanently:- Inventory & Triage (first 0–24 hours)
- Enumerate all Micro820, Micro850 and Micro870 devices and collect firmware versions.
- Prioritize devices on production-critical lines, safety systems, and those exposed to adjacent networks.
- Short-term containment (0–48 hours)
- If IPv6 is not required, disable IPv6 on the affected controllers or block IPv6 at the network edge / VLAN boundary. (Rockwell recommends disabling IPv6 as a mitigation for CVE-2025-13823.
- Apply immediate ACLs or firewall rules to block unknown or untrusted hosts from sending IPv6 or CIP traffic to controller interfaces.
- Isolate heavily used engineering workstations from general corporate networks — require jump hosts or controlled transfer points for project/firmware files.
- Patch / Migration (72 hours to scheduled maintenance)
- Validate and schedule deployment of Rockwell-corrected firmware:
- L50E/L70E → V23.012 or later.
- Migrate LC50/LC70 and LC20 models to recommended L50E/L70E or L20E families when firmware updates are not available.
- Test updates in a staging environment before production rollout.
- Recovery playbook & monitoring
- Document recovery steps for the two fault conditions (clear fault 0xFE60; handle hard-fault pattern for 0xF019 and required power cycle).
- Configure monitoring/alerting to detect controller fault codes and LED states; integrate events into your SIEM or OT monitoring console.
- Post-incident validation & hardening
- After applying firmware or migration, run directed fuzz/validation tests in a lab to confirm that malformed IPv6/CIP traffic no longer triggers the faults.
- Harden engineering processes: require signed firmware, use checksums for transferred project files, block untrusted file opening on engineering hosts.
- Communication & change control
- Schedule maintenance windows with operations, safety and management stakeholders. Test rollback and vendor support contacts ready before broad rollout.
- Maintain a contact with Rockwell’s PSIRT (rasecure@ra.rockwell.com) for clarifications or emergency support.
Detection and incident response: what to look for
- Controller fault codes: watch for 0xFE60 (IPv6 stack recoverable fault) and 0xF019 (CIP malformed packet hard-fault recovery). Log and alert on these occurrences so plant responders can act quickly.
- LED state changes: a solid red Fault LED followed by an MS LED flashing pattern after a cycle is a strong indicator of the CIP packet issue. Capture timestamps and network logs for any such events.
- Unusual IPv6 traffic: set IDS/packet-capture rules to flag malformed IPv6 packets (abnormally formed headers, repeated fragmentation anomalies, strange extension header sequences) directed at controller addresses. Because the vendor’s testing found the issue via fuzzing, detection should focus on malformed or out-of-spec packets rather than specific payload patterns alone.
- Correlate events from engineering workstations: sudden controller faults correlated with recent programming sessions, file transfers or remote support windows can indicate misconfiguration or misuse.
Why firmware migration is sometimes the only safe long-term option
Rockwell’s advisory makes a clear recommendation: for some older LC-series controllers, migration to new L-series controllers (L50E/L70E or L20E) is the advised remediation path rather than trying to force a long-term patch on unsupported firmware lines. That guidance reflects a practical reality in ICS: older platforms may have third-party component dependencies or architectural constraints that make deep fixes impractical. Migration is a longer project — requiring hardware procurement, validation, and commissioning — but it pays off by restoring maintainable security posture and vendor support. Plan for staged migrations as part of the asset lifecycle program.Operational and security best practices (beyond the immediate advisory)
- Network segmentation: isolate OT subnets from corporate networks and restrict any inter-subnet routing required for management via jump servers and tightly controlled firewall rules.
- Principle of least connectivity: only allow services and ports that are essential for operation. If IPv6 is not needed in the OT environment, ban it at the edge and in controller configs.
- Harden engineering workstations: restrict their internet access, apply application control, and avoid installing general-purpose email clients or browsers on machines that perform PLC engineering tasks.
- Controlled firmware processes: require cryptographic signatures or checksums where possible, use verified vendor download portals, and validate firmware before production deployment.
- Exercise recovery runbooks regularly: simulate fault clearance, power-cycle recovery and failover to ensure teams can respond to real faults without prolonged downtime.
- Vendor engagement: subscribe to Rockwell product security alerts, validate advisory dates and corrected firmware version strings before deployment, and maintain a support escalation path.
What defenders should not assume
- Do not assume “no public exploitation” means “no risk.” Rockwell and NVD record no known exploited cases at disclosure; however, adversaries routinely adapt public disclosures into targeted outages. The presence of a high-severity availability defect in controllers that sit on plant networks is inherently risky.
- Do not assume firmware-only fixes fully eliminate operational risk. Even corrected versions may change behavior that operators must test for compatibility with existing I/O, safety interlocks and diagnostics. Staging and testing are essential.
- Do not rely solely on perimeter defenses. Attacks that originate inside the plant (malicious insiders, compromised contractor laptops) can still reach adjacent networks; internal segmentation, strict access controls, and host hardening matter.
Conclusions and recommended next steps (executive summary)
- Treat Rockwell SD1766 (Micro820, Micro850, Micro870) as an operational priority: identify impacted devices immediately and schedule remediation. Rockwell published the advisory on December 9, 2025, and NVD entries appeared in mid-December; do not delay.
- Implement short-term mitigations now:
- Disable IPv6 on controllers and block IPv6 at the OT network edge if IPv6 is not required.
- Block untrusted hosts from sending CIP and IPv6 traffic to controllers using ACLs and firewalls.
- Monitor for fault codes 0xFE60 and 0xF019 and alert operations immediately when those codes occur.
- Apply corrected firmware or migrate to recommended hardware:
- L50E/L70E → V23.012 (and later) for fixes.
- Migrate older LC-series devices to the new L-series where firmware patches are not supported.
- Harden engineering workflows and enforce strict change control for firmware and project files. Historical Rockwell advisories and ICS community guidance show engineering workstations are high-value targets — treat them accordingly.
Rockwell’s PSIRT is the escalation path for installation-specific questions (contact listed in the advisory), and the Rockwell advisory and national CVE entries should be used as authoritative references when updating asset inventories, vulnerability trackers, and change-control tickets. Prioritize devices that sit on production-critical lines or are reachable from contractor/third-party zones and schedule remediation windows that include rollback and validation steps. The combination of accessible fault indicators (LEDs and fault codes) and vendor-corrected firmware makes this a manageable risk — provided teams act swiftly and methodically.
Source: CISA Rockwell Automation Micro820, Micro850, Micro870 | CISA
