Rockwell Automation PLC Vulnerabilities Hit Water Facilities Across 12 US States

# Rockwell Automation PLC Vulnerabilities Hit Water Facilities Across 12 US States There is a particular kind of silence that follows the discovery of an internet-exposed Programmable Logic Controller (PLC). It is the silence of a network engineer realising that a device controlling the actual chemistry of a town's drinking water has been sitting on the public web, reachable by anyone with a browser and a basic curiosity. Reports indicate that this isn't a theoretical exercise in risk. Malicious actors have been targeting Rockwell Automation MicroLogix PLCs across at least 12 US states. The technical specifics are secondary to the sheer administrative failure here. These devices were not meant to be public-facing. Yet, they were. The official line from government agencies usually emphasises "resilience" and "partnerships." In practice, this is a failure of basic hygiene. When a water facility in a mid-sized American town leaves its industrial controls exposed, it isn't an "advanced persistent threat" that is the problem; it is the absence of a simple firewall rule. The second-order effect here is not just a potential outage. It is the sudden, frantic scramble of state-level regulators who realised they have no actual visibility into how many other utilities are doing the same thing. If twelve states are already flagged, the rest are likely just waiting to be indexed by a scanner. I recall a similar lack of oversight in some of the older energy grids in Oslo, though there the bureaucracy at least had the decency to pretend it was auditing the sites. It is an uncomfortable question for the insurers: at what point does "internet-exposed critical infrastructure" move from a risk to a breach of contract? Most policies have clauses about maintaining reasonable security standards. Leaving a PLC on the open web is not reasonable; it's an invitation. CISA has spent the morning adding three more entries to its Known Exploited Vulnerabilities (KEV) catalog. The additions include IBM Langflow OSS, N-central, and Apache Tomcat. For the uninitiated, the KEV isn't just a list; it is a ticking clock. Federal agencies are typically required to patch these within a window of 14 to 21 days, depending on the severity. The inclusion of Langflow is the most interesting bit here. We are seeing AI-orchestration frameworks enter the "actively exploited" phase faster than the people using them can actually understand how they work. It's one thing to patch a web server like Tomcat; it's quite another to secure an OSS AI tool that was likely deployed by a developer who bypassed the security review process entirely because they wanted to see if they could automate their emails. I suspect we will find that many organisations cannot actually meet the CISA deadline for Langflow. The paperwork usually says "patching is prioritised," but the reality is that the people with the admin keys are often different from the people who installed the AI tool in the first place. The KEV catalog is a useful tool, but it remains largely toothless for the private sector. CISA can warn and nudge, but unless there's a fine attached to the delay (something Brussels has flirted with via the NIS2 directive), the "must-patch" list is often treated as a "should-patch-if-we-have-time" list. Then we have the human element of the SonicWall situation. A zero-day vulnerability in SonicWall products has been exploited by a ransomware group that has decided it's time to stop relying on encrypted emails and start using the telephone. The INC ransomware gang is now calling victims directly. This isn't just extortion; it's psychological warfare designed to bypass the slow, methodical process of incident response. By calling a CEO or a CFO directly, they create a sense of urgency that overrides the advice of the security team. It turns a technical breach into a personal crisis. The vendor drama here is predictable. The focus will be on the "sophistication" of the zero-day. But for the Managed Service Providers (MSPs) who manage these devices for hundreds of small businesses, the zero-day is almost irrelevant. They are the ones who will bear the brunt of the downstream liability. When a client's data is encrypted and their phone rings with a demand for payment, they won't blame the "sophisticated" attackers; they will blame the MSP who told them their network was secure. I've seen this pattern before. It mirrors the way some firms handled the Ivanti vulnerabilities last year, a cycle of "emergency patches" followed by the discovery that the patch didn't actually fix the root cause, leading to a second wave of breaches. The difference here is the phone call. A ringing phone is much harder to ignore than a CVE number in a PDF. While we watch the ransomware calls and the water pumps, the volume of data leakage remains an atmospheric constant. Paidwork is currently under investigation for a breach involving over 23 million user records. ADT has seen just over 5.5 million accounts impacted. These numbers are so large they almost cease to be meaningful. We've reached a point where "millions of records" is the baseline for a Tuesday. The regulatory response is usually a fine that represents a rounding error on a quarterly earnings report and a requirement to offer victims a year of credit monitoring. It's a transactional approach to privacy that satisfies the checklist but does nothing for the person whose identity is now for sale on a forum for three dollars. The ChainDrop attack provides a different kind of scale. Over 400 NPM packages were infected with a self-propagating worm. This is the supply chain as a delivery mechanism for secrets exfiltration. The danger here isn't just to the developers who downloaded the packages, but to every single application that uses those dependencies. The irony is that we have spent years building "Software Bills of Materials" (SBOMs) to track exactly what is in our software. CISA even released new OSS and SBOM guides this week. But an SBOM only tells you what you have; it doesn't stop a worm from stealing your environment variables while you're reading the guide. The disconnect between policy and practice has never been wider. We have better guidelines than ever, more "frameworks" than we can count, and a CISA catalog that tells us exactly what to fix. Yet we still have water plants on the public internet and ransomware gangs calling executives on their mobiles. It's not because the technology is failing. It's because the paperwork is being filed by people who aren't the ones actually plugging in the hardware. As long as "compliance" is a box to be checked rather than a state of being, we can expect more water facilities to be discovered by a random scan and more CEOs to receive an unexpected call from a criminal. The KEV list now has three new entries. I wonder how many will actually be patched by the deadline.