Zimbra CVE-2026-73570 Exploited: Patch to 10.1.20 Now

Attackers have been exploiting a command injection flaw in Zimbra Collaboration Suite (ZCS) to plant web shells, steal authentication secrets and copy mailbox data off servers. Microsoft’s security researchers documented the campaign. It ran in the weeks between Zimbra shipping a fix in July 2026 and the bug being disclosed publicly in August. If you run a self-hosted Zimbra server below version 10.1.20, assume it may be compromised until you have checked it.

What the vulnerability is

The flaw is tracked as CVE-2026-73570 and scored 8.9 on CVSS. It is an unauthenticated operating system command injection that leads to remote code execution. An attacker triggers it with a specially crafted SMTP request, so all they need to do is send traffic to your mail port. There is no login step and no user has to click anything.

One condition applies: the optional zimbra-snmp package must be installed and SNMP notifications must be enabled. Servers without that component are not exposed through this path. Even so, upgrading is the only real fix.

The timeline matters. Attackers were working the bug before most administrators knew it existed. If you patched after disclosure, your server could already have been backdoored.

What attackers did after getting in

The initial foothold gave command execution as the zimbra service account. From there, Microsoft observed a consistent playbook:

• JSP web shells dropped into Jetty and mailboxd application paths, plus reverse shells (some encrypted with OpenSSL).
• Payloads pulled down with wget or curl.
• Persistence through cron, systemd and in-memory execution via memfd_create, including a systemd unit named zimlog.service.
• Privilege escalation by editing /etc/pam.d/sudo to allow sudo without a password.
• Secrets dumped with zmlocalconfig -s, including zimbraPreAuthKey, zimbraAuthTokenKey, zimbraTwoFactorAuthSecret and service credentials from /opt/zimbra/conf/localconfig.xml.
• Mailbox, metadata, mobile device and out-of-office tables exported with custom Go tools.
• Lateral movement to other cluster nodes using the Zimbra SSH key at /opt/zimbra/.ssh/zimbra_identity and rsync.
• A remote access agent (Zimclient2) offering shell access, file transfer and SOCKS5 proxying.

In one case the attacker archived mailbox backups to /opt/zimbra/final.tar.gz and fetched AzCopy to push data to Azure Blob Storage. Nobody has attributed the activity, and it was seen across several regions and industries.

What to do now

1. Check your version and SNMP package

su - zimbra -c "zmcontrol -v"

# RHEL, Rocky Linux, AlmaLinux
rpm -q zimbra-snmp

# Debian, Ubuntu
dpkg -l | grep zimbra-snmp

2. Patch

Take a full backup or snapshot, then upgrade to ZCS 10.1.20 or later. On multi-server setups, upgrade every node. If you cannot patch right away, follow Microsoft’s interim advice:

• Uninstall the zimbra-snmp package and disable SNMP notifications.
• Allow SNMP only from trusted monitoring hosts at the firewall.
• If your mail reaches Zimbra through a filtering gateway or relay, allow SMTP only from that gateway.

3. Hunt for compromise

Patching closes the hole but does not remove a backdoor that is already there. Check each server:

# JSP files changed recently (compare against a clean install of the same version)
find /opt/zimbra -name "*.jsp" -mtime -90 -ls

# Unexpected services, including zimlog.service
systemctl list-unit-files | grep -i zim
ls -lt /etc/systemd/system/ | head -20

# Tampered sudo PAM config
cat /etc/pam.d/sudo

# Cron jobs and SSH keys for the zimbra user
crontab -l -u zimbra
cat /opt/zimbra/.ssh/authorized_keys

# Staged archives
ls -la /opt/zimbra/*.tar.gz

Also look for new local accounts, entries in shell startup files, and outbound connections to hosts you do not recognise.

4. Rotate secrets if you find anything

If you find any sign of intrusion, assume every secret on the box has been taken. That means the preauth and auth token keys, two-factor secrets, the service credentials in localconfig.xml, and the SSH identity the nodes share. Rotate all of them. Make users reset their passwords and re-enrol two-factor authentication. Where the attacker clearly had root, rebuilding on a fresh host and migrating clean mailbox data is safer than trying to clean the old server.

How TechProvidence can help

TechProvidence runs and hardens self-hosted mail servers, Zimbra included. We can upgrade your servers to a patched release, review them for web shells and persistence, rotate compromised secrets, and lock down SNMP and SMTP exposure. For ongoing patching and monitoring of your mail infrastructure, contact us.

Quick checklist

1. Confirm ZCS version is 10.1.20 or later on every node.
2. Remove zimbra-snmp if you do not need it.
3. Firewall SNMP and, where possible, SMTP to trusted sources.
4. Search for rogue JSP files, systemd units, cron jobs and SSH keys.
5. Inspect /etc/pam.d/sudo.
6. Rotate Zimbra keys and credentials if anything looks wrong.

Source: The Hacker News