Satine Sentinel: August 14, 2026

A private cellular network that the energy industry treats as a walled garden turned out to be a bridge between a wind farm and a heat plant’s control systems, and it took Polish investigators three months to realize the “contractor error” that shut down a turbine last December was actually the first documented case of an attacker pivoting through that kind of network into OT. The water utility campaign this column has tracked since July picked up two more confirmed states this week, plus a volunteer defense effort aimed at exactly the utilities getting hit. A build-pipeline flaw that JetBrains said showed no signs of exploitation three weeks ago is now on CISA’s actively-exploited list, and a geospatial server flaw with no patch yet is already drawing reconnaissance scans within hours of disclosure. And a financial services vendor that quietly went dark a month ago still can’t tell the credit unions relying on it whether member data was taken.

This week: what a Russian-linked group’s pivot through a Polish energy utility’s own cellular infrastructure means for anyone using dedicated OT networks, why the water utility campaign now has a dedicated volunteer response effort behind it, and why “no known exploitation” on a CVSS 9.8 CI/CD vulnerability lasted exactly nine days.

Update: Water Utility Campaign Confirms New Jersey and Alabama, Draws a Coordinated Defense Response

What happened:

The coordinated OT campaign against US water and wastewater utilities, more than 30 Minnesota systems hit the weekend of July 26 to 27, has added two more confirmed states this week. New Jersey confirmed on August 5 that its Cape May Sewer Department and the Borough of Woodbine Water Department were both hit in near-simultaneous attacks the morning of July 27, each disrupted for roughly 12 hours. Alabama’s Childersburg Water, Sewer, and Gas Board confirmed the same day that its computerized monitoring and control network was targeted, also on July 27, and temporarily disconnected the system as a precaution. That brings the confirmed count to at least 12 states since late July, with Wisconsin, Pennsylvania, and Washington warning utilities without yet confirming attacks of their own. None of the newly confirmed utilities reported water quality or safety impact; all shifted to manual or precautionary operations.

Technical details that matter:

The pattern across the newly confirmed states matches what CISA, the FBI, and EPA have already documented for the broader campaign: attackers targeting internet-facing Rockwell Automation and Allen-Bradley MicroLogix PLCs, reaching them without needing to defeat any authentication because the standard configuration for these controllers accepts unauthenticated CIP connections on port 44818. The more significant development this week isn’t technical, it’s structural. On August 7 in Las Vegas, the National Rural Water Association and DEF CON Franklin launched the Water Watch Center, a threat-intelligence and managed-detection service aimed specifically at utilities serving fewer than 10,000 people, the size class this campaign has disproportionately hit and that makes up roughly 91 percent of the roughly 50,000 community water systems in the US. Five managed detection and response providers, Rapid7, Defendify, Legato Security, L1 Secure, and Sentinel Technologies, joined at launch. DEF CON Franklin itself dates to late 2024 and has already placed roughly 450 volunteer security professionals with small utilities across Arizona, Indiana, Oregon, Utah, Vermont, Washington, and Wyoming.

Why critical institutions should care:

The expanding state count confirms this is still an active, spreading campaign rather than a closed incident, and the newly confirmed victims are exactly the profile the Forescout exposure research flagged last week: small municipal systems without the budget or staff to run a mature vulnerability management program on their own. The Water Watch Center is a genuinely new development worth watching, not because it fixes the underlying exposure (internet-facing PLCs with no authentication), but because it’s the first sector-wide response mechanism sized correctly for the utilities actually getting hit. For any critical institution watching this campaign from the outside, electric co-ops, rural hospitals, small school districts, the lesson generalizes: if your sector has a long tail of small, under-resourced operators sharing the same vulnerable architecture, a volunteer or subsidized MDR model may reach more of them faster than another compliance mandate would. Attribution still hasn’t moved past “consistent with CyberAv3ngers tradecraft,” and this newsletter continues to treat that as an open question rather than a confirmed fact.

Key sources:

A Private Cellular Network Became the Bridge Into a Polish Power Plant’s Control Systems

What happened:

CERT Polska published a follow-up report on August 8 and 9 (presented at DEF CON in Las Vegas by CERT Polska head Marcin Dudek) disclosing a previously unknown second facility hit during the destructive December 29, 2025 campaign against Poland’s energy sector, an attack that publicly was known to have destroyed equipment at more than 30 wind and solar installations and a large combined heat-and-power plant, briefly threatening power for as many as 500,000 people. The newly disclosed second target was a smaller CHP plant supplying heat to roughly 50,000 residents. The attack shut down the plant’s steam turbine and water treatment system. Because maintenance work happened to be underway at the facility around the same time, staff initially attributed the disruption to contractor error and didn’t recognize it as a cyberattack for more than three months.

