On July 26, someone took down water systems across more than 30 Minnesota municipalities in a single coordinated operation. Braham’s water treatment plant went fully offline. Plymouth reported cellular communications failures at water towers and wastewater lift stations. The Minnesota IT organization (MNIT) activated a statewide response alongside the FBI and multiple federal agencies. Residents in affected communities were asked to minimize water use.

This is not a ransomware story. No ransom demand has been reported, no criminal group has claimed responsibility, and no customer data compromise has been confirmed. What distinguishes this incident is the specificity and simultaneity: operational technology systems at geographically distributed utilities hit in the same window, with at least one facility pushed to complete shutdown. That profile matches deliberate OT targeting by an actor with prior reconnaissance of the affected networks, not an opportunistic intrusion that stumbled into industrial control systems.

What the Attack Pattern Tells Practitioners

The public record on this incident is still thin, and attribution has not been made. But the technical signature warrants attention regardless of who is responsible.

Municipal water utilities are among the softer edges of critical infrastructure. Staffing is lean, IT and OT are often managed by the same small team, and remote access to SCADA and PLC systems was widely expanded during the pandemic years without corresponding security investment. The diversity of vendors across 30-plus facilities means attackers who found one point of entry with a common configuration or shared vendor may have been able to pivot laterally across the entire cluster. That scenario, a shared third-party component or remote access tool, is the most plausible explanation for how this many systems were hit in coordination. It also explains why no single named CVE has surfaced: if the entry point is a misconfigured remote access credential or a shared VPN appliance rather than a disclosed software vulnerability, there is nothing to patch.

The communications failures reported in Plymouth are worth flagging separately. Loss of cellular connectivity at water towers and wastewater lift stations suggests the attack disrupted more than just the treatment plant’s SCADA environment. Cellular-connected monitoring endpoints for lift stations are common in municipal water systems and typically have minimal authentication. If attackers were able to interfere with those endpoints, the operational blast radius extends well beyond the primary treatment facility.

For defenders outside Minnesota, the immediate question is vendor and remote access hygiene. Water utilities that share a common SCADA vendor, remote monitoring platform, or managed service provider should treat this week as a forcing function for an access audit. The specific platform used in Minnesota has not been publicly named, which makes waiting for a specific indicator pointless. The pattern is the indicator.

The Unpatched Fastjson Problem

Running parallel to the water infrastructure story is a vulnerability situation with a structural feature that practitioners rarely encounter: active exploitation confirmed in the wild, no patched version available, and no patched version coming for the affected branch.

CVE-2026-16723 is a CVSS 9.0 deserialization flaw in Alibaba’s Fastjson versions 1.2.68 through 1.2.83. ThreatBook confirmed in-the-wild exploitation beginning July 22, targeting US-based financial services, healthcare, and retail organizations running Fastjson inside Spring Boot fat-JAR applications with SafeMode disabled. Alibaba published its advisory on July 21. As of July 26, no fixed 1.x build exists and none is expected. The 1.x branch is effectively end-of-life, even if it was not formally declared as such before this week.

Fastjson has a long history as a deserialization exploit target. The library became popular in Chinese-origin enterprise Java applications and spread broadly through the ecosystem because it offered a faster JSON parsing path than Jackson. That same performance path involves resolving arbitrary class references at parse time, which is the root cause of essentially every Fastjson RCE going back to 2019. The current exploit targets configurations where SafeMode, the library’s own mitigation for this class of flaw, is disabled, which is a common default in older deployments.

The migration path is Fastjson2, but Fastjson2 is not a drop-in replacement. API signatures changed, configuration options moved, and any organization running Fastjson 1.x inside a complex Spring Boot application is looking at a real code migration effort, not a library version bump. In the interim, the only effective mitigation is enabling SafeMode via JVM flag at startup: -Dfastjson.parser.safeMode=true. That flag existed in 1.x for years and most teams never enabled it. Now it is the only available defense for a flaw under active exploitation.

The affected sectors are not accidental. Financial services and healthcare Java stacks tend to accumulate library debt because testing requirements for production changes are high and upgrade cycles are long. Fastjson 1.x is exactly the kind of dependency that survived multiple application modernization cycles because it was “working fine.” It is not working fine now.

Escalation From Monday: ShinyHunters Moves on EY With a 72-Hour Clock

Monday’s brief tracked ShinyHunters as the “Identity-First Breach Wave” campaign entering its eleventh week. As of July 27, the campaign added a high-visibility victim and a deadline: ShinyHunters posted a final ultimatum claiming a supply chain breach of Ernst & Young via a third-party IT service management platform used for internal tax-related client work. Unauthorized access ran from March 28 to April 12, 2026. Stolen material allegedly includes EY client tax documents and credentials granting access to EY’s Jira, GitHub, and Azure environments.

The July 31 deadline for public data release makes this one of the shortest-fuse extortion situations in the campaign’s history. ShinyHunters also added RingCentral and Brinks Home to its leak site in the same posting cycle, which is consistent with the group’s pattern of stacking simultaneous extortion targets to maximize negotiating pressure. EY has not confirmed ShinyHunters’ identity or the scope of the claimed access. Whether the stolen credentials translated to meaningful access into EY’s development and cloud environments, or whether the Jira and GitHub claims are leverage inflation, will not be clear until July 31 passes one way or the other.

What to Watch Before Monday

The ShinyHunters/EY deadline on July 31 is the most immediate pending development. If ShinyHunters follows through on the leak, the question shifts to what client tax data or development credentials actually appear in the dump, and whether the downstream exposure extends beyond EY to its clients. Also worth watching: CVE-2026-63077 in JetBrains TeamCity, a CVSS 9.8 unauthenticated RCE via deserialization in the agent polling protocol, disclosed July 27 with no confirmed exploitation yet. TeamCity’s history matters here. Lazarus Group weaponized CVE-2023-42793 within days of its 2023 disclosure. Any organization running TeamCity On-Premises prior to versions 2025.11.7 or 2026.1.3 should treat the exploitation clock as already running.

Security Unlocked publishes threat intelligence and strategic analysis twice weekly. This mid-week brief covers developments from 2026-07-27 through 2026-07-30.