Rockwell Micro800 PLCs: High-Severity Flaws, CISA Advisory 25-226-25

Rockwell Automation’s Micro800 line of programmable logic controllers (PLCs) has been the subject of a high-severity U.S. Cybersecurity and Infrastructure Security Agency (CISA) advisory republished on August 14, 2025, warning that multiple remotely exploitable vulnerabilities tied to Azure RTOS components and improper CIP packet handling could enable remote code execution or privilege escalation on affected devices, resulting in operational disruption across critical infrastructure sectors.

Background / Overview​

Rockwell Automation’s Micro800 family — which includes Micro820, Micro850, and Micro870 variants — is widely used in manufacturing and industrial control environments. The August 14, 2025 advisory classifies the combined risk as CVSS v4 9.3 and explicitly flags the issues as remotely exploitable with low attack complexity, a combination that raises urgent operational and security concerns for operators of affected controllers.
At a technical level the advisory ties several high-severity Common Vulnerabilities and Exposures (CVEs) to third‑party real‑time operating system components from Microsoft/Azure’s RTOS family (Azure RTOS NetX Duo and ThreadX) and to an improper input validation issue tied to malformed CIP (Common Industrial Protocol) Forward Close packets. These conditions can produce memory corruption (out-of-bounds write/read), remote code execution (RCE), and device fault states requiring manual recovery. Independent vulnerability trackers and vendor advisories corroborate the root cause and the severity of the underlying CVEs.

---

What’s affected: products, versions, and scope​

Affected product families and versions​

CISA’s advisory lists the following affected Micro800 variants and their impacted version ranges:

• PLC Micro820 LC20 — All versions prior to V14.011.
• PLC Micro850 LC50 — All versions prior to V12.013.
• PLC Micro870 LC70 — All versions prior to V12.013.
• PLC Micro850 L50E — Versions V20.011 through V22.011 are affected by additional CVEs including the CIP packet issue.
• PLC Micro870 L70E — Versions V20.011 through V22.011 likewise affected.

These product/version mappings are critical for triage — operators must verify firmware versions directly on their assets before applying any remediation plan. Rockwell’s advisory index and product pages provide the vendor-tracked remediation matrix and guidance for each model. (rockwellautomation.com, cisa.gov)

Who should care​

The advisory explicitly calls out deployment across critical sectors: Chemical, Critical Manufacturing, Energy, Food and Agriculture, Transportation Systems, and Water and Wastewater. The global footprint of Micro800 devices means the potential blast radius spans many industries where uptime and safety are paramount.

---

Technical breakdown: the vulnerabilities explained​

Dependency on vulnerable third‑party components (Azure RTOS NetX Duo / ThreadX)​

Three CVEs drive the most severe outcomes:

• CVE‑2023‑48691 — Out‑of‑bounds write in Azure RTOS NetX Duo that may lead to remote code execution. CVSS v3 reported as 9.8; CISA computed CVSS v4 base score 9.3. (cisa.gov, nvd.nist.gov)
• CVE‑2023‑48692 — Memory overflow issues in Azure RTOS NetX Duo affecting multiple networking stacks/protocol implementations; again enabling RCE in vulnerable configurations. CVSS v3 reported as 9.8; CVSS v4 also assessed at 9.3 by CISA. (cisa.gov, tenable.com)
• CVE‑2023‑48693 — Parameter‑checking weakness in Azure RTOS ThreadX enabling arbitrary read/write and potential privilege escalation; CISA lists analogous scoring (CVSS v3 9.8; CVSS v4 9.3). (cisa.gov, nvd.nist.gov)

These CVEs originate in the RTOS network and kernel components used by embedded devices. The practical implication: if a Micro800 device embeds the vulnerable NetX/ThreadX stacks (as Rockwell’s firmware has historically done), a remote network‑accessible exploit path exists for an unauthenticated attacker to corrupt memory, gain code execution within the PLC’s runtime, or escalate privileges. This combination is unusually dangerous in OT environments because successful misuse may allow attackers to modify control logic, steal process data, or deny service to operational equipment.

Improper input validation — CIP Forward Close fuzzing (CVE-2025-7693)​

A separate but equally severe issue is CVE‑2025‑7693, rooted in improper handling of malformed CIP Forward Close packets. During fuzzing, researchers reproduced the condition where controllers enter an unrecoverable fault LED state (solid red Fault), then after power cycle display a recoverable fault that requires clearing (fault code 0xF015). The practical effect observed is an operational denial‑of‑service requiring human intervention to clear the fault and return the controller to normal operation. CISA assigns the issue a high score and flags it as exploitable remotely and with low attack complexity.
This vector is particularly dangerous because CIP is the basis for EtherNet/IP communications — widely used in factory networks — so malformed packets can be sent from any network path that reaches the PLC’s management or control interfaces.

