September 8, 2026

Multiple Denial-of-Service Vulnerabilities in Rockwell Automation RSLinx Classic

Security Advisory Brief

The Cybersecurity and Infrastructure Security Agency (CISA) published industrial control system advisory ICSA-26-244-01 on September 1, 2026, disclosing four denial-of-service vulnerabilities in Rockwell Automation RSLinx Classic. RSLinx Classic is the communications middleware that connects Rockwell Automation engineering and visualization software — Studio 5000 Logix Designer, RSLogix 5000, FactoryTalk View, and the historian and reporting products that sit above them — to Allen-Bradley controllers and devices over EtherNet/IP. All four vulnerabilities are reachable across the network by an unauthenticated attacker, all four are triggered by a single crafted Common Industrial Protocol (CIP) message, and all four crash the RSLinx Classic service. Every version of RSLinx Classic at 4.50 and earlier is affected, and the product is deployed worldwide across the critical manufacturing sector.

Two of the four vulnerabilities are integer arithmetic defects. CVE-2026-9621, with a CVSS v3.1 base score of 8.6 and a CVSS v4.0 base score of 9.2, is an integer overflow or wraparound (CWE-190) in which a crafted CIP packet causes the RSLinx Classic service to crash and require a restart. CVE-2026-9622, also scoring 8.6 under CVSS v3.1 and 9.2 under CVSS v4.0, is an integer underflow (CWE-191) triggered by a crafted CIP packet targeting the Forward Close service. Both carry a changed scope in their CVSS v3.1 vectors and a high subsequent-system availability impact under CVSS v4.0, which is the formal way of recording that the crash does not stop at the vulnerable service — it removes the communications path that every dependent application relies on. The remaining two are parsing defects confined to the service itself. CVE-2026-9624, with a CVSS v3.1 base score of 7.5 and a CVSS v4.0 base score of 8.7, is a second integer underflow (CWE-191) arising from insufficient data length validation. CVE-2026-9625, also 7.5 under CVSS v3.1 and 8.7 under CVSS v4.0, is a classic buffer overflow (CWE-120) triggered by a crafted CIP packet carrying an oversized embedded message request.

The significance of this advisory lies in where RSLinx Classic sits rather than in the severity of any single defect. RSLinx Classic is not an endpoint application; it is a shared dependency, frequently installed on a single server that brokers connectivity between an entire plant's visualization, historian, and engineering estate and the controllers on the plant floor. When it stops, the controllers continue to execute their programs, but the operators lose view, the historian stops recording, alarm annunciation degrades, and engineering access is severed — a loss of view and loss of control condition without any compromise of the control logic itself. Because the service listens for unauthenticated CIP messages by design, an attacker requires no credentials, no foothold on an engineering workstation, and no interaction from an operator. Rockwell Automation has corrected all four defects in RSLinx Classic version 4.60. CISA reports no known public exploitation specifically targeting these vulnerabilities at this time.

Threats and Vulnerabilities

CVE-2026-9621, with a CVSS v3.1 score of 8.6 and a CVSS v4.0 score of 9.2, is an integer overflow or wraparound vulnerability (CWE-190) in the CIP message-handling path of RSLinx Classic. A crafted CIP packet causes an arithmetic operation on a length or size field to wrap, and the resulting undersized or miscalculated allocation crashes the RSLinx Classic service, which must then be restarted before communications resume. The CVSS v3.1 vector describes a network-reachable attack of low complexity requiring no privileges and no user interaction, with a changed scope — the impact extends beyond the vulnerable component to the applications that depend on it for controller connectivity. This is the highest-scoring of the four and, along with CVE-2026-9622, the one that most directly translates a single packet into a plant-wide visibility outage.

