ROCKWELL LOGIX

CVE-2021-22681 is a critical authentication-bypass vulnerability in the mechanism Rockwell Automation's Studio 5000 Logix Designer and RSLogix 5000 engineering software use to verify that a connection to a Logix-family programmable logic controller (PLC) originates from legitimate engineering software. The verification relies on a cryptographic key embedded identically in every copy of the software rather than a per-device or per-deployment secret — an attacker who extracts that key, which CISA assesses requires only "low skill level," can impersonate a trusted engineering workstation against any Logix controller reachable on the network, with no valid credentials at all. The affected product family spans the core of Rockwell's industrial control portfolio: CompactLogix, ControlLogix, GuardLogix, DriveLogix, and SoftLogix controllers used throughout manufacturing, energy, water/wastewater, and critical-infrastructure environments worldwide.

What makes this vulnerability unusual — and why it belongs in this card series alongside PrintNightmare and PaperCut rather than as a footnote — is that it has no patch and, per Rockwell's own determination, never will. The flaw is not a bug in a specific code path that can be corrected with an update; it is a foundational design choice (a static, software-embedded shared secret used as an authentication mechanism) that would require replacing the authentication scheme itself, which Rockwell has done — as CIP Security, an entirely separate, opt-in, certificate/PSK-based protocol extension — rather than attempting to retrofit the legacy mechanism. Five years after public disclosure, the vast majority of the installed base still relies on the original, permanently vulnerable verification method.

The vulnerability moved from theoretical to actively and repeatedly weaponized in 2026. CISA added CVE-2021-22681 to its Known Exploited Vulnerabilities catalog on 2026-03-05 after confirming that Iran's IRGC-CEC, operating under the CyberAv3ngers persona (see companion actor card), had pivoted from its earlier Unitronics default-credential campaign to exploiting this specific flaw against Rockwell-equipped U.S. water, energy, and government facilities — a campaign a six-agency joint advisory (AA26-097A) confirmed caused operational disruption and financial loss, and which culminated in a coordinated July 2026 attack disrupting 30-plus Minnesota water utilities.

Who is at risk today: any organization operating Logix-family Rockwell controllers reachable, directly or indirectly, from an untrusted network — a population research published in August 2026 put at over 4,400 internet-facing devices globally, nearly two-thirds of them in the United States. Because there is no patch, "unpatched" is not a temporary state for this vulnerability — it is the permanent, structural condition of every Logix controller not yet migrated to CIP Security or isolated behind compensating architectural controls.

Studio 5000 Logix Designer and RSLogix 5000 authenticate their connections to Logix controllers using a shared cryptographic key rather than a per-device certificate, a per-customer secret, or any value unique to a specific deployment. Claroty's Team82 research, along with independent findings from Kaspersky and researchers at Soonchunhyang University's Lab of Information Systems Security Assurance, demonstrated that this key can be recovered by reverse-engineering the widely-distributed engineering software itself. Once recovered, the key is valid against every Logix controller running the affected verification mechanism worldwide — it is not scoped to a customer, a site, or a device serial number. An attacker holding it can mimic a legitimate engineering workstation well enough for the controller's connection-verification logic to accept it, at which point the attacker can upload or download ladder logic, read or write controller memory and configuration, change the controller's operating mode, or push new firmware (Claroty Team82; CISA ICSA-21-056-03).

This is architecturally distinct from a typical authorization-logic bug like PrintNightmare's RPC flaw or PaperCut's request-routing confusion (both covered elsewhere in this card series), where a specific code path fails to check permissions correctly and a patch can close that specific path. Here, the verification mechanism is working exactly as designed — it is the design itself that is unsound, because a secret that must remain secret to provide security cannot be distributed, unmodified, inside a product installed on hundreds of thousands of engineering workstations. This is functionally the same failure class as hardcoded credentials (CWE-798), and it is why Rockwell's remedy is not a patch to the existing mechanism but an entirely separate, properly-designed authentication protocol: CIP Security, which uses per-device X.509 certificates or pre-shared keys rather than one secret shared across an entire product line.

