Water Utilities Under Attack, Plus Unauthenticated RCE Flaws in WatchGuard and SonicWall

CISA Warns of Cyberattacks Targeting Exposed Water System Controls

CISA has confirmed that Iranian-linked threat actors targeted more than 100 internet-exposed water and wastewater systems in July 2026. Here's what happened, why unmanaged remote connectivity keeps causing these incidents, and what utilities should do about it.

What You Need to Know

CISA reported malicious cyber activity against more than 100 internet-exposed systems in the U.S. Water and Wastewater Systems sector during July 2026, activity linked to Iranian threat actors. The attacks primarily targeted programmable logic controllers (PLCs) connected directly to cellular modems, a setup that creates a direct path from the public internet into operational technology environments. Utilities across at least 12 states, including Minnesota, Michigan, South Dakota, Georgia, New Jersey, and Alabama, were reportedly targeted. No significant service disruption has been reported, but the activity appears focused on operational disruption rather than data theft.

What Happened

The targeted environments included industrial control systems used to monitor and manage water and wastewater operations. Because PLCs are designed to interact directly with physical equipment, unauthorized access to them creates risks that go beyond a typical enterprise network compromise: loss of visibility into operations, unauthorized changes to physical processes, and potential interruption of service delivery. The common thread across the affected utilities was unmanaged remote connectivity. PLCs connected directly to cellular modems, without an intermediary security layer, gave attackers a straightforward route from the open internet into systems that were never designed to be internet-facing in the first place.

Why This Matters

This activity shows that public-facing OT assets remain discoverable and attractive to threat actors, even when the affected organization doesn't consider those systems part of its conventional IT attack surface. Water utilities, in particular, often run lean IT and security teams, use legacy equipment, and rely on third parties or decentralized operational staff for remote access, all of which make it easy for a PLC or remote-access appliance to end up exposed without anyone tracking it. An attacker doesn't need a data-theft payoff to cause damage here. Access to a PLC alone is enough to threaten physical processes tied to public health and safety.

What to Do

CISA's guidance centers on identifying and reducing unnecessary internet exposure. Utilities should maintain accurate inventories of internet-accessible assets, validate whether each exposed system is actually operationally required to be reachable that way, and remove direct public access where it isn't. PLCs, human-machine interfaces, engineering workstations, remote-access appliances, and cellular-connected OT devices deserve particular attention, and external attack-surface monitoring can help catch exposure that internal inventories miss, especially where third-party support or legacy connectivity has crept in over time. For systems that genuinely need remote access, avoid direct PLC connectivity and route through secure, monitored remote-access architectures instead: secure gateways or jump hosts, MFA, strong non-default credentials, timely security updates, network segmentation, least-privilege access, and continuous logging of remote sessions and OT network activity. Exposure should be reassessed periodically, since it tends to creep back in as equipment, vendors, and communications paths change.

Water and wastewater systems weren't designed with the modern internet in mind, and that gap is exactly what this activity exploited.

Ubiquiti Patches Three Maximum-Severity UniFi Vulnerabilities

Ubiquiti has fixed three max-severity flaws spanning UniFi Protect, UniFi OS, and UniFi Talk, all exploitable without authentication or user interaction. Here's what's affected, what's at stake, and how to check your environment.

What You Need to Know

Ubiquiti has released patches for three maximum-severity vulnerabilities across its UniFi product line: UniFi Protect, UniFi OS, and UniFi Talk. Tracked as CVE-2026-77537, CVE-2026-77550, and CVE-2026-77554, each can be exploited remotely with low complexity and no user interaction, which raises the urgency for any organization relying on Ubiquiti gear for network management, physical security, or voice communications. More than 100,000 UniFi OS instances have been observed online, though that figure likely includes honeypots and already-remediated systems. No active exploitation of these specific flaws has been confirmed yet, but the combination of unauthenticated access and maximum severity means that window won't stay open for long.

What's Vulnerable

CVE-2026-77537 affects the UniFi Protect video surveillance management platform and could let an unauthenticated attacker compromise a vulnerable device through improper input validation. CVE-2026-77550 is a CRLF injection vulnerability in UniFi OS that may allow a network-accessible attacker to bypass authentication entirely. CVE-2026-77554 affects the UniFi Talk VoIP application and could enable command injection, also through improper input validation. Ubiquiti has addressed all three: UniFi Protect Application version 7.2.105 and later, UniFi Talk Application version 5.3.2 and later, and UniFi OS Server versions beyond the 5.1.21 release.