Technical details that matter:

The intrusion started on a Fortinet VPN and firewall device at an unrelated wind farm, reached over the internet and accepting locally configured accounts without multi-factor authentication. From there, the attacker identified a Teltonika RUTX50 cellular router on the same network, accessed its admin interface, and used SSH to build a tunnel into a private APN, a dedicated cellular data channel that a distribution system operator uses to carry SCADA traffic between its systems and remote substations. CERT Polska found the APN lacked client isolation, meaning any device on that private network could reach any other, letting the attacker scan across it and reach a facility with no relationship to the wind farm where they’d started. On the CHP plant’s segment of the APN, the attacker found a WAGO PFC200 PLC exposed with default administrator credentials, compromised it, enabled SSH, and used it as a bridge into the plant’s OT network, eventually reaching three Siemens PLCs before the December 29 sabotage. CERT Polska states this is the first documented real-world instance of an attacker using a private APN as a lateral-movement path into OT, and warns the underlying misconfiguration, treating a private APN as an inherently trusted, walled-off segment rather than applying client isolation and access controls within it, is common well beyond Poland. The broader campaign has been linked to the Russia-affiliated Electrum threat activity cluster, per Dragos reporting; CERT Polska’s report does not itself make an attribution.

Why critical institutions should care:

The architecture exploited here, a private APN, is specifically the kind of network that OT operators and even federal guidance (the FBI has recommended private APNs as a hardening measure) treat as a trusted perimeter precisely because it isn’t reachable from the public internet. This incident demonstrates that “not reachable from the internet” and “internally segmented” are different properties, and an attacker who reaches the APN through any single connected facility can potentially reach every other facility sharing it. Any critical institution, water utility, electric cooperative, hospital system, that relies on a shared private cellular network, a managed carrier gateway, or any third-party-operated OT connectivity should treat this as direct evidence that shared infrastructure requires the same internal segmentation and access control discipline as a corporate network, not less. The three-month detection gap is its own lesson: an unusual operational event during scheduled maintenance is exactly the scenario in which a genuine intrusion is most likely to be waved off as human error.

Key sources:

JetBrains TeamCity RCE Moves From “No Known Exploitation” to CISA’s Exploited-Vulnerabilities List in Nine Days

What happened:

JetBrains disclosed CVE-2026-63077 on July 27, 2026, a critical unauthenticated remote code execution flaw in TeamCity On-Premises, its widely used CI/CD server, and stated at the time it had no evidence of active exploitation. On August 5, CISA added the flaw to its Known Exploited Vulnerabilities catalog, confirming real-world exploitation had begun, and set a remediation deadline of August 8 for federal civilian agencies. As of this writing, no vendor or researcher has publicly disclosed the identity of the attackers, the scale of compromise, or named victims; JetBrains has not updated its advisory to confirm exploitation details.

Technical details that matter:

The vulnerability is an unsafe deserialization flaw (CWE-502) in TeamCity’s agent polling protocol, the channel distributed build agents use to check in with the central server. An attacker with mere network access to a TeamCity server over HTTP or HTTPS can exploit it without credentials and execute arbitrary operating system commands with the privileges of the TeamCity server process. Rapid7’s analysis found the vulnerable configuration stems from a permissive XStream allowlist on the server. The practical impact of compromise extends well beyond the TeamCity server itself: successful exploitation can expose stored credentials, modify server state, and compromise the integrity of build artifacts and everything downstream of them in a CI/CD pipeline, source code, signing material, deployment credentials, and the software an organization ships to its own customers. This is not TeamCity’s first appearance in this category. A 2023 authentication-bypass flaw in the same product was exploited by Russia’s SVR (APT29) specifically to pursue software supply chain access, a precedent multiple researchers cited this week as the reason to treat this flaw as more than a routine patch item.

Why critical institutions should care:

Every TeamCity On-Premises version ever shipped is affected, and the nine-day gap between “no known exploitation” and a confirmed KEV listing illustrates how little warning defenders get once a critical CI/CD flaw becomes public. Any critical institution running self-hosted build infrastructure, a hospital system’s internal software team, a utility’s OT/IT integration group, a bank’s application development shop, is exposed to the same downstream risk the water utility PLCs and the keyv npm worm covered in recent editions represent: an attacker doesn’t need to breach your production environment directly if they can compromise the pipeline that builds and deploys it. Given TeamCity’s specific history with state-sponsored software supply chain operations, organizations running on-premise instances should treat this as an emergency-patch item rather than a routine cycle, and should audit build logs and stored credentials for anything that touched an exposed server since July 27.

Key sources:

Unpatched GeoServer Zero-Day Draws Exploitation Attempts Within Hours of Public Disclosure

What happened:

A researcher publicly disclosed an unpatched SQL injection vulnerability in GeoServer, the open-source geospatial data server widely used by government mapping agencies, utilities, and GIS applications, on August 12 at 10:46 UTC. Within hours, threat intelligence firm watchTowr observed exploitation attempts beginning against internet-facing GeoServer instances. As of this writing the flaw has not been assigned a CVE identifier and no patch is available; this section is included because active exploitation is already confirmed, not merely a working proof of concept, though no named victim or successful breach has been publicly confirmed yet.

Technical details that matter:

The vulnerability sits in GeoServer’s jsonArrayContains function and allows unauthorized SQL injection; researchers note that in the default “sa” (system administrator) database configuration, this can be escalated to remote code execution. watchTowr reported hundreds of exploitation attempts originating from a small pool of IP addresses in the hours after disclosure, describing current activity as reconnaissance, attackers probing to identify vulnerable systems and triggering errors without yet demonstrating successful follow-on compromise. GeoServer has a documented recent history as a target: CISA added a separate GeoServer XXE flaw (CVE-2025-58360) to its KEV catalog in December 2025, and a 2024 GeoServer RCE (CVE-2024-36401) was exploited to build DDoS botnets and cryptomining infrastructure. Researchers note this pattern is consistent with how GeoServer gets treated generally, OGC operations are standardized and easy to build generic scanning probes against, so a newly disclosed flaw tends to draw immediate mass scanning regardless of sophistication.

Why critical institutions should care:

GeoServer’s user base skews heavily toward exactly the institutions this newsletter covers: municipal and state GIS departments, utilities mapping their own infrastructure, and emergency management agencies. An unauthenticated, unpatched, actively-scanned SQL injection vulnerability with an RCE path in software used to manage geospatial data for public infrastructure is a meaningful exposure even before a confirmed breach, because the reconnaissance phase this week is normally the precursor to opportunistic mass exploitation once a public proof of concept circulates further, not a sign the threat is contained. Organizations running GeoServer should treat the absence of a patch as the operative fact and restrict public access to instances now rather than waiting for a CVE number or a fix. This is a genuinely early-stage story, and this newsletter will follow whether it escalates from scanning to confirmed compromise.

Key sources:

A Month Later, TruStage Still Can’t Tell Credit Unions Whether Member Data Was Taken

What happened:

TruStage Financial Group, a Madison, Wisconsin-based insurer that sells life and auto insurance, retirement products, and payment protection through more than 700 credit union partners nationwide, disclosed a cybersecurity incident on July 15, 2026, and proactively shut down its network to contain it. A month later, as of this week’s reporting, the company still has not confirmed whether ransomware was involved, whether a ransom was demanded, whether any threat actor has claimed responsibility, or whether member or customer data was accessed. The outage disrupted claims processing for GAP insurance, mechanical repair coverage, and payment protection products, and disrupted access to retirement account services credit unions offer through TruStage, though the company says account balances themselves were not affected. TruStage has missed its own informal mid-August target for restoring key processes.

Technical details that matter:

Unlike most incidents this newsletter covers, TruStage has disclosed almost no technical detail: no attack vector, no indicators of compromise, no confirmation of the threat actor or malware family involved. What is publicly documented is the business impact and the legal fallout. As of a July 29 court order, at least 14 federal class-action lawsuits have been filed against TruStage in the Western District of Wisconsin, split between credit unions and businesses seeking to recover their own operational losses and individual consumers. Notably, at least one credit union, Bessemer System Federal Credit Union in Pennsylvania, is a plaintiff in its own right, seeking to recover costs the outage imposed on the credit union itself, not just its members. TruStage is currently rebuilding internal systems, including its Diligence, Metabase API, and Newsdesk platforms, in a new environment after isolating affected infrastructure.

