Microsoft Tracks Zimbra CVE-2026-73570 Attacks That Steal Mail and Auth Keys
Do Son 
CVE-2026-73570 attack chain, mapped to MITRE ATT&CK tactics and composited across all confirmed compromises. | Image: Microsoft
A single crafted email can give attackers a shell on an unpatched Zimbra mail server. Microsoft Threat Intelligence has now mapped how attackers exploit Zimbra CVE-2026-73570 in the wild. According to Microsoft’s analysis of the unauthenticated command injection, intruders went on to gain root, move across mail clusters, and grab mailbox data.
See a Microsoft CVE's exploit risk spike before it becomes a headline.
Get EPSS spike alertsAt a Glance
| Vulnerability | CVE-2026-73570, OS command injection in Zimbra’s SNMP notification path |
| Affected | Zimbra Collaboration Suite before 10.1.20, with the optional zimbra-snmp package and SNMP notifications enabled |
| Attacker | Unknown; Microsoft saw several distinct toolsets |
| Scale | 274 compromised servers and 8,200+ unpatched as of August 25 (Shadowserver) |
| Fix | Zimbra 10.1.20, released July 20, 2026 |
| Sources | Microsoft Threat Intelligence; Shadowserver via Help Net Security |
TL;DR
Attackers send a malicious SMTP request that injects shell commands into Zimbra’s SNMP alerts. No login or user click is needed. Microsoft saw web shells, root escalation, credential theft, and attempts to pull mailbox backups out to cloud storage.
How the Zimbra Command Injection Works
The flaw sits in how Zimbra builds SNMP notifications. An attacker sends an SMTP request laced with shell characters. Later, a service-state change triggers Zimbra’s health monitor. That monitor then feeds the attacker’s text into a shell command. As a result, the injected code runs as the zimbra service account.
Importantly, only some servers are exposed. Exploitation “requires the optional zimbra-snmp package to be installed and SNMP notifications to be enabled,” Microsoft notes. Still, Shadowserver counted more than 8,200 unpatched instances in late August.
Probing Before Disclosure
Zimbra shipped the fix on July 20. Microsoft dates public disclosure to August 13. Between July 28 and August 7, Microsoft spotted two separate scanning tools testing the exact injection point. In other words, some attackers studied the bug before most defenders knew about it.
These early probes did not drop malware. Instead, they pinged public callback services to confirm that commands ran. Some also wrote a small fingerprint script to the server’s web root.
From Web Shell to Root
Web Shells in Several Places
After the first foothold, attackers rebuilt an encoded payload from staged pieces. They then wrote JSP web shells into public Zimbra folders. Copies also landed on peer mailbox nodes.
Abusing Zimbra’s Own Helpers
Next came privilege escalation. Here, the Zimbra command injection was only the first step. The attackers swapped a writable Zimbra log file for a link to the sudo configuration. A trusted Zimbra helper then handed that file to the zimbra account. With it, they added a hook that ran as root and gave the account password-free sudo rights. Afterward, they restored the original file to cover their tracks.
For persistence, one intruder installed a fake systemd service named to look like a Zimbra logging tool. Its timestamps were changed to match older system files.
Stealing Keys, Not Just Passwords
The attackers went after Zimbra’s master secrets rather than single mailbox passwords. They pulled service credentials for LDAP, MySQL, and Postfix. Then they queried LDAP for signing and two-factor keys.
This matters a great deal. Microsoft warns that the auth token key “enables session token generation for arbitrary accounts without requiring account credentials.” Put simply, a stolen key can open any mailbox on the server.
One custom Go tool, built for Zimbra, automated this theft. It dumped config credentials, certificates, and mailbox database tables into a ZIP file for upload.
Spreading Across the Cluster
Zimbra clusters often trust each other through a shared SSH key. The attackers reused that key to jump between nodes. They copied web shells and tools with rsync and deleted the source files afterward. In another campaign, a Go-based remote access agent offered shell access, file transfer, and SOCKS5 proxying.
Mailbox Data Heads for the Cloud
On one server, the attackers archived recent mailbox backups. They then tried to upload the archive to Azure Blob Storage with Microsoft’s AzCopy tool. However, Microsoft says “available evidence does not confirm that the transfer completed successfully.”
Who Is Behind It
Microsoft has not tied Zimbra CVE-2026-73570 attacks to a named actor. It saw victims “in more than one region and industry.” The mix of automated payloads and hands-on work suggests more than one group. Help Net Security also notes that past Zimbra bugs drew both state-backed spies and criminals. Meanwhile, CERT Polska flagged active attacks on August 18, and CISA later added the flaw to its Known Exploited Vulnerabilities catalog.
What Defenders Should Do
Every team running Zimbra should check its exposure to CVE-2026-73570 today:
- Upgrade to Zimbra 10.1.20 or later right away.
- If you do not need it, remove the zimbra-snmp package or disable SNMP notifications.
- Hunt for unexpected JSP files in Zimbra web folders on every node.
- Check the sudoers file for new password-free rules for the zimbra account.
- Review systemd units, cron jobs, and SSH authorized keys for unknown entries.
- If you find signs of compromise, rotate every Zimbra service password and regenerate auth and pre-auth keys.
- Alert on AzCopy or other cloud upload tools running on mail servers.
Patching alone will not remove an intruder who already has root. So treat any exposed, unpatched server as potentially compromised until you prove otherwise.
Support Our Threat Intelligence
Find our vulnerability reports and weekly recaps helpful? Support our work today and unlock a 100% ad-free reading experience!
Buy Me a Coffee
