The PLC Vulnerability Behind the US Water Utility Attacks Has No Patch, and Never Will

Since late July 2026, water and wastewater utilities across at least 12 US states have reported the same failure pattern: operators locked out of their own control systems, pressure readings that stop matching reality, and in some cases actual pressure loss or flooding. The common thread is a single class of PLC vulnerability in Rockwell Automation controllers that has been sitting unpatched, and unpatchable, since it was disclosed in 2021.

That detail is the part most coverage of this campaign skips past. It is not being framed as a breaking-news story here, because by the time an article goes up, the outage counts are already out of date. It is worth writing about because the vulnerability at the center of it breaks the assumption most security advice quietly depends on: that a fix, eventually, is a patch away.

What has actually been happening since July

The first confirmed cluster hit around 30 water systems in Minnesota between July 26 and 27, 2026. Within two weeks, the Cybersecurity and Infrastructure Security Agency and the FBI had traced related activity to utilities in at least 12 states, spanning water and wastewater treatment, energy, and government services. The attackers, assessed as Iran-linked, have reportedly been active since at least March 2026, connecting from leased foreign infrastructure and, in several documented cases, using the same engineering software a utility’s own technicians would use to configure the equipment.

The affected hardware, per FBI and EPA identification, centers on Rockwell Automation’s Allen-Bradley MicroLogix 1100 and 1400 series controllers. Once connected, the actors have downloaded project files, altered control logic, and changed what operators see on human-machine interface and SCADA displays, which is a more dangerous move than it sounds: an operator trusting a false pressure reading can make exactly the wrong call at exactly the wrong moment.

The PLC vulnerability nobody is going to patch

CVE-2021-22681 carries a CVSS score of 9.8. It is an authentication bypass in how Rockwell’s Logix family of controllers validates connections over the CIP and EtherNet/IP protocols used by engineering software to program and monitor them. The flaw was added to CISA’s Known Exploited Vulnerabilities catalog in March 2026, roughly four and a half years after it was first disclosed, once confirmed exploitation by Iran-linked actors made the case undeniable.

The reason it has stayed open that long is not neglect. The bypass is a property of how the protocol establishes trust between an engineering workstation and the controller, not a bounded coding error inside a single firmware routine. Rewriting that trust model would break compatibility with a large installed base of controllers that utilities, plants, and municipalities have no near-term plan to replace. Rockwell’s own guidance has consistently pointed toward network isolation rather than a firmware update, because a firmware update that fixes the authentication model is not really on offer.

Why "apply the patch" is the wrong instinct for OT

IT security culture is built around a patch cadence: a vulnerability is disclosed, a vendor ships a fix, and the remaining risk is measured in how fast an organization applies it. That model assumes the fix is available and that applying it does not require taking a production system offline for an extended, carefully scheduled window. Neither assumption reliably holds in operational technology.

None of this is an argument against patching where patching is possible. It is an argument against treating "patch faster" as the whole strategy, because for a meaningful slice of OT vulnerabilities, patch speed is not the variable that determines whether an attacker gets in.

How the attackers are actually getting in

The technical entry point is mundane. A Shodan-based exposure scan referenced by researchers at the Cloud Security Alliance identified 4,407 internet-facing Rockwell Automation and Allen-Bradley controllers worldwide, with 2,844 of them reachable from the United States. Separately, publicly reported scan data puts the broader figure of directly reachable ICS devices, across all vendors, above 74,000, a meaningful share still running default or no credentials at all.

That is the actual attack surface: not a sophisticated exploit chain, but a controller sitting on a routable IP address, discoverable with a search engine built for exactly this purpose, protected by whatever credentials shipped from the factory. The attackers connect the same way an authorized technician would, because from the controller’s point of view, there is often no meaningful difference between the two connections.

The fix is architectural, not a patch cycle

CISA’s guidance in the wake of this campaign has been consistent: remove PLCs and other OT devices from direct internet exposure, put them behind a segmented network reachable only through an allow-listed jump host, change default credentials immediately, and monitor for unauthorized project-file writes and logic changes rather than relying on perimeter alerts alone.

None of that is novel advice. It has been the standard ICS security recommendation for years. What this campaign demonstrates is what happens when that advice is treated as optional guidance rather than a prerequisite: the vulnerability that made it exploitable at scale has been sitting in CISA’s own catalog since March, and the exposure that made it reachable at all has been visible on a public scanner the whole time.

Why this generalizes past Rockwell

CISA’s July 22 update to advisory AA26-097A expanded the documented exploitation beyond Rockwell Automation equipment to include Schneider Electric and Siemens devices, and added detection guidance for a new technique: manipulation of reusable code modules embedded inside PLC programs, which lets an attacker’s changes persist across what looks like a routine logic update. That expansion matters more than the specific vendor list. It confirms the underlying issue is a pattern in how legacy industrial protocols were designed decades before internet exposure was a realistic threat model, not a defect isolated to one manufacturer’s product line.

For a team that has no OT footprint at all, the relevant lesson still applies one level up. Anywhere "the vendor will ship a fix" is doing the load-bearing work in a security plan, it is worth checking whether that assumption is actually true, or whether it is a patch-culture habit applied to a system where no patch is structurally possible.

A short checklist for anything that looks like this

If a system in your environment has a vulnerability with no realistic patch timeline, whether that is an OT controller, unsupported hardware, or a vendor product past end of life, the response looks the same regardless of industry:

• Confirm whether the device needs to be reachable from a routable IP at all, and if not, take it off one.
• Put it behind a segmented network with an allow-listed jump host instead of a perimeter firewall rule.
• Replace default credentials immediately, and rotate them on a schedule even without a specific incident.
• Monitor for unauthorized configuration or logic writes, not just failed login attempts.
• Track vulnerabilities without available patches as permanent exposure items, not open tickets waiting to be closed.

This is not the first time

Water utilities have been a recurring target for exactly this style of intrusion for years. A municipal authority in western Pennsylvania had a PLC defaced in late 2023 by actors targeting Israeli-made equipment left on the internet with factory-default credentials, and multiple US water systems have reported similar low-effort, high-visibility intrusions since. What is different about the 2026 campaign is scale and persistence: a state-linked actor working a known, unpatched CVE across a documented list of thousands of exposed devices, rather than an opportunistic actor stumbling onto one plant.

That history matters for how utilities plan, because it means the exposure problem was never a secret. CISA has published water-sector-specific OT guidance since at least 2021. The gap was never awareness. It was the assumption, reasonable in isolation, that a plant with limited IT staff and a tight capital budget could defer network segmentation for one more budget cycle. A campaign that has already touched a dozen states is a fairly direct argument against deferring it again.

What to watch next

CISA and the FBI have said the actor set is still expanding its target list within the water, energy, and government services sectors, and the July advisory update suggests the multi-vendor pattern will keep broadening rather than narrowing. The specific IOCs and affected IP ranges will keep changing week to week. The exposure math underneath them, tens of thousands of internet-reachable industrial controllers running old protocols with a patch that does not exist, is the part that is not going to resolve itself before the next campaign starts.