Today, over 12,000 Zimbra mail servers are openly accessible on the Internet, and the attacker knows which SNMP malformed query will enable them to get a foothold. No authentication required, no phishing, no user intervention. Just a packet crafted with knowledge of the service that most admins forgot was even running.
What is CVE-2026-73570? It is a command injection vulnerability in the SNMP notification handler component of Zimbra Collaboration with CVSS score of 8.9. The attacker who is not authenticated can craft a special request, which is then unsanitised and used in an OS command executed as the zimbra user on all the systems with an optional zimbra-snmp package installed and SNMP notifications enabled.
How The SNMP Command Injection Works
The vulnerability exists because of the way that Zimbra Collaboration handles SNMP notifications. With zimbra-snmp package installed and SNMP notifications enabled, the default associated service is swatchdog that watches out for and passes along any alerts. The input processing chain is not sanitized properly before being passed to the OS command execution context.
The attack works by sending a specially constructed request and having the string that should be used as a notification value execute as a command. No authentication or foothold is required.
The vulnerability was patched in Zimbra Collaboration release 10.1.20 dated July 20, 2026. All previous versions with zimbra-snmp package and SNMP notifications enabled are vulnerable.
From Patch To Active Exploitation
CERT Polska, the country’s national computer emergency response team, reported active exploitation of CVE-2026-73570 by August mid-month, nearly one month after the release of the patch. CISA included this vulnerability in its list of Known Exploited Vulnerabilities on August 21, 2026, issuing an order under BOD 26-04 for federal civilian agencies to patch by August 24, 2026.
This is four weeks from the availability of a public fix and a patch mandate for federal civilian agencies, and the attackers have exploited the four weeks. Shadowserver currently monitors some 12,100 Zimbra servers that are internet-reachable and mostly located in Europe (4,382) and Asia (4,492). Note that some of these servers are honeypots and patched ones.
It is not surprising that this gap is getting smaller because of the speed of modern attacks. For example, according to a Q2 2026 threat landscape report, the number of high- and critical-severity vulnerability disclosures has reached 8,539, twice as many as in the previous year. In addition, 62% of newly exploited vulnerabilities had no requirement for authentication/user interaction the exact same case as CVE-2026-73570.
Zimbra’s Own Alerting Feature Became the Entry Point
The component at fault is an alerting feature meant to notify administrators, not a user-facing mail function. That is part of why it sat unpatched on so many installs.
A snapshot from around August 20. Shadowserver’s count includes some hosts that are already patched or are honeypots, so the working exposure is somewhat smaller.
Figures from Q2 2026 vulnerability intelligence report. A remotely exploitable flaw in a widely deployed mail platform, moving from patch to active exploitation to a federal deadline within five weeks, is consistent with that broader pace.
What Happens After The Command Runs
After obtaining the ability to execute commands as the zimbra user, the usual steps for an attacker include achieving persistence, credential harvesting, and pivoting to other systems that may be accessed through the mail server. A popular way to establish persistence is deploying a webshell file in the Zimbra webroot under directories such as /opt/zimbra/jetty/webapps/ and /opt/zimbra/jetty_base/webapps/.
The administrator should examine the log files found at /var/log/zimbra.log to find any suspicious service restarts and check whether there are files that have been added to any of these directories or to the /tmp/ directory within the past 30 days. At the moment, nobody knows which group is behind the attacks or what their final objective is.
The history of exploiting vulnerabilities in Zimbra provides another perspective on the ambiguity of the situation. Various nation-states, including Winter Vivern, APT29, and APT28, have previously targeted Zimbra servers belonging to NATO member states and Ukrainian entities. Moreover, no less than four other vulnerabilities in Zimbra were marked on the KEV list by CISA this year. A server storing internal communications over several years is the type of server that interests espionage agents as well as ransomware groups.
An Unauthenticated Command Is Still Just Code Running
It is not the fact that CVE-2026-73570 falls under command injection vulnerabilities that makes it uncomfortable this type of security flaw has been around for years. The issue with CVE-2026-73570 is that the whole process goes smoothly without having to obtain any credentials, or any clicks by the employees. Detection systems will have no way to flag the anomaly in this case since no login takes place, and there is no attachment involved.
This is the gap Execution Governance seeks to bridge. Rather than detecting if the login seems suspicious, the kernel-based solution focuses on a more narrow question of whether the piece of code that wants to create files, run processes or make connections has been previously approved for this purpose by this very server. An unauthorized process generated by command injection attacks cannot answer the question; therefore, the execution will occur only within the constraints imposed by Kernel API Virtualization.
Conclusion: No Login. No Click. Just Execution.
The defining lesson from CVE-2026-73570 is how little an attacker needs before execution begins. There is no phishing step to recognize, no credential to steal, and no user action to wait for. On affected Zimbra systems with the relevant SNMP functionality enabled, a crafted unauthenticated request can cross directly from exposed service input into operating-system command execution as the zimbra user.
That makes the remediation window decisive. Zimbra released the fix in version 10.1.20 on July 20, and active exploitation was reported in August. Once exploitation succeeds, the security problem is no longer simply a vulnerable mail server. The attacker has gained an execution foothold on infrastructure that may hold years of internal communications and provide opportunities for persistence or further access.
What happens after that foothold remains less certain in this specific campaign. Webshell deployment, credential harvesting, and lateral movement are plausible post-exploitation behaviors in comparable Zimbra intrusions, but they have not been confirmed here. Defense should therefore focus on what is known: close the vulnerable path, then determine whether unauthorized execution already occurred before remediation.
Why This Threat Matters
- Initial access requires no identity compromise. An attacker does not need a password, session, MFA bypass, or employee interaction to reach the vulnerable execution path.
- The vulnerable component is operational infrastructure. The flaw sits in SNMP notification handling rather than the user-facing mail workflow most defenders would naturally associate with email compromise.
- A patch does not erase prior execution. Updating closes the vulnerability, but it does not establish whether the server was exploited before remediation.
- Command injection changes the incident immediately. Once attacker-controlled input becomes OS command execution, investigation must extend beyond vulnerability status into processes, files, persistence, and outbound activity.
- Internet exposure compresses response time. Publicly reachable services can be probed and exploited without waiting for a user or a stolen identity.
- Attribution and final objective remain unknown. Defenders should not let assumptions about espionage, ransomware, or known Zimbra-focused actors substitute for evidence from the affected system.
Where Defensive Control Must Operate
Defense must close the vulnerable service first, then govern execution if exploitation reaches the host.
Xcitium Vulnerability Assessment helps identify vulnerable and exposed infrastructure, configuration weaknesses, and remediation gaps so affected Zimbra systems can be prioritized for patching.
If exploitation succeeds, Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform addresses the execution layer. Execution Governance governs what unknown execution may do at runtime before trust exists, limiting the authority untrusted processes receive even when the initial trigger is a remotely exploitable server flaw.
Patch the Server. Hunt the Execution.
Upgrading to the fixed Zimbra release closes the known vulnerability, but systems exposed during the exploitation window should also be investigated for evidence that the boundary was crossed before the patch arrived. Zimbra logs, unexpected service activity, recently created files, web application directories, temporary locations, spawned processes, and outbound connections become part of that determination.
The important boundary is not the login screen. In this attack path, the decisive transition occurs when untrusted network input becomes code running on the server.