The practical consequence is that CVE-2021-22681 cannot be "fixed" in the way most CVEs are — there is no version of Studio 5000 Logix Designer or RSLogix 5000 in the affected range for which the underlying shared-key mechanism has been corrected. Migration to CIP Security requires both software and, on many older controller models, hardware/firmware support that a large fraction of the installed base does not have, making a full architectural fix a multi-year (in many industrial environments, multi-decade) undertaking rather than a patch cycle.

CVE-2021-22681 was independently identified by three separate parties — Claroty's Team82, Kaspersky Lab, and researchers from South Korea's Soonchunhyang University Lab of Information Systems Security Assurance — a convergence pattern echoing PrintNightmare's multi-team discovery and suggesting the flaw was reachable through straightforward reverse engineering rather than exotic technique. Claroty published its research and CISA published the coordinated ICS advisory (ICSA-21-056-03) on 2021-02-25. At the time of disclosure, CISA explicitly stated there were no known public exploits targeting the flaw — a detail worth holding onto, because it means this vulnerability then sat in a five-year window of assessed-but-unconfirmed real-world exploitation before the picture changed decisively in 2026.

Because Rockwell determined the flaw "cannot be mitigated with a patch," the 2021 advisory's remediation guidance was architectural from the start: deploy CIP Security where supported, set controller mode switches to RUN to block remote logic changes, and isolate control-system networks behind firewalls with VPN-only remote access — guidance that has not materially changed in the five years since, because there has been no patch to supersede it. That static remediation picture changed in urgency, not in substance, when CISA added CVE-2021-22681 to the KEV catalog on 2026-03-05 (due 2026-03-26 for FCEB agencies), following confirmation that CyberAv3ngers/IRGC-CEC actors had shifted their tradecraft toward exploiting this specific flaw. A six-agency joint advisory (AA26-097A, published 2026-04-07 and updated 2026-07-22) then documented sustained exploitation across U.S. water, energy, and government infrastructure, and by August 2026 independent research confirmed over 4,400 Rockwell controllers remained internet-reachable globally — meaning the population that has actually completed a CIP Security migration or equivalent architectural mitigation, five years after disclosure, remains a minority of the installed base.

CVE-2021-22681's disclosure process itself was a model of coordination — three independent teams, a single joint CISA advisory, no leaked PoC, no rushed emergency patch. What makes this card's disclosure story distinctive is not how the vulnerability was disclosed but what the vendor concluded once it was: rather than shipping a fix, Rockwell publicly stated the flaw could not be patched and redirected the entire remediation burden onto customer architecture. That is a categorically different vendor outcome than every other vulnerability profiled in this card series, and it deserves to be read as its own kind of disclosure risk — one where "responsible disclosure was followed" does not converge, eventually, on "the vulnerability was fixed."

The five-year gap between disclosure (2021) and confirmed exploitation (2026) is the second notable feature of this vulnerability's history. It is tempting to read that gap as evidence the flaw was low-risk in practice — CISA's own 2021 language ("no known public exploits") could support that reading. A more defensible reading, given what happened next, is that ICS-specific exploitation historically requires either specialized domain knowledge or a state-level actor with the resourcing to develop and operationally validate an OT-specific technique, and that the absence of confirmed exploitation for five years reflects the depth of that barrier rather than the absence of risk. Once a resourced actor (IRGC-CEC/CyberAv3ngers) had reason to invest in OT-specific tradecraft against U.S. critical infrastructure, this five-year-old, publicly documented, permanently unpatchable flaw was sitting ready to be used at scale.

An attacker begins with network reach to a target Logix controller's EtherNet/IP (CIP) interface — typically TCP/UDP 44818, see Section 11 — either from a compromised host inside the OT network or, per the exposure data in Sections 01 and 11, directly from the internet in a meaningful minority of real-world deployments. The attacker obtains the shared cryptographic key embedded in Studio 5000 Logix Designer or RSLogix 5000 (versions in the affected range are widely available; the key does not need to be extracted from the specific target, only from any legitimate copy of the software). Using that key, the attacker crafts CIP protocol messages that satisfy the controller's connection-verification check exactly as a legitimate engineering-workstation session would — there is no secondary authentication factor, per-session challenge tied to a specific installation, or device-side allowlisting that would catch a correctly-signed-but-illegitimate connection.

