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.
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.
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.
1898 & Co. recommends the following actions to reduce exposure to CVE-2026-9621, CVE-2026-9622, CVE-2026-9624, and CVE-2026-9625.
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. 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.