Attackers have been breaking into internet-facing Zimbra mail servers with a single crafted email, then stealing the keys Zimbra uses to sign every user's login session. The original report, by Mahesh Mandava and Rajesh Kumar Natarajan of Microsoft Threat Intelligence, traces exploitation of CVE-2026-73570 from quiet probing in July through web shells, root access and an attempt to carry off mailbox backups.
The flaw itself is not new to defenders. Zimbra fixed it in version 10.1.20 on July 20, 2026, it was publicly disclosed on August 13, and it was later added to CISA's Known Exploited Vulnerabilities catalog, as IntelFusions reported in August. What Microsoft adds is the view from inside the compromised servers, and a timeline showing attackers were testing the bug before most administrators knew it existed.
Probing began before the bug was public
Between July 28 and August 7, after the fix shipped but before disclosure, Microsoft saw two separate scanning tools probing the vulnerable code path. The probes only confirmed that commands would run: they called back to out-of-band services such as oast[.]fun, oast[.]online, dnslog[.]pp[.]ua and requestrepo[.]com, and their HTTP requests carried a telltale ZB73570 User-Agent string.
The bug sits in Zimbra's SNMP notification path. A crafted SMTP request smuggles shell characters into data that the swatchdog monitor later hands to snmptrap, so the attacker's commands run as the zimbra service account. It only works where the optional zimbra-snmp package is installed and SNMP notifications are enabled, but it needs no login and no user interaction. Microsoft saw affected organizations in more than one region and industry.
From one mail server to root across the cluster
Once in, the attackers planted JSP web shells in several application directories, sometimes loosening a folder's permissions just long enough to write the file and then restoring them. They mapped the deployment with Zimbra's own zmprov tool, then used the built-in zimbra SSH identity and rsync to copy tools and web shells to peer mailbox nodes.
To get root, one operator abused Zimbra's sudo-authorized helpers: a symlinked log file handed ownership of the sudo PAM configuration to the zimbra account, a pam_exec hook ran as root, and a permanent NOPASSWD sudoers entry was left behind. A second foothold hid as a systemd unit named zimlog.service, its timestamps altered to match older services such as sshd.service.
The prize was the signing keys
Rather than chase individual passwords, the attackers ran zmlocalconfig -s and authenticated LDAP queries to pull zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret. Microsoft notes that the auth token key lets an attacker generate a session for any account without its credentials. A dedicated Go implant, built under the module path zimbra-exfil/client-dump, automated that theft and dumped mailbox database tables. On one server the actor packed mailbox backups into /opt/zimbra/final.tar.gz and tried to push them to Azure Blob storage with Microsoft's own AzCopy tool; Microsoft could not confirm the transfer finished.
A separate chain installed zimclient2, a Go remote-access agent offering shell access, file transfer and SOCKS5 proxying over WebSocket, TLS or raw TCP.
Upgrade to 10.1.20, then rotate every Zimbra secret
Microsoft's advice is to upgrade to Zimbra 10.1.20 or later now. Where that has to wait, uninstall zimbra-snmp, disable SNMP notifications and restrict SNMP and SMTP access to trusted hosts. Patching does not evict anyone already inside, so rotate every domain zimbraPreAuthKey, review systemd units for unexpected ownership or timestamp changes, and check every mailbox node for stray JSP files. Microsoft also warns that some of the most damaging steps involved no malware at all, only a plain shell, so a reverse-shell alert on a mail server should be handled as an incident.
Selected indicators from Microsoft's report (defanged): IP addresses 117[.]107[.]25[.]243, 192[.]255[.]193[.]111, 45[.]32[.]30[.]235, 193[.]42[.]40[.]135 and 3[.]209[.]137[.]175; exfiltration target wsweb03[.]blob[.]core[.]windows[.]net; SHA-256 dee5af1c0f76b45d28bafd6e60c07bb8e391d98addf81ef8f13d073acdb3c48a and aea991f694911e321b0ab97534f2ad0291c392c0a43dabff664c563618bd036d.
The uncomfortable part is the timing. Attackers were testing this bug in the gap between a quiet fix and public disclosure, and for any server that was hit, the patch closes the door without taking back the keys.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.