Rockwell RSLinx Carries a Stack Overflow That Could Run Remote Code Across Four Sectors

The fifth member of CISA's June 16, 2026 Rockwell Automation cluster, ICSA-26-167-02, covers RSLinx — the communications software that bridges Rockwell controllers to the engineering and SCADA applications that manage them. Unlike the denial-of-service entries elsewhere in the batch, this advisory describes the most dangerous class of memory-safety defect, and it spans an unusually broad set of critical-infrastructure sectors: critical manufacturing, energy, food and agriculture, and water and wastewater.

The vulnerability, tracked as CVE-2020-13573, carries a CVSS v3.1 base score of 7.5 and a v4.0 score of 8.7. The CVE identifier's 2020 vintage is itself notable — it points to a long-lived defect in widely deployed communications software — but the technical core is what earns the advisory its place near the top of the queue.

"The affected product is vulnerable to a stack-based buffer overflow, which may allow an attacker to remotely execute arbitrary code."— CISA ICS Advisory ICSA-26-167-02, source

To understand the stakes, it helps to know where RSLinx sits in a Rockwell deployment. It is the communications backbone — the software layer through which engineering workstations, SCADA front-ends, historians, and asset-management tools discover and talk to controllers across the plant network. It speaks the device protocols on one side and presents a common interface to applications on the other. That central, trusted position is exactly what makes a flaw in it disproportionately serious: it is not a leaf node but a hub, and compromising the hub puts an attacker on the conversation between operators and the machines they control.

A stack-based buffer overflow that permits remote code execution is the difference in kind that separates this advisory from its DoS siblings. Where a denial-of-service bug costs availability, a remote-code-execution flaw costs the integrity of the system: an attacker who can run arbitrary code on the RSLinx host gains a position athwart the path between engineering workstations and the controllers themselves. That host typically sees, and can influence, the traffic that programs and commands the plant floor.

Memory safety, the unfinished work of OT

Stack-based buffer overflows are the canonical memory-safety vulnerability — corrupt the stack with attacker-controlled data, overwrite a return address, and redirect execution. The IT software world spent two decades layering defenses against exactly this: stack canaries, address-space layout randomization, non-executable stacks, and, more recently, a migration toward memory-safe languages. Industrial communications software written in C and C++ for older runtimes often predates or only partially adopts those mitigations, which is why a 2020-era buffer overflow can remain a live, advisory-worthy threat in 2026.

The defensive lesson is not that overflows are exotic — it is that they are entirely preventable with bounds checking, compiler hardening, and modern memory-safe tooling, and that the OT sector is still catching up to the secure-development practices the rest of the industry adopted long ago. For software that brokers the connection between the people who program controllers and the controllers themselves, a remote-code-execution path is close to a worst case, because it sits exactly where an attacker would most want to be.

What defenders should do

The first action is to apply Rockwell's fixed version of RSLinx, and CISA's advisory page is the authoritative source for the affected version ranges and the vendor's remediation. Because RSLinx hosts are management software rather than embedded devices, the standard endpoint disciplines apply alongside the OT mitigations: keep the host off the public internet, restrict which engineering workstations can reach it, segment the network so the communications layer is not exposed to business systems, and use hardened remote access only where genuinely required.

The breadth of affected sectors — manufacturing, energy, food and agriculture, water and wastewater — is the part operators outside heavy industry should not miss. RSLinx is plumbing that shows up wherever Rockwell gear runs critical processes, and a remote-code-execution flaw in that plumbing is a cross-sector exposure. Within the June 16 batch, ICSA-26-167-02 is the entry where the worst case is full code execution on a host that mediates access to the controllers, and it deserves priority accordingly.

What the 2020 CVE vintage tells us

The six-year-old CVE identifier is worth pausing on, because it reflects something structural about how vulnerabilities propagate through industrial software. A defect first cataloged in 2020 surfacing in a 2026 ICS advisory usually means one of a few things: the flaw was found in an upstream component or library that RSLinx incorporates, the same vulnerable code was carried forward across product versions, or the industrial-software release cadence is slow enough that a known weakness persists in deployed fleets long after it is understood. None of those scenarios is reassuring, and all of them argue for treating the advisory's publication date, not the CVE's, as the start of the exposure clock for operators who only learn of the issue now.

This longevity is also why memory-safety in operational technology is a strategic problem rather than a series of one-off bugs. Each individual buffer overflow is patchable, but the underlying condition — large bodies of C and C++ written before modern hardening was standard, maintained on long lifecycles, and deployed in environments that are slow to update — guarantees a steady stream of similar findings for years to come. The industry-wide answer is the same one the wider software world is converging on: adopt memory-safe languages for new code, apply compiler hardening uniformly, and fuzz the parsers that handle untrusted input. Until that transition reaches the OT software stack, advisories like ICSA-26-167-02 will keep arriving, and the responsible posture is to assume the communications layer is a high-value target and defend it as one rather than as inert plumbing.

For organizations triaging the five Rockwell advisories together, a useful rule of thumb: patch the remote-code-execution and account-takeover items first, the unrecoverable-fault item next, and the recoverable denial-of-service items as the maintenance window allows. RSLinx, with its RCE path and four-sector footprint, sits firmly in the first tier.