Zimbra CVE-2026-73570: Exploited SNMP Command Injection

What to do

1. Check the Zimbra version (su - zimbra -c 'zmcontrol -v') and whether zimbra-snmp is installed (rpm -q zimbra-snmp or dpkg -l zimbra-snmp).
2. Upgrade every mailbox and MTA node to Zimbra 10.1.20 or later.
3. If you cannot upgrade yet, uninstall zimbra-snmp or disable SNMP notifications, and restrict SNMP and SMTP access to trusted hosts where you can.
4. Hunt for compromise on any server that ran the vulnerable configuration after July 28, even if it is now patched.
5. If you find compromise, rebuild the server and rotate zimbraPreAuthKey and other Zimbra secrets, the Zimbra SSH key and the credentials in localconfig.

How to check if you are affected or compromised

• Search /var/log/zimbra.log for 'Service status change' lines whose service name contains shell commands, the pattern CERT Polska published.
• List files created by the zimbra user in the last 30 days under /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ and /tmp/.
• Look for NOPASSWD sudo rules for zimbra (such as /etc/sudoers.d/81_metric), changes to /etc/pam.d/sudo, and unknown systemd units such as zimlog.service.
• Check for /opt/zimbra/final.tar.gz, AzCopy, and outbound reverse shells or openssl s_client sessions from the mail server.

What happened#

Zimbra disclosed a command injection flaw in its SNMP monitoring component in a security advisory on June 26, 2026, with a temporary mitigation (Help Net Security). The permanent fix shipped in Zimbra 10.1.20 on July 20, which describes "a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled." The CVE record, published August 13, says an unauthenticated attacker "can send specially crafted SMTP requests that may result in execution of arbitrary operating system commands as the Zimbra user." It scores the bug CVSS 3.1 8.9, with high attack complexity.

Microsoft Threat Intelligence explains the path. A crafted SMTP request puts untrusted input into SNMP notification processing. When a service-state change triggers health monitoring, swatchdog places the attacker's value into a snmptrap shell command. Microsoft saw scanning and out-of-band command-execution probes from July 28 to August 7, before public disclosure.

CERT Polska warned of an active campaign on August 17. Shadowserver flagged 155 compromised instances on August 20 and at least 274 a few days later, per Help Net Security. CISA added the CVE to KEV on August 21 with an August 24 deadline. Microsoft's September 30 report documents what attackers did next. They planted JSP web shells, escalated to root through sudo and PAM changes, and pulled secrets such as zimbraPreAuthKey and zimbraAuthTokenKey from LDAP. They moved between nodes with the Zimbra SSH key and attempted mailbox exfiltration with AzCopy.

Who is affected#

Zimbra Collaboration before 10.1.20 is affected, but only when the optional zimbra-snmp package is installed and SNMP notifications are enabled. CERT Polska frames the conditions as the SNMP trap service being enabled through the snmp_notify parameter while the swatchdog service runs, which it says is the default. The CVE record lists everything before 10.1.20 as affected. Zimbra's release post does not say whether other branches received a fix. Help Net Security counted at least 8,200 internet-facing instances not yet on 10.1.20, noting that not all are vulnerable because the configuration is not the default.

Do you really need to act?#

Only if you run self-hosted Zimbra, and then the first job is a five-minute check. Without zimbra-snmp, this CVE is not reachable. With it and notifications on, the attack needs no login and no user action, and it arrives over SMTP, which a mail server must accept from the internet. NVD and the CVE record call the complexity high, but hundreds of real compromises show that it is not a barrier in practice. Code runs as the zimbra account, which holds every mailbox, and attackers have escalated from there to root.

Upgrade to 10.1.20 even if you are not exposed. Zimbra is a frequent KEV entry, and this is its ninth addition to the catalog since February 2025.

What to do now#

1. Check the version and package: su - zimbra -c 'zmcontrol -v', then rpm -q zimbra-snmp or dpkg -l zimbra-snmp. If the package is present, assume you are exposed unless you have confirmed SNMP notifications (the snmp_notify parameter CERT Polska cites) are off.
2. Upgrade every mailbox and MTA node to 10.1.20 or later.
3. If the upgrade must wait, do what Microsoft recommends: uninstall zimbra-snmp or disable SNMP notifications, and restrict SNMP and SMTP to trusted hosts. Limiting SMTP is practical only if a mail gateway sits in front of Zimbra.
4. Hunt on any server that had the vulnerable configuration after July 28. Patching does not remove web shells or persistence.
5. If you find compromise, rebuild, then rotate all domain zimbraPreAuthKey values, the other secrets in localconfig, and the Zimbra SSH key.

How to tell if you were hit#

CERT Polska's main indicator is /var/log/zimbra.log lines reading "Service status change: ... changed from stopped to running" (or the reverse) where the service name is a shell payload. Try grep 'Service status change' /var/log/zimbra.log* and look for anything that is not a Zimbra service name. Microsoft describes the injection as a normal snmptrap call followed by shell metacharacters, a wget or curl download and a trailing #. Then list recent files owned by the zimbra user: find /opt/zimbra/jetty/webapps /opt/zimbra/jetty_base/webapps /tmp -user zimbra -mtime -30. Check /etc/sudoers.d/ for a NOPASSWD rule for zimbra (Microsoft cites 81_metric) and review /etc/pam.d/sudo. Look for systemd units such as zimlog.service, chronyd-helper.service or syslog_init.service, and for /opt/zimbra/final.tar.gz. The Microsoft post lists hashes and network indicators. It also warns that named-malware detections alone will miss redundant web shells, so check every mailbox node.

Timeline#

• Jun 26, 2026 — Zimbra discloses the SNMP command injection with a temporary mitigation.
• Jul 20, 2026 — Zimbra 10.1.20 ships the permanent fix.
• Jul 28, 2026 — Microsoft starts seeing scanning and out-of-band probes, which continue through August 7.
• Aug 13, 2026 — CVE-2026-73570 is published.
• Aug 17, 2026 — CERT Polska warns of active exploitation.
• Aug 21, 2026 — CISA adds the CVE to KEV, a day after Shadowserver flagged 155 compromised servers.
• Sep 30, 2026 — Microsoft publishes post-exploitation analysis, covered by The Hacker News.

Vulnerability records

• CVE-2026-73570 · KEV 2026-08-21 · A remote code execution vulnerability exists in Zimbra Collaboration (ZCS) before 10.1.20 when the optional zimbra-snmp package is installed and SNMP…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Zimbra — Patch Release Update: Zimbra 10.1.20 (Jul 20, 2026) blog.zimbra.com
2. CVE record — CVE-2026-73570 cve.org
3. NVD — CVE-2026-73570 nvd.nist.gov
4. CISA — Known Exploited Vulnerabilities: CVE-2026-73570 cisa.gov
5. CERT Polska — Actively exploited vulnerability in Zimbra Collaboration Suite (advisory 145/2026) moje.cert.pl
6. Microsoft Threat Intelligence — Unauthenticated command injection on internet-facing mail servers: tracking CVE-2026-73570 microsoft.com

Coverage and analysis

1. Help Net Security — Unpatched Zimbra servers are falling to CVE-2026-73570 attacks helpnetsecurity.com
2. The Hacker News — Attackers exploit Zimbra flaw to deploy web shells and harvest authentication secrets thehackernews.com