CVE-2026-9622, also with a CVSS v3.1 score of 8.6 and a CVSS v4.0 score of 9.2, is an integer underflow vulnerability (CWE-191) reached through the CIP Forward Close service. Forward Close is the routine half of CIP connection management, used to tear down an established connection between a client and a device, which means the vulnerable code path is exercised constantly during normal operation and is not gated behind any unusual or privileged request type. A crafted Forward Close message causes a size calculation to underflow, and the RSLinx Classic service crashes. Like CVE-2026-9621 it carries a changed scope under CVSS v3.1 and a high subsequent-system availability impact under CVSS v4.0. The practical concern is that an attacker does not need to construct an exotic request — an attack that abuses a message type the service processes routinely is difficult to distinguish from legitimate traffic on volume or type alone.

CVE-2026-9624, with a CVSS v3.1 score of 7.5 and a CVSS v4.0 score of 8.7, is a further integer underflow vulnerability (CWE-191) caused by insufficient data length validation during CIP packet parsing. A crafted packet whose declared length does not correspond to its actual content drives the parsing logic into an underflowed calculation and crashes the service. The scope is unchanged in the CVSS v3.1 vector and the subsequent-system availability impact is none under CVSS v4.0, meaning the recorded impact is confined to the RSLinx Classic service rather than formally extending to dependent components — a distinction that matters for scoring but not for the operator, whose connectivity is lost either way.

CVE-2026-9625, with a CVSS v3.1 score of 7.5 and a CVSS v4.0 score of 8.7, is a classic buffer overflow (CWE-120) triggered by a crafted CIP packet containing an oversized embedded message request. CIP supports message encapsulation, in which one request carries another for routing to a device behind a bridge or communications module, and the defect lies in copying that embedded request into a fixed-size buffer without validating its length first. The immediate consequence is a service crash. Buffer overflows of this class warrant particular attention in remediation planning because the boundary between a reliable crash and a more serious memory-corruption outcome is a property of the specific code path and the compiler mitigations in effect, not something an operator can assess from the outside. All four vulnerabilities affect RSLinx Classic versions 4.50 and earlier, and all four are corrected in version 4.60. No workaround has been published for any of them.

Client Impact

The operational consequence of any of these four vulnerabilities is the loss of the communications path between the plant's software estate and its controllers. RSLinx Classic is commonly deployed as a shared service on a single server — a FactoryTalk View SE server, a historian collector, or a dedicated communications host — and every application that reaches Allen-Bradley devices through that server loses connectivity when the service crashes. Operators lose their process graphics and live values, the historian stops collecting, alarm annunciation degrades or stops entirely, batch and recipe systems lose their device interface, and engineering staff lose the ability to go online with a controller at precisely the moment they most need to. The controllers themselves continue running their programs, which means the process does not stop but does become unobserved and uncommanded, and in many plants operating procedure requires a controlled shutdown when view is lost for any extended period. Because a crashed service can be restarted, the individual outage may be short; because the attack requires only one packet and can be repeated, an attacker who retains network access can hold the plant in that state indefinitely.

The compliance consequence is shaped by the fact that RSLinx Classic runs on a Windows host inside the control network, which brings it within scope of controls that a controller itself often escapes. Entities subject to NERC CIP must evaluate these four CVEs under CIP-007-6 R2 within 35 calendar days of release and either install the update or produce a dated, documented mitigation plan; the absence of any vendor workaround means that plan rests almost entirely on network access controls, and the evidence burden shifts to CIP-005 electronic security perimeter documentation and CIP-010 configuration change management for the upgrade itself. Organizations aligning to IEC 62443-3-3 will find these vulnerabilities implicate system requirements SR 7.1 and SR 7.2 for denial-of-service protection and resource management, and SR 3.5 for input validation, which is the requirement the four defects collectively fail. Manufacturers operating to NIST SP 800-82 guidance, pipeline operators under TSA security directives, and water utilities under state and federal cybersecurity expectations should treat an unpatched RSLinx Classic server as a documented, time-bound risk acceptance with named compensating controls rather than an open remediation item, and should be prepared to demonstrate that inbound CIP messaging to that server is restricted to an enumerated set of authorized sources.

