:quality(90):no_upscale()){kind=logo}
Four Gateway Attacks in Five Weeks Expose the Coordination Gap Between Attack and Response
STATUS: Active Exploitation Pattern SEVERITY: 8/10 AUDIENCE: Government, Defense, Critical Infrastructure Security Leads
Oct 12, 2026
·Blog
·Secure Communications
:quality(90):no_upscale())
In the past five weeks, attackers have exploited critical vulnerabilities across four widely deployed gateway categories, including email, remote access, secure content exchange, and OT protocol connectivity. Three of the incidents involved vulnerabilities that could result in root-level control. Together, these events expose two distinct coordination challenges that response planning rarely separates: communicating while an attacker may already control trusted channels, and communicating after those channels have been intentionally isolated to contain the attack.
What Happened
These vulnerabilities created two coordination problems: communicating during an active compromise and communicating during the isolation meant to stop one.
On August 21, CISA added Zimbra flaw CVE-2026-73570 to its Known Exploited Vulnerabilities catalog after attackers exploited it before public disclosure.1 By late August, Shadowserver had confirmed 274 compromised instances, with attackers using Zimbra's own trusted SSH identity to move across cluster nodes,2 an illustration of the first problem: coordinating through a channel the attacker already controls.
Three weeks later, Citrix confirmed two zero-days, CVE-2026-88771 and CVE-2026-88772, both rated 9.5, under active exploitation in NetScaler ADC and Gateway appliances.3 Mandiant and Google's Threat Intelligence Group traced the exploitation to suspected state-linked actors.4 Both flaws deliver full root-level control of the appliance.5
In late September, a secure content exchange provider took customer-facing systems offline after receiving intelligence indicating a credible threat.7 The precautionary shutdown lasted approximately nine hours and illustrates the type of isolation action defensive guidance often recommends when risk cannot be immediately ruled out. For the duration of that action, whatever coordination normally ran through those systems was unavailable.
On October 2, Moxa disclosed two vulnerabilities in its MGate protocol gateways, used across energy, water, manufacturing, and government sectors.6 One, rated 9.4, lets a read-only user corrupt device memory, and the other has no firmware fix yet. These are exactly the gateways CISA and international guidance tell operators to isolate at the first sign of compromise. That guidance stops at the network boundary and provides no instruction for maintaining coordination once it closes.
Across all four cases, the same two gaps repeat. Where an attacker may control the trusted channel, as in Zimbra and NetScaler, coordinating through that channel risks coordinating in full view of the attacker. Once an organization isolates a compromised or at-risk system, as OT guidance recommends for Moxa-class equipment, any coordination that relied on that system disappears unless a separate channel already exists.
Finding | What It Means | Operational Consequence | Open Question |
Three of the four incidents involved vulnerabilities that granted or could escalate to root-level control of critical gateway infrastructure.7 | An attacker with that level of access can monitor or manipulate anything that moves through the gateway, including any coordination that still relies on it. | Using the compromised system's own channels to coordinate a response risks coordinating in full view of the attacker who controls them. | How many organizations operating gateway infrastructure have a coordination plan that assumes the gateway itself may be compromised rather than merely unavailable? |
One organization responding to a credible threat chose to take critical infrastructure offline for several hours, illustrating how the standard defensive playbook can create its own coordination vacuum. | The standard defensive playbook, isolating the suspect system, creates its own coordination vacuum for exactly as long as the isolation lasts. | An organization with only one coordination channel loses that channel the moment it takes the correct defensive step and isolates the system it runs on. | How many organizations have a tested, separate coordination channel ready before they ever need to isolate a system, rather than improvising one during the window? |
The Moxa MGate flaws affect protocol gateways that joint CISA and international guidance already instructs critical infrastructure operators to isolate at the first sign of compromise. | Isolation guidance for OT environments addresses the network boundary but says nothing about how personnel coordinate once that boundary closes. | Field teams, control room staff, and mutual aid partners need a coordination plan that assumes the OT network itself may be the thing that's isolated, not just the IT network. | Do current OT incident response plans specify a coordination channel for the isolation window, or just the isolation step itself? |
Why This Matters
Old Assumption | Current Reality | BlackBerry Response |
If a gateway is compromised, the organization's existing communication channels can still be used to coordinate response, since the breach is a data problem, not a channel problem. | Two of four gateway vulnerabilities gave attackers root-level control, meaning the existing channel is the same system the attacker now controls. | BlackBerry® AtHoc® provides a coordination channel independent of the infrastructure under investigation, so response doesn't have to run through a system that may already be hostile. |
Taking a compromised or at-risk system offline is a complete defensive action on its own. | A recent precautionary shutdown demonstrates that isolating a system also isolates whatever coordination previously depended on it for the duration of the isolation period. | BlackBerry AtHoc is built to function specifically during isolation windows, giving teams a coordination channel that doesn't depend on the system being isolated. |
OT isolation guidance, disconnect the network the moment compromise is suspected, is a complete response on its own. | The Moxa disclosure affects exactly the class of OT gateway this guidance tells operators to isolate, and that guidance stops at the network boundary with no instruction for how personnel stay coordinated afterward. | BlackBerry AtHoc and BlackBerry® SecuSUITE® extend the same out-of-band coordination principle into OT environments, so isolating the network doesn't mean isolating the people who depend on it. |
Recommended Actions
IMMEDIATE | Confirm patch status on all affected platforms in your environment, including email gateways, remote-access infrastructure, secure content exchange systems, and OT protocol gateways. Treat any unpatched, internet-reachable instance as a potential active compromise. |
IMMEDIATE | Identify whether your organization has a coordination channel that remains available if your email or remote access system is isolated with no advance notice. |
SHORT-TERM | Build and test an out-of-band coordination channel for both scenarios explicitly: operating while a trusted system may be compromised, and operating after that system has been deliberately isolated. |
SHORT-TERM | Extend isolation and coordination planning to OT environments specifically, given that current OT isolation guidance addresses the network boundary but not what happens to coordination after it closes. |
ONGOING | Treat the length of time a coordination channel needs to keep functioning during an isolation window, hours or longer, as a planning assumption rather than an afterthought. |
BlackBerry Position
Every one of these four incidents eventually gets resolved by either patching the vulnerability or isolating the affected system. Neither action restores coordination on its own. An attacker with root access on a trusted gateway can watch everything that moves through it, and a system taken offline to stop that attacker takes its coordination function down along with it. Both scenarios point to the same requirement: a channel built to keep functioning independently of the compromised or isolated, because the moment an organization needs that channel most may be the exact moment the usual one is unavailable.
Citations:
1. Attackers Exploit Zimbra SNMP Flaw for Unauthenticated Remote Code Execution (The Hacker News, coverage of CVE-2026-73570 active exploitation, August 20, 2026).
2. Hackers Breached Over 270 Zimbra Servers in Ongoing Attacks (BleepingComputer, coverage of Zimbra server compromises tracked by Shadowserver, August 25, 2026).
3. Warning: Two Unpatched Citrix NetScaler RCE Zero-Days Under Active Exploitation (The Hacker News, Citrix confirms NetScaler zero-day exploitation, September 27, 2026).
4. Defending Against Active Exploitation of Citrix NetScaler ADC and Gateway Appliances (Google Cloud Blog, authored by Mandiant, Google Threat Intelligence Group, and Mandiant Services; analysis and defensive guidance related to active exploitation of Citrix NetScaler vulnerabilities CVE-2026-88772 and CVE-2026-88771, September 29, 2026).
5. Citrix NetScaler Zero-Days Highlight Recurring Root-Access Risk (TechTimes, analysis of recurring NetScaler root-access vulnerability patterns, September 30, 2026).
6. Moxa MGate Vulnerabilities Put Industrial Protocol Gateways at Risk (SecurityOnline, coverage and analysis of the Moxa MGate vulnerabilities CVE-2026-86325 and CVE-2026-86326, including affected products, severity ratings, and mitigation guidance. October 2, 2026).
7. Kiteworks patches max severity code injection vulnerability (BleepingComputer, reported on CVE-2026-54154 affecting Kiteworks Email Protection Gateway (EPG), October 1, 2026).
:quality(90):no_upscale())