---

Risk evaluation: what an attacker can do​

• Remote code execution and privilege escalation are possible where NetX/ThreadX CVEs can be chain‑exploited against firmware that contains the vulnerable third‑party components. This can lead to:
• Modification of PLC logic (safety-impacting changes).
• Persistence in device firmware or runtime memory.
• Theft of configuration/credentials held in device memory.
• Denial‑of‑service via CIP Forward Close malformed requests can place controllers into fault states requiring manual recovery — a major operational impact for production lines or critical processes.
• The ease of exploitation is elevated by the advisory’s observation of low attack complexity and no required privileges, meaning threat actors that achieve network access to industrial zones can attempt exploitation without needing specialized credentials. (cisa.gov, tenable.com)

---

Mitigations and vendor guidance​

Vendor remediation and recommended updates​

Rockwell Automation’s guidance (reproduced in the advisory) recommends upgrade or migration paths aimed at moving devices onto versions that include fixes or use re‑engineered product SKUs:

• Micro820 LC20: migrate to Micro820 L20E V23.011 and later (target release noted by Rockwell). (cisa.gov, rockwellautomation.com)
• Micro850/870 L50E / L70E: upgrade to V23.011 and later for corrected revisions. (cisa.gov, rockwellautomation.com)

Rockwell’s public security advisories and product pages are the canonical reference for the exact corrective firmware file names and remediation tables; operators must cross‑check their specific part numbers and firmware families before updating. Firmware corrections and migration guidance may vary by SKU and hardware revision. (rockwellautomation.com, cisa.gov)

CISA operational mitigations (recommended defensive actions)​

CISA’s practical mitigations emphasize network posture and defense‑in‑depth:

• Remove direct Internet exposure of control system devices; they should not be reachable from the public Internet.
• Isolate control networks behind industrial firewalls and separate them from corporate/business networks.
• When remote access is necessary, prefer secure methods such as modern VPNs — but maintain patch currency for remote access appliances and endpoints, and apply least privilege.

CISA cautions organizations to perform impact analysis and risk assessment before deploying containment or mitigation solutions, especially where firmware upgrades carry the risk of device reconfiguration or program loss.

---

Operational realities: patching PLCs is not trivial​

Updating PLC firmware or migrating device families is an operational task that often requires planned downtime, configuration backups, and regression testing. Two critical constraints must be considered:

• Program and data persistence — some firmware actions (for example, full flashes to reset passwords or recover devices) may erase user programs and data, requiring restore from backups or re‑engineering. Rockwell has historically warned that certain recovery actions are destructive to user programs.
• Testing and validation — firmware replacements in OT environments must be validated in test or staging networks before production deployment to avoid unintended safety or functional regressions.

Given those realities, the recommended staged approach is:

• Inventory affected hardware and firmware versions.
• Identify devices that can be patched within scheduled maintenance windows.
• For devices that cannot be safely updated, apply network controls and monitoring compensations (micro‑segmentation, ACLs, industrial firewalls).
• Validate firmware updates in a sandboxed test rig reflective of production I/O and logic.
• Schedule safe rollouts with rollback plans and backup of PLC programs.

Operators should treat firmware migration as a cross‑discipline exercise involving OT engineers, control systems integrators, and cybersecurity/IT staff.

---

Detection, monitoring, and incident response​

• Network monitoring: watch for anomalous CIP/EtherNet‑IP traffic, unexpected Forward Close requests, or bursts of malformed packets targeting PLCs; these may be early indicators of fuzzing or exploitation attempts.
• Memory/corruption indicators: device LED faults (solid red Fault, MS LED patterns) and reported fault code 0xF015 — as documented by CISA — are operational signals that a device has encountered the CIP fuzzing issue and requires manual intervention.
• Log collection: ensure that OT network logs, packet captures, and management interfaces are logging sufficient telemetry; consider centralizing logs for correlation and threat hunting.
• Whitelist-based access: use strict firewall rules and allowlist management to restrict which addresses and management stations can send CIP/EtherNet‑IP traffic to PLCs.

If suspicious activity is observed, follow established internal incident response procedures, isolate the device/network segments, gather forensic evidence (packet captures, logs), and report findings to CISA or appropriate national CERT channels for correlation and assistance.

---

Supply-chain and engineering implications​

This advisory highlights a recurring industrial cybersecurity pattern: dependency on third‑party software components (here, Azure RTOS NetX Duo and ThreadX) embeds systemic risk into vendor firmware. When widely used RTOS components are later found vulnerable, every vendor that embeds those libraries may become vulnerable — elevating the importance of:

• Software bill of materials (SBOMs) for embedded devices, showing RTOS/library versions.
• Secure update channels and cryptographic verification for firmware images.
• Vendor transparency about embedded third‑party components and their update cadence.

Organizations should demand SBOMs and clear update SLAs from suppliers, and incorporate third‑party component management into asset risk assessments.

---

Critical analysis — strengths, gaps, and residual risks​

Notable strengths​

• Coordinated disclosure and vendor involvement: Rockwell reported the issues to CISA and provided migration recommendations; coordinated advisories allow operators to act with better information. (cisa.gov, rockwellautomation.com)
• Clear operational mitigations: CISA’s guidance is pragmatic and focused on network segmentation, minimizing Internet exposure, and secure remote access — measures that significantly reduce remote exploitation opportunity.

Potential gaps and risks​

• Timing and availability of fixes: Rockwell’s recommended migration to Micro820 L20E V23.011 was noted as targeted for release in September 2025, which means some operators will face multi‑week or multi‑month windows before vendor‑delivered fixes are widely available. This creates an extended period of elevated risk that must be managed by compensating controls. (cisa.gov, rockwellautomation.com)
• Operational cost of remediation: Firmware migration, device replacement, or full firmware flash for recovery may require significant downtime and engineering effort. The advisory’s observation that recovery may involve firmware flashes and clearing faults underscores possible destructive recovery paths. (rockwellautomation.com, cisa.gov)
• Detection limitations: Many OT environments lack full packet capture or centralized telemetry; attackers exploiting low‑complexity remote flaws may operate unnoticed for extended periods unless proactive monitoring is implemented.
• Supply‑chain ripple effects: NetX/ThreadX are used across many product families and vendors; operators must treat any new RTOS vulnerabilities as systemic and scan the fleet for impacted firmware versions.

Unverifiable or circumspect claims​

• Any claim that “no exploitation has been observed in the wild” should be treated cautiously. CISA stated there have been no known public exploitation reports at the time of the advisory, but absence of public reporting does not equal absence of exploitation in private or unreported incidents. Organizations should treat that statement as informative but not total assurance.

---

Practical checklist for operators (prioritized actions)​

• Inventory: Identify every Micro800 device, record model, exact firmware version, and network connectivity profile.
• Immediate containment: Block external access to PLCs — close management/engineering ports at the firewall and limit EtherNet/IP traffic to known hosts.
• Apply vendor guidance: Where updates/migrations are available and validated, schedule firmware upgrades per vendor recommendations. Confirm the exact corrective version for each SKU on Rockwell’s advisory index. (rockwellautomation.com, cisa.gov)
• Implement monitoring: Enable packet capture for suspect segments, track CIP Forward Close patterns, and alert on fault codes such as 0xF015.
• Test patches: Validate firmware in a testbed that replicates production I/O and logic before broad deployment.
• Backup and recovery: Ensure PLC programs and configurations are backed up prior to any firmware action and have rollback procedures well documented.
• Engage stakeholders: Coordinate with process engineers, plant managers, and integrators to balance security patching against safety and continuity requirements.

---

Final assessment and outlook​

The Micro800 advisory is a stark reminder that industrial control devices remain attractive targets because vulnerabilities can translate directly into physical impact. The combination of third‑party RTOS vulnerabilities and protocol parsing weaknesses yields high potential for both code execution and operational denial‑of‑service. The presence of low‑complexity, remotely exploitable vectors elevates urgency for operators to inventory assets, harden network exposure, and plan tested firmware migrations.
While vendor fixes and CISA guidance create a clear path to remediation, the operational reality — firmware availability windows, downtime costs, and the need for thorough testing — means many organizations will face a multi‑phase remediation effort. For risk managers and OT teams, the priority must be reducing attack surface now (segmentation, access control, monitoring) and executing validated upgrades as soon as they can be safely deployed.
Operators should treat this advisory as a high‑priority operational security task: inventory, isolate, monitor, and patch — in that order — while preparing contingency plans for safe firmware application and post‑update validation. The combination of vendor advisories and independent CVE trackers provide the cross‑reference needed to prioritize actions; CISA’s operational mitigation guidance should be integrated into incident response and patching playbooks immediately. (cisa.gov, nvd.nist.gov, rockwellautomation.com)

---

Rockwell Automation Micro800 users and OT security teams are encouraged to confirm affected versions against device firmware, follow Rockwell’s published update tables, and apply CISA’s recommended network defenses to minimize exposure while planning tested firmware migrations. (cisa.gov, rockwellautomation.com)

---

Source: CISA Rockwell Automation Micro800 | CISA