Why This Matters

UniFi platforms typically sit at the center of an organization's network, camera, and communications infrastructure, not off to the side of it. A compromised UniFi management component could give an attacker a foothold to manipulate configuration, pull surveillance data, disrupt voice service, or map out other systems connected to the environment. Both cybercriminal and state-linked actors have targeted Ubiquiti products before, and the scale of internet exposure here means this isn't a niche concern limited to a handful of deployments.

What to Do

Identify every deployed UniFi Protect, UniFi Talk, and UniFi OS Server instance in your environment, verify the installed version against the fixed releases above, and apply the updates. While you're at it, check whether management interfaces are externally accessible and remove any exposure that isn't strictly necessary, then lock down legitimate administrative access with network segmentation, allowlisting, secure remote-access paths, and MFA. Review logs for unexpected administrator activity, authentication anomalies, configuration changes, new user accounts, and outbound connections from UniFi infrastructure, since those are the signs that would indicate someone got there before you patched.

Maximum-severity and unauthenticated is about as bad as a rating gets. If UniFi is running in your environment, this one goes to the top of the list.

GitLab EE Security Patch Addresses Risks in DevOps Environments

GitLab has shipped a security update for GitLab Enterprise Edition, and the stakes go well beyond a single application. Here's why a GitLab vulnerability is a software supply-chain problem, and how to handle patching it.

What You Need to Know

GitLab Enterprise Edition has released a security update addressing vulnerabilities that could affect organizations using the platform to manage source code, CI/CD pipelines, user identities, and sensitive development artifacts. Because GitLab instances centralize application code, access tokens, deployment configurations, and automation workflows, a vulnerability on an externally accessible deployment can hand an attacker a path into the entire software development lifecycle, not just one isolated application. Security teams should treat this as both a platform-maintenance task and a supply-chain security priority.

What's at Risk

Delayed updates can leave self-managed GitLab instances exposed to attacks that enable unauthorized access, disclosure of private project information, privilege escalation, or manipulation of development workflows. The impact doesn't stop at GitLab itself. If a compromised GitLab account or runner has access to CI/CD secrets, cloud credentials, container registries, package repositories, or production deployment processes, an attacker can ride that access straight into downstream environments.

Why This Matters

GitLab often ends up as one of the most trusted systems in an environment by default, since it holds the credentials and automation that build and ship everything else. That makes it a high-value target even when the vulnerability itself sounds routine. An attacker who gets into a GitLab instance isn't just reading code, they're potentially sitting on the keys to your cloud accounts, your container registries, and your production deployment pipeline.

What to Do

Start by identifying every GitLab EE deployment in your environment, including externally hosted instances, internal development environments, disaster-recovery systems, and any overlooked test environments, then validate each one's installed version against GitLab's current security release guidance. Apply the update through your established change-management process, prioritizing internet-facing instances first. Before and after patching, review administrator accounts, personal access tokens, deploy keys, runner registrations, OAuth applications, and CI/CD variables for unexpected changes, and check logs for unusual sign-in activity, new privileged accounts, project-access changes, token creation, pipeline modifications, and anomalous API use. Longer term, enforce MFA for privileged users, keep administrative interfaces off the public internet unless there's a clear reason otherwise, and make sure GitLab runners operate with least-privilege access to cloud accounts and production environments. Regular testing of backup restoration, configuration recovery, and pipeline integrity will also pay off if emergency patching is ever needed. Treat GitLab patching like the supply-chain control it actually is, not a routine maintenance checkbox, and build the habit into a repeatable workflow rather than a one-off scramble.

WatchGuard Agent Flaws Let Attackers Run Code With No Login Required

WatchGuard has disclosed two critical vulnerabilities in its Windows Agent that let an attacker run arbitrary code without ever authenticating. Here's what's affected, how the flaws work, and what to patch first.

What You Need to Know

WatchGuard has disclosed two critical vulnerabilities in the Windows WatchGuard Agent, tracked as CVE-2026-57910 and CVE-2026-57909, with CVSS v4.0 scores of 9.3 and 9.4. Both affect WatchGuard Agent versions earlier than 1.25.13.0000 and can let an unauthenticated attacker execute arbitrary code on affected endpoints, potentially gaining SYSTEM-level privileges. WatchGuard hadn't identified active exploitation as of August 25, but the unauthenticated RCE impact combined with the elevated privileges available to the service means remediation shouldn't wait.

What's Vulnerable