Once verified, the attacker has engineering-level access equivalent to a legitimate programmer: upload or download ladder logic (enabling logic replacement, as documented in 2026 campaign reporting), read or write controller configuration and memory, change the controller's operating mode between RUN/PROGRAM/REMOTE (a physical hardware keyswitch set to RUN is one of the only controls this vulnerability cannot bypass, since it requires physical presence), and in some configurations push new firmware. Because none of this requires malware — it is legitimate engineering protocol traffic authenticated with a stolen-but-valid key — detection depends entirely on identifying anomalous sources of otherwise-normal traffic, not on identifying malicious payloads.

A companion actor card exists for this campaign: CyberAv3ngers (output/actors/2026-09-02_CYBERAV3NGERS.html) documents Iran's IRGC-CEC operating this and related exploitation under a self-presented "hacktivist" persona, formally sanctioned by U.S. Treasury/OFAC, and profiles the group's full 2023–2026 campaign arc. This is the first vulnerability card in this repository with a confirmed, independently-sourced actor-card cross-reference — see Section 10. No other threat actor or campaign has been publicly attributed to exploitation of CVE-2021-22681 specifically as of this compile.

CVE-2021-22681 is the clearest case in this card series of a vulnerability class that patching cannot solve by definition: a symmetric secret distributed, unmodified, inside every copy of widely-available client software is not a secret in any security-meaningful sense the moment more than a handful of trusted parties possess it — and Rockwell distributed it inside commercial engineering software installed on an unknowable number of workstations worldwide. This is architecturally identical to hardcoded-credential failures seen across the industry (default passwords baked into firmware, API keys committed to public repositories, shared signing keys embedded in mobile apps) — the common root is treating "not published" as equivalent to "secret," when the two properties diverge the moment the artifact containing the value is itself distributed at scale. A patch can close a logic error; a patch cannot make an already-widely-distributed value un-known again.

The industrial-control-systems context makes this specific failure mode especially durable. In enterprise IT, a hardcoded-credential vulnerability is usually resolved by a vendor pushing a new build that generates unique per-installation values and forcing a rotation — disruptive but achievable within a normal release cycle. In OT, the equivalent fix (CIP Security's certificate/PSK-based authentication) requires hardware and firmware capability that a large fraction of a decades-old installed base simply does not have, and even where the capability exists, deploying it means touching live industrial control systems where downtime has physical-world consequences and change windows are measured in months, not sprints. The 4,407-controller exposure count and the persistence of the underlying shared-key mechanism five years after disclosure is not evidence of organizational negligence so much as evidence that OT security fixes operate on a fundamentally different timescale than IT ones — a timescale attackers, once sufficiently motivated, do not have to respect.

The August 2026 finding that 19 of 22 exposed hosts in already-attacked cities also ran firmware vulnerable to a separate, patched 2017 flaw (CVE-2017-16740) reinforces the broader lesson beyond this single CVE: organizations that have not addressed their exposure to an unpatchable 2021 vulnerability have, in the same population, also failed to apply an available patch from 2017. CVE-2021-22681's "no fix exists" status is a genuine and unusual technical constraint, but the data suggests it is compounding with, rather than substituting for, more ordinary OT patch-management gaps — the organizations most exposed to this vulnerability are disproportionately likely to also be behind on the vulnerabilities that do have fixes.

The productName field (here, 1769-L32E, a CompactLogix 1769-series module) is the practical way to confirm a scanned host is a member of the affected Logix family without needing authenticated access. Because this vulnerability has no patched version to distinguish from an unpatched one, positive identification of an affected product line is the closest thing to a definitive vulnerability confirmation this section can offer — a meaningfully different situation from PrintNightmare and PaperCut, where reachability alone does not imply vulnerability.

Version not meaningfully discriminated via banner — the revision field indicates firmware version, which is useful for tracking exposure to other, patchable CVEs (such as CVE-2017-16740, referenced in Section 07) but has no bearing on CVE-2021-22681 specifically, since no firmware revision resolves the underlying shared-key design.

This is the one card in this series where the standard nmap distribution ships a dedicated, purpose-built protocol script rather than requiring third-party tooling — a reflection of EtherNet/IP's broad adoption across industrial environments rather than anything specific to this CVE. Run at subnet scale, enip-info is a practical, source-documented way to enumerate every Rockwell device on a network segment and cross-reference the results against the affected-product table in Section 05.