ArmorStart LT DoS Vulnerabilities: 9 CVEs With No Patch Yet

Rockwell Automation’s ArmorStart LT has been publicly flagged for multiple denial-of-service (DoS) vulnerabilities that can render affected motor controllers unresponsive, forcing manual recovery and potentially interrupting production lines. Rockwell’s SD1768 advisory lists nine CVE identifiers and assigns high-severity ratings (CVSS v3.1 ≈ 7.5; CVSS v4.0 ≈ 8.7), while national vulnerability repositories and CERTs corroborate the findings and describe reproducible failure modes triggered by fuzzing and active scanning.

Background​

ArmorStart® LT is a compact, pre‑engineered distributed motor control solution intended for material‑handling applications. It supports full‑voltage, reversing, and variable‑speed motor control, and includes integrated network connectivity intended for on‑machine deployment. The product family is sold under several catalog numbers (notably 290D, 291D, 294D), and Rockwell reports that firmware revisions at or below V2.002 are affected by the issues disclosed.
These advisories come as part of a broader trend: vendors and national authorities have increasingly published coordinated disclosures for industrial control systems (ICS) products after internal testing, fuzzing, or third‑party research revealed fragilities in protocol stacks or resource management. Previous Rockwell and ICS advisories have shown similar DoS‑type failure modes triggered by malformed CIP/EtherNet‑IP traffic, memory exhaustion, or stress tests, underscoring the recurring problem of uncontrolled resource consumption in networked controllers.

---

What Rockwell reported (straight facts)​

• Affected models: ArmorStart LT catalog numbers 290D, 291D, 294D running firmware V2.002 and earlier.
• CVE identifiers: CVE‑2025‑9464, CVE‑2025‑9465, CVE‑2025‑9466, CVE‑2025‑9278, CVE‑2025‑9279, CVE‑2025‑9280, CVE‑2025‑9281, CVE‑2025‑9282, CVE‑2025‑9283.
• Vulnerability class: Uncontrolled Resource Consumption (CWE‑400) that can lead to denial‑of‑service. Rockwell’s advisory maps each CVE to DoS outcomes observed during fuzzing and protocol stress tests.
• Severity: Rockwell’s advisory reports CVSS v3.1 scores around 7.5 (high) and CVSS v4.0 scores around 8.7 (high). National repositories mirror the vendor scoring.
• Vendor status: As of the advisory publication, Rockwell indicates no corrected firmware release and no workaround is available; the advisory is being used to inform customers and encourage mitigations until a fix is available.

These are the core, verifiable facts published by Rockwell and mirrored in independent CVE/NVD/third‑party advisories. Where Rockwell details differ across locales, the product and CVE lists remain consistent.

---

Technical analysis: how these DoS conditions occur​

What “uncontrolled resource consumption” means here​

Uncontrolled resource consumption (CWE‑400) covers defects where a system doesn’t validate or properly limit inputs, buffers, or operational parameters, allowing an attacker (or aggressive scanner) to exhaust CPU, memory, network sockets, or protocol‑state resources. In ArmorStart LT’s case, vendor testing shows that fuzzing or specifically crafted traffic targeting CIP/EtherNet‑IP and related protocol handlers can produce:

• Loss of web or network connectivity (ICMP/unreachable), and
• Unexpected reboots or transient major faults that stop normal operation for several seconds or longer.

Multiple CVEs reference different trigger conditions — e.g., active web‑scanner payloads, Achilles test suites, EtherNet‑IP “storm” tests, and fuzzing of CIP classes — but the end result is consistently availability loss.

Attack surface and exploitability​

• Attack vector: Network (AV:N in CVSS v4.0 vector published by the vendor), meaning an attacker with network access to the device can trigger the condition. In practice, adjacency may be required (same VLAN or reachable segment) for on‑machine controllers not exposed beyond ICS networks, but some vectors indicate remote network exposure can be problematic.
• Complexity: Low — the reported CVSS metrics and vendor findings indicate no special privileges or user interaction are required to trigger the condition; a crafted request or scanning activity suffices.
• Persistence and recovery: Observed behaviors include reboots or link monitor outages; recovery often requires a manual restart or power cycle. That is operationally disruptive and may require on‑site intervention.

Practical exploitation scenarios​

• Accidental: Security teams scanning an on‑machine device with active scanners (Burp, Nessus, Achilles) can inadvertently bring production devices offline—something many incident reports and CERT summaries warn about.
• Malicious: An adversary with network access—lateral access from a compromised workstation, a misconfigured VPN, or a breached remote access jump host—could repeatably trigger the DoS to interrupt operations or create safety‑adjacent chaos.

---

Impact on operations and industrial risk profile​

The ArmorStart LT family sits on the machine line, directly controlling motors in material handling use cases. That means loss of availability has immediate, concrete consequences:

• Production stoppage: If an array of on‑machine controllers goes offline, conveyors, sorters, and handling subsystems stop functioning, causing immediate operational loss and potential product spoilage.
• Safety and fallback complexity: While DoS itself is an availability issue, loss of telemetry and control can cascade into manual overrides, human error, and safety system interactions that complicate recovery.
• Maintenance burden: Manual restarts and on‑floor interventions consume technician time and may require planned downtime windows to avoid risk during shift changes.
• Business exposure: Extended outages ripple into supply chains, SLAs, and revenue, especially in high‑throughput facilities.

