Zimbra CVE-2026-73570: Patched in July? Check Whether Someone Got In First

Zimbra fixed CVE-2026-73570 in version 10.1.20 on 20 July 2026. The flaw lets anyone who can send mail to a Zimbra server run shell commands on it, with no login and no user action, as long as the optional zimbra-snmp package is installed and SNMP notifications are switched on. On 30 September Microsoft Threat Intelligence published what attackers did with it: web shells, root access, stolen authentication keys and mailbox archives, across organisations in more than one region and industry.

If you upgraded in July and never had SNMP notifications on, you can stop here. Everyone else has two jobs. The first is to patch. The second, which most advice skips, is to check whether someone got in before you did, because the upgrade closes the hole but does not remove a web shell, a sudoers entry or a stolen key.

Why patch dates matter more than usual here

According to Microsoft, two separate scanning tools probed the vulnerable path between 28 July and 7 August. That was after the fix shipped on 20 July but before the public disclosure on 13 August. In other words, attackers were testing servers while most admins had no reason yet to rush. A server that took the update in late August was exposed during a window when the bug was already being worked.

How the attack works, in one paragraph

Zimbra's monitoring daemon, swatchdog, watches the mail log for "service status change" lines and, when SNMP notifications are enabled, sends an snmptrap through a shell. Elastic Security Labs reproduced the chain: an attacker sends an SMTP command with a malformed address, Postfix writes it to /var/log/zimbra.log, and if that text looks like a status line, the service name part reaches /bin/sh. The result is code execution as the zimbra user. The CVE entry carries a CNA score of 8.9.

Step 1: patch, or remove the trigger

1. Upgrade every Zimbra node to 10.1.20 or later. Microsoft and Elastic both call this the only complete fix.
2. If you cannot upgrade today, Microsoft's interim advice is to uninstall the zimbra-snmp package, disable SNMP notifications, and restrict SNMP and SMTP access to trusted hosts.

Do not trust a quick exploit test as proof you are safe. Elastic found that several public proof-of-concept scripts write a payload that swatchdog never matches, so a failed test can make a vulnerable server look patched. Check the installed version instead.

Step 2: look for what attackers left behind

These checks come straight from the behaviour Microsoft describes. Run them on every mailbox and MTA node, not only the one facing the internet, because the attackers moved between nodes using Zimbra's own SSH key.

• Web shells. Look for JSP files that do not belong to your Zimbra version in the Jetty and mailboxd web application directories, including servlet work directories. Microsoft saw several copies per server, plus copies on peer nodes.
• Sudo access for the zimbra account. Run sudo -l -U zimbra and search /etc/sudoers and /etc/sudoers.d/ for NOPASSWD: ALL. The attackers created exactly that entry by briefly taking ownership of /etc/pam.d/sudo, then restored the PAM file but kept the sudoers line.
• A fake systemd service. Check for /etc/systemd/system/zimlog.service. The name sounds like part of Zimbra, but Microsoft found it installed by hand in the system-wide systemd directory, outside Zimbra's own folders, and the attackers changed its timestamps to match older system services, so sorting by date will not reveal it.
• Cron jobs and odd processes. Review crontabs for the zimbra user and root, and look for a named pipe at /tmp/s or an openssl s_client process wired to a shell, which Microsoft observed as an encrypted reverse shell.
• Log evidence. Search /var/log/zimbra.log for "Illegal address syntax" lines that contain $(, backticks or the text "Service status change", and web logs for the ZB73570 User-Agent used by the early probes.

Step 3: if you find anything, rotate the keys, not just passwords

Microsoft says the attackers went after Zimbra's central secrets rather than individual passwords. They ran zmlocalconfig -s, which prints the LDAP, MySQL, Postfix, Amavis and replication credentials, then used LDAP to pull zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret. With the pre-auth or auth-token key, an attacker can sign in as any user without knowing their password, so resetting user passwords alone does nothing. On a server with confirmed compromise, plan to:

1. Rotate the service credentials shown by zmlocalconfig -s.
2. Regenerate the pre-auth keys for each domain and the auth token key, so tokens signed with the stolen keys stop working.
3. Re-enrol two-factor authentication, since the shared secrets may have been copied.
4. Replace the zimbra SSH key in /opt/zimbra/.ssh/ on every node.
5. Treat mailbox contents as read. Microsoft observed archives being created and transferred out, which may trigger breach notification duties depending on where you operate.

In many cases rebuilding the affected nodes from a clean install and restoring data is quicker and more certain than cleaning them, given that the attackers had root and edited timestamps.

The wider lesson for self-hosted mail

This bug sat in an optional monitoring add-on, not in the mail path most admins think about. It is the same pattern as the NetScaler zero-days: the patch closes the door, but secrets taken before the patch stay valid until you rotate them. Two habits help on any self-hosted mail server. Install only the packages you use, and keep a written list of every key the server holds, so that rotating them after an incident is a checklist rather than a research project. If you are comparing self-hosted platforms, our Mailcow, Stalwart and Mailu comparison covers how each one is put together.

The same month brought security releases for Roundcube, another widely deployed webmail, including a pre-login SQL injection that is being exploited: see Roundcube 1.6.20 and 1.7.5.

Frequently asked questions

Sources: Microsoft Threat Intelligence (30 September 2026), Elastic Security Labs (23 October 2026) and NVD CVE-2026-73570.