Vulnerabilities

Zimbra SNMP flaw: Microsoft maps the full attack chain

CVE-2026-73570 lets one crafted email run commands on Zimbra servers. Microsoft details root escalation, key theft and mailbox exfiltration. Checks and fixes.

By Yaali. October 2, 2026, 6 min read, Vulnerabilities, Patching, Threat intel.

CVE-2026-73570 is an operating system command injection flaw in Zimbra Collaboration Suite (ZCS), rated CVSS 8.9. A server is exposed when it runs a release before 10.1.20, has the optional zimbra-snmp package installed and has SNMP notifications turned on. On such a server, an attacker with no account sends a crafted SMTP request, in plain terms an email, and gets commands running as the zimbra service account. Zimbra fixed it in 10.1.20 on July 20, and CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on August 21.

On September 30, Microsoft Threat Intelligence published what attackers did after that first command: probing that started more than two weeks before the flaw was publicly disclosed on August 13, a path from the zimbra account to root, theft of the keys that sign Zimbra logins, and an attempt to copy mailbox backups out to Azure storage. If your Zimbra servers were patched late, upgrading did not remove anything an attacker left behind, and the stolen keys still work until you rotate them.

Attack chain for CVE-2026-73570: a crafted email reaches the SNMP notification path, runs commands as zimbra, leads to JSP web shells, root through a PAM sudo change, theft of zmlocalconfig secrets and preauth keys, SSH movement to other Zimbra nodes and mailbox exfiltration with AzCopy

How it works

The zimbra-snmp package lets a Zimbra server report its own health to a monitoring system. A watcher process called swatchdog reads the server's logs, and when a Zimbra service changes state (for example the MTA stopping or starting) it calls the snmptrap command to send an SNMP trap, a short alert message, to the configured monitoring host. These alerts are controlled by the snmp_notify local configuration setting.

The bug is in how that notification is built. Part of the log line that swatchdog reacts to can be influenced from outside through an SMTP request, and the value ends up inside the shell command that calls snmptrap without being cleaned. An attacker who puts shell metacharacters such as ;, | or $(...) in the right place gets their own commands run by the shell, with the rights of the zimbra user. Because the trigger is mail delivery, there is no login and no user has to open anything.

The zimbra account is not root, but on a mail server it does not need to be. It owns the mail store, the Jetty web application directories and the local configuration file that holds the database, LDAP and mail transfer agent passwords.

What attackers are doing

Microsoft saw two separate scanning tools probing the injection point between July 28 and August 7, after the fix shipped and before the public write-ups. The probes made the server call out to unique subdomains on public interaction services such as oast.fun and oast.online, a cheap way to confirm commands were running. HTTP requests in this phase carried the User-Agent string ZB73570, which mirrors the CVE number.

CERT Polska reported exploitation in mid-August. By August 22, the Shadowserver Foundation counted 274 compromised internet-facing Zimbra servers, up from 155 two days earlier, and at least 8,200 instances still on unpatched releases. Not all of those are exploitable, because zimbra-snmp is not installed by default.

Microsoft's report fills in what came next:

JSP web shells written into the Jetty and mailboxd web application directories, with the staging fragments deleted afterwards.
zmlocalconfig -s run to dump the LDAP, MySQL and Postfix passwords, plus queries for the LDAP attributes zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret. The first two let anyone holding them mint valid login tokens; the third seeds two-factor codes.
Root through a change to /etc/pam.d/sudo that ran a command via pam_exec and gave the zimbra user passwordless sudo.
A systemd unit named zimlog.service, made to look like a logging component, along with cron jobs, shell startup changes, SSH keys and new local accounts.
Lateral movement to other nodes of a multi-server install with the existing key at /opt/zimbra/.ssh/zimbra_identity, using rsync to copy payloads across.
A reverse shell piped through openssl, mailbox database tables exported, backup content packed into /opt/zimbra/final.tar.gz, and AzCopy downloaded to push it to Azure Blob Storage.

Microsoft has not named the actor or said how many organisations it saw hit.

What to do

Response steps for Zimbra CVE-2026-73570: upgrade to ZCS 10.1.20 or later, disable SNMP notifications or remove zimbra-snmp if you cannot upgrade today, check logs and paths for compromise, then rebuild and rotate preauth keys and service passwords

1. Upgrade

Move every Zimbra node to ZCS 10.1.20 or later. In a multi-server install, that includes MTA, proxy and mailbox nodes, since the attackers moved between them over SSH.

2. If you cannot upgrade today

As the zimbra user, run zmlocalconfig snmp_notify and check whether the zimbra-snmp package is installed. If you do not use Zimbra's SNMP alerts, remove the package. If you need it for now, set zmlocalconfig -e snmp_notify=0 and restart the watcher with zmswatchctl restart. At the network edge, allow SNMP (UDP 161 and 162) only between Zimbra and your monitoring host.

3. Check whether you were hit

Do this even on servers that are already patched, going back to late July:

Search /var/log/zimbra.log for "Service status change" lines where the service name contains ;, |, backticks, $, URLs, IP addresses or base64 text. CERT Polska gives this as the main sign of exploitation.
List files created in the last 30 days under /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, the mailboxd webapps directory and /tmp/, and look for JSP files nobody deployed.
Check /etc/systemd/system/ for zimlog.service and any unit you cannot explain, and review /etc/pam.d/sudo, /etc/sudoers.d/, the zimbra user's crontab and authorized_keys files.
Look for /opt/zimbra/final.tar.gz, an azcopy binary on the box, and outbound connections to *.blob.core.windows.net from a mail server that has no reason to talk to Azure storage.
In web and proxy logs, search for the ZB73570 User-Agent and DNS lookups of oast.fun or oast.online.

4. If you find signs of compromise

With root gained through PAM, local cleanup cannot be trusted. Rebuild the affected nodes on 10.1.20 and restore mail data from a backup taken before the intrusion. Then rotate the domain preauth key on every domain with zmprov generateDomainPreAuthKey <domain>, the auth token key, and the LDAP, MySQL and Postfix passwords from localconfig. Replace the zimbra_identity SSH key across the cluster, and have users with two-factor authentication enrol again, because their TOTP secrets may have been read. Treat mailbox contents as read by the attacker for notification and legal purposes.

Patching late leaves a gap

Microsoft's timeline suggests the attackers worked out the bug from the fixed release: 10.1.20 shipped on July 20, probing started on July 28, and public disclosure came on August 13. For a server that was still unpatched in late July, the upgrade is the start of the job, and the compromise checks above are the rest of it. Inventory optional packages too. zimbra-snmp sits outside the default install, so it is easy for a team to miss that a server has it.

Our network penetration tests check which mail and monitoring services answer from the internet, and our security operations team can run the compromise checks above on your Zimbra estate. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

Sources: Microsoft Threat Intelligence, SecurityWeek, The Hacker News, Simply Secure Group, CISA KEV alert, Security Affairs, SOCRadar, eSecurity Planet, BleepingComputer, Zimbra wiki: Preauth.