ICS outages are rarely contained to a single device; they tend to involve HMIs, historians, engineering workstations, and Windows‑based supervisory systems that rely on continuous PLC data streams. Windows teams must treat these ICS DoS advisories with the same urgency as enterprise server vulnerabilities because the downstream effects are operational and financial.

---

Detection and indicators​

Operators and security teams should watch for the following indicators that map to Rockwell’s reported behavior:

• Sudden loss of ICMP or web responsiveness from ArmorStart LT devices after active scanning or network stress events.
• Unexpected device reboots or transient Link State Monitor outages coinciding with fuzzing or scanning activity. Several CVEs explicitly describe reproduction in Achilles tests and scanners.
• Repeated alarms on HMIs and supervisory systems indicating I/O loss to one or more on‑machine controllers. Correlate these with network logs to identify suspicious traffic patterns.

Because some triggers are noisy (e.g., active vulnerability scans), defenders should instrument logging at network edges and collect packet captures around incidents. That enables forensic correlation to determine whether a benign scan or a targeted attack caused the outage.

---

Mitigations: immediate steps you can and should take (practical, prioritized)​

Rockwell’s advisory and national guidance converge on a layered defense approach. Below are prioritized mitigations for operators, Windows sysadmins, and security teams responsible for hybrid IT/OT environments.

• Inventory and identify:
• Locate every ArmorStart LT device by catalog number (290D, 291D, 294D) and record firmware version strings. Devices at or below V2.002 are in scope.
• Map device network placement — VLAN, subnets, firewall rules, and whether any are reachable via business networks or VPNs.
• Reduce exposure (network controls):
• Segregate ICS and control networks from business networks using firewalls and strict ACLs. Ensure on‑machine devices are not accessible from the internet or general corporate subnets.
• Block unnecessary services and ports at the network perimeter; limit management protocols to trusted engineering workstations and jump hosts only.
• Use host‑based access control to prevent unauthorized scanning tools from reaching control segments.
• Harden remote access:
• Where remote access is required, use properly configured jump hosts and updated VPN appliances. Recognize that VPNs are only as secure as the endpoints and should be hard‑segmented.
• Enforce multi‑factor authentication for remote engineering and maintenance access.
• Avoid noisy scanning in production:
• Do not run active vulnerability scans or fuzz testing against production ArmorStart LT devices. If testing is necessary, isolate devices in a lab or scheduled maintenance window. Several reported failures reproduced using Burp, Achilles, and fuzzing suites.
• Monitoring and detection:
• Instrument network IDS/IPS to alert on unusual CIP/EtherNet‑IP session behavior, frequent malformed frames, or scanning patterns.
• Add supervision of device health checks (heartbeat/Link State Monitor) and correlate with network events to detect DoS onset early.
• Change control and testing:
• If you plan any firmware upgrades or configuration changes, follow strict change‑control, test in a staging environment, and schedule maintenance windows with operations teams.
• When patching becomes available:
• Prioritize applying vendor fixes to affected devices. Rockwell’s advisory currently lists no corrected firmware; continue to monitor the vendor advisory for updates and plan patch deployments once fixes are released. Flag any systems that cannot be upgraded and isolate them further until a remediation path exists.

---

Why Windows teams should pay attention (specific guidance)​

Windows administrators often host HMIs, historians, remote access gateways, and engineering tools that interact directly with ArmorStart LT controllers. Actions you can take from the Windows side:

• Harden engineering workstations:
• Restrict which workstations can access ICS segments; use hardened jump hosts and privileged access management to control remote sessions.
• Ensure Windows endpoints used for ICS engineering are patched, have up‑to‑date anti‑malware, and run minimal services to reduce lateral movement risk.
• Segregate management interfaces:
• Host FactoryTalk and other management tools on dedicated, hardened Windows servers that can only reach controllers via tightly controlled routes.
• Logging and forensics:
• Enable detailed logging on Windows jump hosts and remote access servers; retain logs long enough to investigate correlated ICS incidents.
• Training and procedures:
• Train Windows administrators and helpdesk personnel to recognize ICS failure indicators and to not run active scanners against production control devices.

These steps create practical friction for attackers and reduce the chance that routine IT operations inadvertently trigger outages.

---

Vendor response, disclosure timeline, and what remains unknown​

Rockwell published advisory SD1768 on January 20, 2026, disclosing the nine CVEs and the affected firmware cutoff (≤ V2.002). The advisory indicates the issues were discovered during internal testing and that, as of publication, corrected firmware releases were not yet available; Rockwell labels the advisory “Corrected: No” and “Workaround: No.” Independent trackers (NVD, CVE aggregators, and national CERTs) have added the CVE entries and echo the DoS/uncontrolled resource consumption descriptions and severity ratings.
What remains unclear or unverifiable at time of writing:

• The exact line‑by‑line root cause and which internal subsystems (CIP stack, web server, IPv6 handler, etc.) are implicated under each CVE are high‑level in the vendor advisory. The public documentation intentionally omits exploit code and low‑level debugging details. Until Rockwell releases patch notes with technical fixes, defenders must rely on test reproduction descriptions and observed failure modes. Treat any claim of a complete fix as unverified until Rockwell publishes a formal corrected firmware and release notes.

Flag: any assertions that a particular CVE can be exploited from the open internet should be treated with caution. Some CVE vectors report network access as the vector, but real‑world exploitability depends on whether devices are exposed beyond tightly segmented ICS networks. Always verify the exact network exposure of your devices before assuming external remote exploitation risk.

---

Implementation checklist for operations teams (quick action list)​

• Inventory all ArmorStart LT devices and record firmware versions. If any are V2.002 or below, mark them as high priority.
• Immediately block external network access to any on‑machine controllers and enforce ACLs so only trusted engineering subnets can reach them.
• Suspend active vulnerability scans against production ArmorStart LT devices until isolated testing windows exist.
• Implement or validate jump host architecture for remote engineering — require MFA and session logging.
• Configure network monitoring to detect anomalous CIP/EtherNet‑IP traffic and sudden ICMP/web outages from controllers.
• Maintain an incident playbook: if a device loses connectivity or reboots unexpectedly, follow a pre‑approved sequence to capture packet captures and logs before power cycling where feasible.
• Monitor Rockwell’s SD1768 advisory, NVD entries, and national CERT feeds for firmware fixes and detailed remediation steps.

---

Strategic recommendations: beyond immediate mitigation​

• Adopt a defense‑in‑depth posture: combine segmentation, strict access control, endpoint hardening, IDS/IPS monitoring, and robust change management to reduce the likelihood and impact of ICS vulnerabilities. National guidance and Rockwell both emphasize layered controls rather than single fixes.
• Build a secure testing lab: vendors and teams should encourage a dedicated staging environment where active scanning, fuzzing, and resilience testing occur off the production network. That will prevent accidental DoS events during security assessments.
• Invest in ICS visibility: centralized asset and firmware inventories, automated configuration checks, and integrated IT/OT logging pipelines reduce time‑to‑detect and time‑to‑respond. Windows servers often host tools that can feed telemetry into SOC processes — use them.
• Plan for patch operations: when Rockwell publishes corrected firmware, ensure you have tested rollback procedures, spare devices for testing, and scheduling plans that minimize production impact. For devices that cannot be patched immediately, prioritize isolation and monitoring.

---

Final assessment: strengths, risks, and what to watch​

Strengths

• Transparent vendor disclosure: Rockwell publicly documented the affected models and CVEs (SD1768), which helps customers prioritize mitigations and inventory activities. Public scoring (CVSS v3/v4) and cross‑listing with national repositories provide useful triage data.
• Reproducible test observations: independent CVE trackers and CERTs repeat vendor‑observed triggers (Burp, Achilles, fuzzing), which aids defenders in reproducing and validating incidents in lab environments.

Risks and gaps

• No available patch at disclosure: Rockwell listed no corrected firmware at publication, leaving operators to rely on network mitigations and procedural controls until a fix is provided. This increases the window of operational risk.
• Potential for accidental outages: routine security scanning or red‑team exercises could inadvertently trigger DoS conditions if performed against production devices. This creates a practical problem for security teams that must validate systems without causing business impact.
• Lack of low‑level technical detail: the advisory provides high‑level CWE classifications and test reproduction descriptions, but not source code fixes or detailed root cause analysis, making it harder for third parties to craft targeted compensations beyond isolation and access control. Until Rockwell publishes full corrected firmware and release notes, some technical claims remain unverifiable.

What to watch next

• Rockwell firmware releases and patch notes for SD1768 will be the highest‑value update. Once corrected versions are published, operators should prioritize testing and staged deployments.
• Any public proof‑of‑concept or exploit code appearing in the wild would sharply increase urgency; monitor CERT feeds and vulnerability trackers for exploitation evidence. At the time of publication, no confirmed public exploitation of these ArmorStart LT CVEs has been reported.

---

Conclusion​

The ArmorStart LT advisory (SD1768) is a timely reminder that even compact, on‑machine controllers are exposed to network‑borne reliability risks. The nine CVEs tied to uncontrolled resource consumption can lead to real operational consequences: reboots, network unreachability, and manual recovery steps that interrupt production. Rockwell’s transparent disclosure combined with independent corroboration by national vulnerability repositories allows defenders to act quickly: inventory affected devices, isolate and harden networks, suspend active scans against production devices, and prepare for patches.
For Windows administrators, the advisory is an operational call‑to‑action — your servers, HMIs, jump hosts, and remote access gateways are part of the attack surface and must be hardened, monitored, and operated under strict change control. Until Rockwell publishes corrected firmware, defense in depth — segmentation, strict access controls, and careful operational procedures — remains the best practical protection against these high‑severity denial‑of‑service vulnerabilities.

---

Source: CISA Rockwell Automation ArmorStart LT | CISA