Mitigations

1898 & Co. recommends the following actions to reduce exposure to CVE-2026-9621, CVE-2026-9622, CVE-2026-9624, and CVE-2026-9625.

Identify every host running RSLinx Classic and record the exact installed version on each. Because RSLinx Classic is frequently installed as a dependency of FactoryTalk, Studio 5000, RSLogix 5000, and third-party historian and reporting products rather than as a deliberate standalone deployment, an inventory built from purchase or license records will be incomplete. Enumerate by software inventory query, by installed-service query across the Windows estate in the control network, and by checking every host that listens on TCP port 44818. Any host at version 4.50 or earlier is affected.
Upgrade every affected host to RSLinx Classic version 4.60. Sequence the work through change management and validate the upgrade against the dependent applications on each host, since RSLinx Classic is a shared component and a version change affects every product that consumes it. Where a dependent application constrains the RSLinx version, escalate that constraint to the application vendor as a remediation blocker and record it explicitly rather than allowing it to defer the upgrade silently.
Restrict inbound CIP traffic to every RSLinx Classic host. TCP and UDP port 44818 and UDP port 2222 should not be reachable to that host from the enterprise network, from any guest or unmanaged segment, or from the internet, and inbound CIP from within the control network should be constrained to the enumerated set of engineering workstations, HMI servers, and devices that legitimately initiate connections to it. Verify the resulting rule set by test rather than by configuration review, and confirm that no RSLinx Classic host is internet-reachable.
Deploy or tune detection for anomalous CIP traffic directed at RSLinx Classic hosts and for the service failure itself. Monitor for malformed or oversized CIP messages, for a rate of Forward Close requests inconsistent with the established baseline, and for inbound CIP from sources outside the authorized set. Pair that network detection with host monitoring for unexpected termination and restart of the RSLinx service, so that a crash is recognized as a security event rather than dismissed as a software fault — these vulnerabilities produce exactly the signature that operations staff have learned to treat as routine instability.
Establish and rehearse a recovery procedure for the loss of RSLinx Classic connectivity, covering how the service is restarted, how operators are alerted that view has been lost rather than merely degraded, what the procedure is for running the process without visualization, and at what point a controlled shutdown is required. Confirm that the recovery path does not depend on the same failed component, and preserve service crash artifacts — Windows Application error records, service control manager events, and any crash dump — as evidence before restarting.

Applying these actions together reduces both the likelihood that a crafted CIP message reaches an RSLinx Classic host and the operational cost of the outage if one does.

1898 & Co. Response

1898 & Co. has supported industrial and critical infrastructure organizations through vulnerability disclosures affecting the Rockwell Automation software estate for many years, and our operational technology security team works alongside plant engineering and controls staff rather than around them. We help clients build an accurate inventory of shared control-network software components — the RSLinx, FactoryTalk, and OPC layers that inventories built from license records routinely miss — translate a vendor advisory into a site-specific applicability determination, and sequence remediation into maintenance windows in a way that respects production commitments and application dependencies.

Our managed threat detection and response service is built specifically for operational technology environments, with analysts who understand CIP, EtherNet/IP, and the behavior of the Rockwell software stack under normal and abnormal conditions. That grounding matters for vulnerabilities of this kind, because the difference between a service crash caused by a memory leak and one caused by a crafted Forward Close message is visible only when host telemetry and network evidence are examined together. We provide threat hunt content, detection engineering, and incident response support scoped to the control network rather than adapted from information technology tooling.

For organizations working through NERC CIP, IEC 62443, TSA, or state regulatory obligations, 1898 & Co. provides assessment and advisory support that documents the applicability determination, the mitigation plan, and the network access control evidence in the form auditors expect. We work alongside clients to close the gap between an advisory being published and a defensible position being recorded, and we remain available to support upgrade planning, network architecture review, and post-incident analysis for the affected Rockwell Automation software.

Sources

Cyberthreat