Why critical institutions should care:

This is a third-party concentration risk story, not unlike Amgen’s cloud-vendor breach covered in the prior edition, but inverted: instead of one company’s data being exposed through a vendor, one vendor’s outage is disrupting operations and generating legal exposure across hundreds of credit unions simultaneously. Per Ncontracts’ 2026 State of Third-Party Risk Management Survey, 52 percent of financial institutions reported a third-party cyber incident in the past year, up from 46 percent the prior year. When a vendor serves a large share of a sector while holding sensitive data across many institutions, the incident stops being that vendor’s problem and becomes sector-wide exposure, and credit unions suing their own vendor over the outage’s operational costs is an early sign of how that liability gets litigated. For any critical institution relying on a small number of concentrated vendors, insurance administrators, core banking processors, claims platforms, the open question a month into this incident (has data actually been taken?) is itself the risk: member-facing institutions are currently unable to make their own notification and liability decisions because their vendor hasn’t told them what happened.

Key sources:

The Pattern This Week

Every story this week is either an attacker exploiting a trust boundary the victim assumed was solid, or an institution unable to answer a basic question about its own exposure. The Polish CHP plant operators trusted that a private APN was inherently segmented; it wasn’t. Federal agencies and defenders trusted “no known exploitation” as a reasonably durable status for a newly disclosed vulnerability; TeamCity went from that status to confirmed active exploitation in nine days, and GeoServer went from public disclosure to reconnaissance scanning in hours. And credit unions who trusted TruStage with claims processing and retirement account access are now suing TruStage because, a month later, nobody, not the vendor, not its clients, not their members, can say whether data was taken.

The throughline connects directly to what this column found in the water utility and Amgen coverage two weeks ago: the exposure increasingly lives in infrastructure, timeframes, and trust relationships the affected institution doesn’t fully control or can’t fully verify in real time. What’s new this week is the speed. Nine days from patch to confirmed exploitation on TeamCity. Hours from disclosure to scanning on GeoServer. Three months for Poland’s private APN pivot to even be recognized as an attack rather than a maintenance error. Detection speed, not just perimeter hardening, is becoming the variable that actually separates a contained incident from a widening one.

See you next week.

What Your Business Can Do This Week

If your OT environment uses a private APN, carrier-managed cellular gateway, or any shared third-party connectivity, confirm in writing whether client isolation is enforced between every device on that network, not just at its perimeter. The Polish CHP plant incident shows that “not reachable from the internet” is a different property from “internally segmented.” Ask your carrier or DSO directly whether devices on your private APN can reach each other, and treat a “yes” as an open finding requiring remediation, not an acceptable baseline.
Audit every self-hosted JetBrains TeamCity server for exposure to CVE-2026-63077 immediately, and treat any instance that was internet-reachable between July 27 and August 5 as a potential credential-rotation event. Given this vulnerability class’s history with state-sponsored software supply chain operations, patching alone (upgrading to 2025.11.7 or 2026.1.3) is necessary but not sufficient; review build logs and rotate any secrets stored in or accessible to an exposed server during that window.
If you run GeoServer instances with any public exposure, restrict access now rather than waiting for a CVE number or patch. Active scanning began within hours of disclosure and no fix currently exists; the standard advice to “wait for the vendor patch” doesn’t apply when there isn’t one yet. Take exposed instances off the public internet or place them behind authenticated access immediately.
If your organization relies on any vendor serving a concentrated share of your sector, insurance administrator, core processor, claims platform, confirm now, not during an incident, what your contract requires that vendor to disclose and on what timeline if it suffers an outage or breach. TruStage’s month-long silence on data impact is currently leaving its own clients unable to make their required notification decisions; find out whether your vendor agreements would leave you in the same position.

Update: Water Utility Campaign Confirms New Jersey and Alabama, Draws a Coordinated Defense Response

A Private Cellular Network Became the Bridge Into a Polish Power Plant’s Control Systems

JetBrains TeamCity RCE Moves From “No Known Exploitation” to CISA’s Exploited-Vulnerabilities List in Nine Days

Unpatched GeoServer Zero-Day Draws Exploitation Attempts Within Hours of Public Disclosure

A Month Later, TruStage Still Can’t Tell Credit Unions Whether Member Data Was Taken

The Pattern This Week

What Your Business Can Do This Week

Like this:

Ready to Strengthen Your Defenses?