For Windows administrators, this is a plant-operations issue rather than a routine desktop patching item. RSLinx Classic is frequently the Windows-resident communications layer between engineering or supervisory software and Rockwell industrial equipment. A service crash can interrupt data collection, device browsing, diagnostics, or the connection path used by applications that depend on it, even if the PLCs themselves remain online.
CISA’s bulletin is based on Rockwell Automation’s disclosure, while the CVE Program records submitted by Rockwell provide the more useful technical detail: all four cases require only network access, have low attack complexity, and require neither authentication nor user interaction. The immediate defensive job is therefore to find every RSLinx Classic host, determine whether it is version 4.50 or older, and verify which networks can send it CIP traffic.
Four packet-handling failures, one operational result
The four CVEs describe separate input-validation failures in RSLinx Classic, but their stated outcome is the same: the RSLinx service crashes and must be restarted.
CVE-2026-9621 is associated with integer overflow or wraparound caused by malformed packet handling. Its CVSS 4.0 record assigns a 9.2 Critical score because the flaw is reachable over the network without credentials or user interaction and can affect availability beyond the vulnerable component.
CVE-2026-9622 involves a crafted CIP packet aimed at the Forward Close service. That service is part of CIP connection management, which makes this case particularly relevant to environments where RSLinx systems accept industrial traffic from broadly reachable segments. The published record says the packet can crash the service, again requiring a restart to recover.
CVE-2026-9624 is an integer-underflow issue tied to insufficient validation of packet data length. CVE-2026-9625 is classified as a classic buffer overflow: an oversized embedded-message request in a CIP packet can crash the RSLinx Classic service. Rockwell’s published CVE records rate both of those cases 8.7 High under CVSS 4.0.
The critical operational detail is the recovery mechanism is a service restart, not an automatic failover described in the advisory. Facilities should confirm who can perform that restart, what applications reconnect afterward, whether a restart affects production-support workflows, and whether the Windows host will reliably resume any required services after a reboot. A runbook that merely says “restart RSLinx” is incomplete if operators must also re-establish application connections or validate communications with controllers.
CISA’s 8.6 score does not tell the whole story
CISA presents the advisory with a CVSS v3 score of 8.6. That number is useful for broad triage, but it should not be treated as a complete substitute for the individual CVE records. Rockwell’s CVSS 4.0 record for CVE-2026-9621 reaches 9.2 Critical, while the records for CVE-2026-9624 and CVE-2026-9625 show 8.7 High.
This is not necessarily a contradiction. CVSS version 3 and version 4 measure and express impact differently, and the CVSS 4.0 records distinguish whether availability consequences can extend beyond the RSLinx host. CVE-2026-9621 is scored with high availability impact to both the vulnerable system and subsequent systems; the two 8.7 cases are scored with high impact to the vulnerable system but no assessed subsequent-system availability impact.
The practical conclusion is straightforward: do not let a single consolidated severity value decide plant priority. A Windows RSLinx workstation that is isolated to a small engineering cell and has a documented restart procedure does not carry the same operational exposure as an RSLinx server serving multiple production applications or reachable from a flat OT network. The version inventory, connectivity map, and recovery dependency matter more than whether an asset-management dashboard displays 8.6, 8.7, or 9.2.
No corrected RSLinx Classic release is identified in the public record
The important omission in the September 1 material is a named patched version. CISA identifies RSLinx Classic 4.50 and prior as affected and provides standard ICS hardening guidance, but does not identify an updated build that fixes the flaws. The Rockwell-submitted CVE records likewise identify the affected range without naming a remediated version or a product-specific workaround.
That means organizations should not assume that moving to the latest installer already available internally resolves the issue. They should check Rockwell’s SD1794 advisory and product support channels before changing software on a production-connected Windows host, particularly where RSLinx Classic is coupled to older FactoryTalk, RSLogix, or custom supervisory applications. Compatibility validation is a real constraint in industrial environments, but it is not a reason to leave the system broadly reachable while waiting for a patch.
CISA says it has received no reports of public exploitation specifically targeting these four vulnerabilities as of September 1. There is also no public exploit maturity score or EPSS estimate in the CVE records reviewed for the advisory. Those absences should be read as a lack of published evidence, not as proof that probing cannot occur on exposed or poorly segmented industrial networks.
What OT and Windows teams should do now
The most effective immediate mitigation is to reduce who can reach the RSLinx Classic service. CISA recommends minimizing network exposure, keeping control systems off the internet, placing industrial networks behind firewalls, separating them from business networks, and using updated VPNs where remote access is necessary.
For teams responsible for the Windows systems themselves, the work should begin with an inventory rather than a blind software push:
- Identify RSLinx Classic installations, including engineering workstations, jump hosts, historian-adjacent systems, and shared communications servers, then record their exact installed version and role.
- Treat every RSLinx Classic deployment at version 4.50 or earlier as affected until Rockwell documents a fixed release or confirms a configuration is outside the affected code path.
- Review firewall rules and routing paths to establish which assets can send CIP traffic to each RSLinx host. Business-network workstations, vendor VPN pools, wireless segments, and unmanaged maintenance laptops deserve particular scrutiny.
- Restrict industrial protocol traffic to documented peers and remove broad “any-to-any” rules between enterprise IT and OT segments. A firewall rule is valuable only if the permitted source systems are themselves controlled and necessary.
- Test the RSLinx service restart procedure during an approved maintenance window. Record service dependencies, application recovery time, operator notifications, and checks that confirm communications have returned.
- Monitor RSLinx service failures and Windows event logs for unexplained crashes. Repeated crashes around the same time, especially where network telemetry shows malformed or unusual CIP activity, warrant incident investigation rather than repeated restarts.
The restart requirement creates a useful detection opportunity. A malicious packet may not leave the obvious artifact of an unauthorized configuration change, but it can produce a service-stop event, application disconnects, and a corresponding loss of communications. Correlating those Windows events with firewall, switch, and industrial intrusion-detection telemetry is more actionable than looking for a generic malware signature.
Segmentation is the available fix until Rockwell publishes one
The advisory’s value is not in discovering a new remote-code-execution path; none is described. Its warning is that unauthenticated network traffic can interrupt a Windows-based industrial communications component that may sit in the middle of production-support workflows.
Rockwell Automation reported the vulnerabilities to CISA, and CISA’s advisory is dated September 1, 2026. Until a corrected RSLinx Classic version or product-specific mitigation is published, the defensible response is to make RSLinx hosts reachable only from the industrial systems that genuinely require them, validate that recovery procedures work, and treat unexplained service crashes as a security signal rather than ordinary Windows instability.