Four RSLinx Classic DoS CVEs: the crash is known, the blast radius is not
Rockwell SD1794 lists four denial-of-service vulnerabilities in RSLinx Classic V4.50 and earlier, fixed in V4.60. The crash is a known event; the blast radius at any site is a question only that site's own inventory can answer.
RSLinx Classic is the Windows service that lets engineering software talk to Allen-Bradley controllers. On 1 September 2026 Rockwell published advisory SD1794 for it: four denial-of-service vulnerabilities, each triggered by a crafted CIP packet that crashes the RSLinx service and needs a restart to recover. None of the four is remote code execution on its own. The advisory matters to a food or packhouse line less because of the CVSS numbers and more because of a question most sites cannot answer quickly: which Windows hosts run RSLinx Classic, and what stops when that service dies?
What the advisory covers
SD1794 lists four CVEs affecting RSLinx Classic V4.50 and earlier, corrected in V4.60, catalog 9355-WAB. All four share one shape: a crafted Common Industrial Protocol (CIP) packet reaches the service and crashes it.
- CVE-2026-9621: improper handling of a malformed packet (CWE-190). Rockwell scores it 9.2 on the CVSS 4.0 scale and 8.6 on CVSS 3.1.
- CVE-2026-9622: a crafted CIP packet targeting the Forward Close service (CWE-191). Rockwell scores it 9.2 (CVSS 4.0) and 8.6 (CVSS 3.1); the NVD record lists 8.7 (CVSS 4.0).
- CVE-2026-9624: insufficient data length validation (CWE-191). Rockwell scores it 8.7 (CVSS 4.0) and 7.5 (CVSS 3.1).
- CVE-2026-9625: an oversized embedded message request (CWE-120). Rockwell scores it 8.7 (CVSS 4.0) and 7.5 (CVSS 3.1).
Rockwell reports no known public exploitation and the advisory carries no Known Exploited Vulnerability entry as of writing. CISA advisory ICSA-26-244-01 covers the same coordinated disclosure. These are one disclosure family, not three independent findings.
What breaks and what keeps running
RSLinx Classic is a bridge, not a controller. It gives configuration, programming and monitoring tools real-time data access to controllers. When a crafted packet crashes the service, the engineering workstation, and anything else that depends on that RSLinx data path, loses the connection. In a typical architecture the controller keeps executing its stored logic while the bridge is down, which is exactly why a crash-class advisory is easy to skip and why that skip can still cost a production window.
A dead RSLinx service can stop a programmer from going online, stop an HMI or data-acquisition path that reads through the service, and stall a maintenance or change task. It does not, by itself, stop a pump or a conveyor. Whether a site loses anything physical depends on whether any control or monitoring function depends on that Windows host, which is an architecture question, not an advisory question.
What an operator should check
Before the advisory is even actionable, a site has to answer an inventory question:
- Which Windows hosts run RSLinx Classic, and at what exact version? Only V4.50 and earlier are affected.
- Which of those hosts are reachable from the control network, and which are reachable from business, remote-support or internet paths?
- What each RSLinx host supports: programming only, live HMI, data acquisition, or a historian feed?
- If the service died now, what would stop, and what would keep running at controller level?
- Who owns the restart, and how long does recovery take inside a production window?
- Is the host segmented so that only engineering and control traffic can reach it?
Segmentation is the first compensating control because CIP is network-adjacent by design: any host on the reachable control segment can send CIP packets to the RSLinx service.
Upgrade and recovery choices
The corrected version is V4.60. For a site that can schedule a maintenance window, the upgrade path is a version change on the engineering host with the usual testing against the controllers it serves. For a site that cannot upgrade immediately, the practical controls are segmentation into a defined zone, restricting who and what can reach the RSLinx host, and verifying remote-access paths. The site should also confirm that a service crash is a known, owned, restartable event, not an unplanned discovery during a run. In IEC 62443 terms the RSLinx host belongs in a zone whose conduit carries engineering traffic only, a framing that applies to the whole control network and not just this one service.
Recovery from all four flaws is a service restart. Whether that restart is automatic, manual, or requires a host reboot is a property of how the site runs the service, and the recovery owner should be named before an incident, not during one.
What no advisory can tell a site
The public record does not say which real-world sites run RSLinx Classic V4.50 or earlier, whether any are reachable from a segment an attacker could reach, or whether any food or agricultural processor has already been affected. No public exploitation is reported as of writing. The advisory establishes the flaw, the affected versions and the fix; only host inventory, network segmentation and the role of each RSLinx installation can establish whether a given site is exposed.
Where this leaves a South African cold chain
A search on 5 September 2026 found no verified evidence that South African packhouses, cold stores or irrigation operations run the affected RSLinx Classic version, so this article does not claim an installed base. The relevant local question is the applicability test above. A South African food or cold-chain operation with ageing Allen-Bradley equipment should treat SD1794 as a prompt to inventory its engineering hosts and name the owner of a service restart. The cost of this class of finding is not a hacked process; it is an unplanned outage at the wrong moment in a season.
Sources
- Rockwell Automation security advisory SD1794: https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1794.html
- CISA advisory ICSA-26-244-01: https://www.cisa.gov/news-events/ics-advisories/icsa-26-244-01
- NVD CVE records: https://nvd.nist.gov/vuln/detail/CVE-2026-9621 and https://nvd.nist.gov/vuln/detail/CVE-2026-9622 and https://nvd.nist.gov/vuln/detail/CVE-2026-9624 and https://nvd.nist.gov/vuln/detail/CVE-2026-9625
- ODVA EtherNet/IP (CIP network design): https://www.odva.org/
- IEC 62443 series (zone/conduit segmentation): https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
