Cape May’s sewer department and Woodbine’s water department, both in New Jersey, went down for roughly 12 hours. Childersburg Water, Sewer and Gas in Alabama was hit the same way.
All three happened on July 27. That is the same day we wrote about when more than 30 Minnesota utilities were attacked. The scope of a single day’s operation took two weeks to become visible.
What are the 2026 US water system attacks? A wave of intrusions against small municipal water and wastewater utilities that began in late July 2026. Attackers reach industrial controllers exposed directly to the internet, then alter their settings. CISA has attributed the broader campaign to CyberAv3ngers, a group affiliated with Iran’s Revolutionary Guard Corps.
Three Utilities, All Hit On The Same Day
These two New Jersey-based utilities operate in small communities. None of these reported any adverse impact on water quality or safety and none used customer information.
In Alabama, again, the same trend persisted. Rockwell Automation’s industrial control systems were at the center of these three intrusions.
What is interesting about this timing is the delay in reporting. On July 30, the FBI confirmed that seven states were affected by such intrusions. On the same date, CISA issued its warning. But, even two weeks later, the number of confirmed states is 12, and, in most cases, these intrusions took place in the last week of July, not subsequently.
Four of these confirmed states are Minnesota, Michigan, South Dakota and Georgia. However, Wisconsin, Pennsylvania and Washington have merely issued alerts.
What a Water Utility Actually Runs, and Who Runs It
Programmable Logic Controller. Opens valves, runs pumps, doses chemicals. The device at the center of this campaign.
Supervisory Control and Data Acquisition. The software layer operators watch.
Human Machine Interface. The screen itself, sometimes reachable from outside the plant.
Remote Terminal Unit. A controller’s job at remote pump stations.
All of this was within reach. Attackers changed access settings instead, leaving the capability unused. That is restraint, not security.
Locked Out Rather Than Taken Over
One thing distinguishes the attacks from the image we have in our minds when we think of such an intrusion.
The perpetrators altered the systems settings in such a way that remote access would no longer be possible. They didn’t take control over the operation process. There was nobody tampering with chemical dosing or pressure levels.
This is important and it works two ways. The utilities could keep their water safe. They couldn’t maintain control over their equipment remotely anymore, which was why they were facing 12-hour downtime and had to work manually.
According to CISA, such attacks on controllers have already resulted in boil water advisories and manual operations elsewhere in the campaign. It isn’t an inconsequential result for any utility that operates with a limited number of employees.
Small Systems Carry The Exposure
The targets have certain similarities. These are municipal utilities with a few thousand customers and using equipment that responds to the Internet right away.
That’s what we said toward the end of July and proved correct – there’s no need for any sophisticated attack when the controller is accessible and has a default password. The incidents in Minnesota fit that scenario exactly, as they occurred in Unitronics, Allen-Bradley, Schneider Electric, and Siemens systems.
The regulators predicted it. According to the EPA, more than 70% of water systems it checked were not complying with all the risk and resilience regulations outlined in the Safe Drinking Water Act, including the ones operating with a default password. The agency detected vulnerabilities in 277 facilities only in 2025.
Funding has begun. The State of New York allocated $9 million in cybersecurity funding for the water industry following the July incident.
There Is No Malware To Detect
It creates very little for the security solution to detect.
The attacker probes for a controller that communicates to the internet, that authenticates to it, and modifies a configuration that can be changed by the controller, as the controller was intended to do so.
All actions in the above description are legitimate actions allowed by the equipment. A malware detection solution looking for signs of malicious code has nothing to analyze.
What decides the result is determined prior to anything: If the controller could be accessed over the Internet in the first place, and if the password protecting it is the factory default. They are both access control and segmentation issues, not detection issues.
That 12 different states in two weeks had such an issue implies that these issues were wrongly answered too many times.
Conclusion: The Controller Was Reachable. That Was Enough.
The defining lesson from this campaign is not malware sophistication. It is that industrial control equipment was reachable from the public internet and could be remotely changed through functions the devices were designed to expose.
The July incidents did not require a custom implant, destructive payload, or complex exploit chain to create operational impact. Attackers changed controller addressing and access settings, operators lost remote visibility and control, and affected utilities had to restore operations while working around systems they could no longer manage normally.
That distinction matters. In the New Jersey and Alabama cases described here, there was no reported adverse impact on water quality or safety, but disruption still lasted roughly 12 hours. Elsewhere in the broader campaign, operational effects have included pressure loss and flooding. What determines the physical consequence is not simply whether an attacker reaches a PLC, but what that specific controller is authorized to operate.
Why This Threat Matters
- The attack surface is the control interface itself. An attacker does not need malware when legitimate remote functions already provide a path to operational change.
- Configuration changes can become operational impact. Changing addresses, credentials, or controller settings can remove operator visibility and force manual operations without deploying malicious code.
- Public exposure turns remote administration into a physical risk boundary. A reachable PLC may influence pumps, valves, alarms, tank levels, or other process functions depending on its role.
- Small utilities face a structural disadvantage. Remote access helps limited teams operate distributed infrastructure, but the same convenience becomes risk when controllers are directly exposed.
- Manual operation is a resilience mechanism, not a substitute for security. It can preserve service during recovery, but only after digital control has already been disrupted.
- A quiet outcome should not be confused with a secure outcome. The fact that drinking water remained safe in the incidents described here does not reduce the significance of unauthorized access to operational control infrastructure.
Where Defensive Control Must Operate
The first defensive control point is exposure.
PLCs should not be directly reachable from untrusted networks. Remote administration should pass through controlled gateways, firewalls, tightly scoped access rules, and authenticated management paths. Programming access should exist only when operationally required, controller configurations should be checked against known-good copies, and recovery procedures should assume remote visibility may be lost.
Xcitium Vulnerability Assessment is the technically relevant Xcitium layer for this attack shape. Its role is to help security teams identify exposed services, vulnerable or outdated infrastructure, and configuration weaknesses before those conditions become attacker access paths. In OT environments, that visibility must translate into action by the asset owner: removing unnecessary internet exposure, hardening remote access, addressing vulnerable or unsupported assets, and validating the systems surrounding critical controllers.
This is an exposure and access-control problem before it is a detection problem. A security product looking only for malicious executables may never see the decisive event because the attacker is abusing capabilities the controller legitimately provides.
Take the Controller Off the Public Internet
Water utilities should prioritize four controls: remove direct public PLC access, broker necessary remote connectivity through secured infrastructure, rotate and restrict controller credentials and programming rights, and maintain validated project files plus tested manual recovery procedures.
The central lesson is simple. If an attacker can legitimately reach the controller and change what it is allowed to change, malware detection may never enter the equation. The security decision was made earlier, at the exposure and access boundary.
