Microsoft Threat Intelligence has published a detailed breakdown of attacks on CVE-2026-73570, an unauthenticated command injection in Zimbra Collaboration Suite that was fixed in 10.1.20 back in July. The writeup shows attackers going well past initial access: web shells, root escalation, and theft of the keys Zimbra uses to mint authentication tokens. If you patched late, the upgrade alone did not undo any of that.
What happened
According to Microsoft's September 30 post, a crafted SMTP request containing shell metacharacters can reach Zimbra's SNMP notification processing, where the injected commands run with the privileges of the zimbra service account. Exploitation requires the optional zimbra-snmp package to be installed and SNMP notifications to be enabled. Zimbra's security advisory describes the fix as closing a command injection in the SNMP monitoring component when SNMP notifications are enabled, lists 10.1.20 as the fixed release, and has not yet published a CVSS score.
The timeline matters. Zimbra released 10.1.20 on July 20, 2026 and disclosed the issue on August 13. Between July 28 and August 7, Microsoft saw two distinct out-of-band scanning tools probing the injection point with DNS, ICMP and HTTP callbacks to confirm command execution without delivering payloads. That activity fell after the fix shipped but before public disclosure.
Post-exploitation activity Microsoft documented includes:
- JSP web shells in Zimbra application and servlet work directories, copied across peer mailbox nodes
- Privilege escalation through PAM and sudo tampering, including NOPASSWD sudoers entries for the zimbra account
- Lateral movement over SSH using Zimbra's own cluster identity key, with rsync to move tooling between nodes
- Harvesting of
zimbraPreAuthKey,zimbraAuthTokenKey,zimbraTwoFactorAuthSecret, LDAP credentials and other local service secrets - Persistence through a timestomped systemd unit, cron, memory-backed execution, SSH authorized_keys changes and new local accounts
- A cryptominer, and AzCopy used with an attacker-supplied Azure Blob SAS URL in attempts to exfiltrate mailbox backups
Microsoft does not attribute the activity to a named actor. The post includes Defender detection names, IOCs and Advanced Hunting queries.
Why it matters
This is the identity part of the story. Preauth keys, auth token keys and two-factor secrets are what a mail server uses to trust that a session or code is legitimate. Once they have been read off a server, patching the injection bug does nothing about them; a stolen key stays useful until it is changed. Microsoft's guidance is to rotate Zimbra authentication secrets, calling out every domain zimbraPreAuthKey by name; given everything else on its list of stolen material, plan to rotate all of it on any host with evidence of compromise.
The timeline is the other lesson: scanners were testing the bug about a week after the fix shipped and before any public disclosure. Teams that wait for a CVE announcement before scheduling mail server upgrades start behind.
What to check in your environment
- Confirm every Zimbra node is on 10.1.20 or later, including secondary mailbox nodes, MTAs and DR hosts. Zimbra's advisory lists only 10.1.20 as fixed, so check how older branches are covered before assuming you are safe.
- Find out whether
zimbra-snmpis installed and SNMP notifications are on. If you can't patch right away, Microsoft says to uninstall the package, disable SNMP notifications, and restrict SNMP and SMTP to trusted hosts. - Rotate every domain
zimbraPreAuthKey, and on any host with signs of compromise, also rotate the other local service credentials, LDAP passwords and the zimbra SSH identity key, and re-enroll users' 2FA. - Inspect application and servlet work directories on every mailbox node for unexpected JSP files. Microsoft names
/jetty_base/webapps/,/mailboxd/webapps/and/work/zimbra/jsp/paths. - Review systemd units, cron,
/etc/pam.dand/etc/sudoers.dplus SSH authorized_keys and local accounts, for unexpected changes. Microsoft calls outzimlog.service,chronyd-helper.service,syslog_init.serviceand a sudoers file named81_metric. - If you run Defender for Endpoint, use the Advanced Hunting queries in Microsoft's post, and extend hunting with Sentinel or archived logs. Microsoft notes that Advanced Hunting's 30 days of raw event data no longer covers the pre-disclosure reconnaissance.
- Block and search for the published IOCs in firewall, proxy and DNS logs, and treat any reverse-shell alert from a mail server as a priority incident.