CVE-2026-57910 is an improper authentication issue in the agent's UDP discovery and command service. An attacker with network access can trigger the TaskExecute event handler, causing the service to retrieve and execute a malicious program, no credentials needed. It's a particularly dangerous combination: unauthenticated command handling paired with insufficient validation of the code being downloaded and run. A successful attack could lead to malware deployment, persistence, tampering with security controls, credential theft, and lateral movement from the compromised endpoint. CVE-2026-57909 is a path traversal vulnerability that also enables unauthenticated remote code execution, though exploitation requires the attacker to already have access to an adjacent network, such as a compromised internal host, a VPN-connected device, a wireless network, or a poorly segmented subnet.

Why This Matters

Neither flaw requires the agent to be exposed to the public internet to be dangerous. An attacker who's already gained a foothold anywhere on an internal network, through a VPN connection, an unmanaged wireless network, or a flat subnet, can use these flaws to escalate from that foothold to SYSTEM-level control of any Windows endpoint running the vulnerable agent. That turns a single compromised device into a springboard for much broader compromise.

What to Do

Identify every Windows endpoint running WatchGuard Agent and update to version 1.25.13.0000 or later. WatchGuard notes that CVE-2026-57910 is also addressed in versions 1.17.02.0000 and 1.17.21.0000, but CVE-2026-57909 specifically requires 1.25.13.0000. Prioritize systems reachable through internal networks, VPN segments, and unmanaged wireless environments, even where the agent isn't directly exposed to the public internet. While patching is in progress, network segmentation, access control lists, and restrictions on UDP discovery traffic can shrink the attack surface. Also watch for unusual UDP traffic, unexpected TaskExecute events, suspicious downloads, and anomalous child processes launched by the WatchGuard Agent service.

A 9.4 on an unauthenticated RCE isn't a flaw to schedule for next month's patch cycle, it's one to close out this week.

SonicWall Patches Root-Level Flaw in NetExtender Linux Client

SonicWall has fixed two vulnerabilities in its Linux VPN client, one of which can write files as root. Here's what's affected, how the flaw works, and what Linux endpoints need.

What You Need to Know

SonicWall has released updates for two high-severity vulnerabilities in the NetExtender Linux Client. The more severe, CVE-2026-66152, is a path traversal flaw with a CVSS score of 8.8 that could let an attacker write arbitrary files with root privileges. It affects NetExtender Linux Client versions 10.3.5 and earlier and is fixed in version 10.3.6. SonicWall says it has no evidence of active exploitation of either vulnerability as of the August 25, 2026 advisory, and there's no workaround, so the update is the only fix. Windows versions of NetExtender aren't affected.

What's Vulnerable

CVE-2026-66152 affects an OPSWAT tarball component used by NetExtender. An attacker can exploit path traversal during archive processing to escape the expected extraction directory and write files to unintended locations. Because the affected process runs as root, successful exploitation could overwrite sensitive system files, plant malicious content in privileged paths, establish persistence, or otherwise compromise the Linux host well beyond the VPN client itself. It requires user interaction but not attacker authentication, which makes phishing, malicious downloads, or manipulated client-update content plausible ways to trigger it. The second issue, CVE-2026-66153, carries a CVSS score of 7.0 and affects the NetExtender Service auto-upgrade process. It stems from insecure handling of temporary files and improper symbolic-link resolution, which could let a local, low-privileged attacker manipulate file paths before the service accesses them, a path to privilege escalation or unauthorized file modification, particularly on shared or multi-user Linux systems.

Why This Matters

NetExtender Linux Client is what a lot of Linux endpoints use to reach corporate networks over VPN, which makes it a piece of software that's both widely deployed and running with elevated privileges by design. A root-level file-write bug in that combination is a serious risk even without confirmed exploitation, since a single phishing click or a tampered update could be enough to trigger it.

What to Do

Identify every Linux endpoint running NetExtender, check whether it's on version 10.3.5 or earlier, and upgrade to 10.3.6 or later, there's no workaround available. Because CVE-2026-66153 involves the auto-upgrade process itself, it's also worth reviewing endpoint telemetry for unexpected changes to privileged files, suspicious archive-processing activity, unusual NetExtender upgrade behavior, or processes launched with elevated privileges following a client update. Add Linux NetExtender deployments to your routine remote-access software inventory and patch-validation workflows going forward, since this client is easy to overlook next to its Windows counterpart. A VPN client that runs as root is only as trustworthy as its last update, and this is the update that closes the gap.