Zimbra CVE-2026-73570: What intruders did on compromised mail servers, and what to check on yours
An unauthenticated command injection in the SNMP notification path of Zimbra Collaboration was probed before public disclosure and exploited at scale afterwards. Microsoft's reconstruction shows web shells, a route to root through PAM, credential dumps and a cloud exfiltration attempt. The fix is 10.1.20. The work starts after the patch.
Microsoft Security published on 30 September 2026 a detailed account of intrusions it investigated on Zimbra Collaboration servers exposed to the internet, all of them entered through CVE-2026-73570. The vulnerability has been fixed since July and has been in CISA's Known Exploited Vulnerabilities catalogue since 21 August. What the report adds is a reconstruction of what the operators did once inside, and that is the part that decides whether an organisation that has patched is actually safe.
The vulnerability
CVE-2026-73570 is an OS command injection (CWE-78) rated CVSS 8.9 with the vector AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L. It affects Zimbra Collaboration versions prior to 10.1.20 when two conditions are met: The optional zimbra-snmp package is installed and SNMP notifications are enabled.
Under those conditions, a specially crafted SMTP request can trigger a service state change. Zimbra's monitoring component, swatchdog, then builds an snmptrap command that incorporates attacker-controlled values without neutralising shell metacharacters. The result is arbitrary command execution as the zimbra service account, without authentication.
Timeline
| Date | Event |
|---|---|
| 20 July 2026 | Zimbra releases 10.1.20 with the fix |
| 28 July to 7 August | Microsoft observes out-of-band probing of the injection point with two distinct scanning tools, before public disclosure |
| 13 August | CVE published |
| Mid-August | Mass exploitation reported; the Cloud Security Alliance cites around 155 confirmed compromises on 20 August rising to at least 274 by 22 August, with more than 8,200 vulnerable servers still exposed |
| 21 August | Added to CISA KEV with a remediation deadline of 24 August |
| 30 September | Microsoft publishes the intrusion analysis |
The pre-disclosure probing deserves attention. Operators validated command execution with callbacks to collaborator services and a CVE-specific user agent, without dropping payloads. Whoever ran those scans knew about the flaw three weeks before the rest of the world and chose to map targets quietly.
What the intruders did
Microsoft describes both automated payload delivery and hands-on-keyboard activity across more than one region and industry. The chain it reconstructs is long, and each step leaves something to look for.
Web shells. JSP web shells were written into the Jetty and mailboxd application paths, assembled from staged fragments that were deleted afterwards. Write permissions on the webroot were changed temporarily and then restored. Copies were placed on peer mailbox nodes for redundancy.
Cluster mapping. The operators used zmprov to enumerate mailbox and MTA nodes and checked for the SSH identity that Zimbra keeps at /opt/zimbra/.ssh/zimbra_identity.
Root through PAM. Using sudo-authorised Zimbra helpers, they replaced a log file with a symbolic link to /etc/pam.d/sudo, changed its ownership through zmmailboxdmgr, inserted a pam_exec hook, triggered a sudo session with the zmstat-fd helper and had the hook grant the zimbra account unrestricted sudo. The original PAM file was then restored. A patched server that went through this still has an account with root.
Persistence. A systemd unit named zimlog.service was installed by hand, assigned to the Zimbra account and given timestamps matching neighbouring services. A second unit, chronyd-helper.service, appears in another cluster of activity.
Credentials and keys. The operators ran zmlocalconfig to expose the LDAP, MySQL, Postfix, Amavis and replication passwords, then queried LDAP for zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret. A purpose-built Go tool read localconfig.xml, exported the mailbox, mailbox_metadata, mobile_devices and out_of_office tables along with the whole zimbra schema, and collected TLS certificates and private keys into a timestamped archive under /tmp.
Lateral movement and control. The existing SSH identity and rsync carried fragments, scripts and web shells to other nodes. A reverse shell used a named pipe at /tmp/s connected to openssl s_client. A multi-stage agent chain (agent2.sh, zimdown2, zimclient2) provided an interactive shell, file transfer, SOCKS5 proxying and persistence options ranging from systemd and cron to SSH authorised keys and new local accounts.
Exfiltration attempt. Recent mailbox backups were archived to /opt/zimbra/final.tar.gz and AzCopy was downloaded to push the archive to an Azure Blob container with an operator-supplied SAS URL. Microsoft notes that the evidence does not confirm the transfer completed. A separate cluster deployed a cryptominer, which is what opportunistic actors did with the same access.
Why the keys matter more than the patch
The pre-authentication key and the auth token key allow session tokens to be generated for any account without a password. The two-factor secret allows the second factor to be reproduced. If these values were read, the attacker keeps a way into every mailbox after the server is upgraded, and the only remedy is to rotate them, invalidate sessions and re-enrol second factors.
What to do now
- Upgrade to 10.1.20 or later. Where that must wait, remove the zimbra-snmp package or disable SNMP notifications, and restrict SMTP and SNMP reachability to trusted hosts.
- Hunt before you trust the patch. On every mailbox node, look for unexpected JSP files in the Jetty and mailboxd webroots and in the servlet work directories, generated _jsp.java artefacts, recent permission changes on served directories, systemd units you did not create, modifications to /etc/pam.d/sudo and /etc/sudoers.d, archives under /tmp named zimbra_dump, and final.tar.gz under /opt/zimbra. In process telemetry, perl running .swatchdog_script and spawning a shell is the signature of the injection itself.
- If anything is found, run a full response. Preserve the server before cleaning it, isolate it, rotate every credential in localconfig, the pre-auth and auth token keys, the two-factor secrets, TLS keys and the Zimbra SSH identity, invalidate sessions and review the other nodes the SSH identity could reach.
- Assess the data. A compromised mail server means mailbox content, contacts and device records may have been read. Under the GDPR, NIS2, DORA or the UAE PDPL, that assessment feeds notification decisions, and the forensic record is what keeps them proportionate.
- Reduce the blast radius. Confine the Zimbra service account with AppArmor or seccomp where feasible, keep management interfaces off the internet and make sure logs from the mail server reach a system the attacker cannot edit.
A note for insurers and boards
Mail servers are the one internet-facing system that must accept traffic from strangers. The relevant questions for a Zimbra estate are not only "is it patched" but "was it patched before 13 August", "has anyone looked for the artefacts above" and "have the signing keys been rotated". A yes to the first and a no to the other two describes a server that may still belong to someone else.
Sources
- Microsoft Security: Unauthenticated command injection on internet-facing mail servers, tracking CVE-2026-73570
- Zimbra Security Advisories
- CISA Known Exploited Vulnerabilities Catalog
- Cloud Security Alliance: Zimbra SNMP flaw under active exploitation (CVE-2026-73570)
