CVE-2026-73570: Zimbra Command Injection via SNMP Is Being Exploited—Update to 10.1.20 and Check for Compromise

In Zimbra Collaboration (ZCS) prior to version 10.1.20, an unauthenticated attacker can execute operating system commands with the privileges of the zimbra user if the optional zimbra-snmp package is installed and SNMP notifications are enabled. The trigger is a crafted SMTP request—that is, an email to the server—whose contents reach SNMP notification processing without filtering. The vulnerability is identified as CVE-2026-73570 and has a CVSS score of 8.9. Zimbra reported it on June 26, 2026, and fixed it in version 10.1.20 on July 20, 2026. CERT Polska warned of an active attack campaign on August 17, 2026; the U.S. agency CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog on August 21, 2026. The update is available.

Key points at a glance

Affected versions and updates

Only installations with zimbra-snmp installed and SNMP notifications enabled are affected. According to CERT Polska, the swatchdog service that processes notifications runs by default. Without zimbra-snmp, a server cannot be attacked through this path according to the advisory description; the update to 10.1.20 also fixes additional vulnerabilities (XSS in the Classic Web Client, bypass of forwarding restrictions, SSRF in the Nextcloud integration, access controls in EWS and mailbox delegation), so it is advisable even without SNMP.

The installed version is displayed by zmcontrol -v as the zimbra user (release number, build, platform, and build date according to the Zimbra Wiki):

su - zimbra
zmcontrol -v

Whether the vulnerable configuration is active can be checked as follows, based on SecureLayer7’s analysis:

su - zimbra
zmlocalconfig snmp_notify
zmswatchctl status
grep dosnmp /opt/zimbra/conf/swatchrc

If snmp_notify is set to true and swatchdog is active, the server is vulnerable on a version prior to 10.1.20.

What is known about the exploitation

Microsoft describes the sequence as follows: swatchdog monitors /var/log/zimbra.log and triggers an SNMP trap when service statuses change. Shell metacharacters reach this processing through a crafted SMTP request; upon a status change, swatchdog incorporates the attacker-controlled value into a call to snmptrap, which runs through a shell. The commands run with the privileges of the zimbra service account.

Timeline according to the Sources:

1. June 26, 2026: Zimbra reports the vulnerability in a security advisory with a temporary mitigation.

2. July 20, 2026: ZCS 10.1.20 is released with the permanent fix.

3. July 28 through August 7, 2026: Microsoft observes probing of the injection point using two different tools.

4. August 13, 2026: The CVE entry is published.

5. August 17, 2026: CERT Polska warns of an active campaign and publishes checking guidance.

6. August 21, 2026: CISA adds the vulnerability to the KEV catalog, with a deadline of August 24, 2026.

7. September 30, 2026: Microsoft publishes an analysis of the attacks with indicators.

According to Help Net Security, the Shadowserver Foundation counted 155 compromised Zimbra instances on the internet on August 20, 2026, rising to 274 a few days later. More than 8,200 instances had not been updated at that time, although not all of them had the vulnerable SNMP configuration.

After exploitation, according to Microsoft, the attackers deployed JSP web shells in several Jetty and mailboxd directories, established persistence through a systemd service, Cron entries, and SSH keys, and gained root privileges by manipulating the PAM configuration. They read credentials using zmlocalconfig -s, queried the zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret attributes via LDAP, archived the mail store with tar, and attempted exfiltration to Azure Blob Storage via AzCopy; according to Microsoft, it has not been confirmed whether the transfer was completed. Microsoft also identifies a coin miner. The party behind the attacks is unknown.

Immediate actions

1. Determine the version and configuration using zmcontrol -v, zmlocalconfig snmp_notify, and zmswatchctl status (see above).

2. Check for compromise and preserve logs before making changes so analysis remains possible (see next section).

3. Update to ZCS 10.1.20 or later. Zimbra, CERT Polska, CISA, and Microsoft all recommend this. Installations on older branches must move to 10.1.20 or later.

4. Implement the workaround until the update: Microsoft recommends uninstalling the zimbra-snmp package or disabling SNMP notifications. The commands are listed below.

5. Reduce exposure: According to Microsoft, restrict SNMP and SMTP to trusted hosts where mail operations allow it. SMTP remains reachable on an MTA that receives mail from the internet; in that case, updating or applying the workaround are the effective measures.

To disable SNMP notifications, SecureLayer7 provides the following commands to run as the zimbra user:

zmlocalconfig -e snmp_notify=false
zmswatchctl stop

Afterward, SNMP traps will be unavailable for service failures; monitoring should be handled another way until the update.

Checking for compromise

The vulnerability was exploited before many systems were updated. Updating to 10.1.20 closes the attack path but does not remove web shells, systemd services, or SSH keys that have already been deployed. Microsoft explicitly recommends searching for redundant persistence and rotating Zimbra authentication keys.

Logs and directories according to CERT Polska

CERT Polska identifies two checks:

1. /var/log/zimbra.log for entries in the form of Service status change: [Payload] changed from stopped to running or changed from running to stopped where suspicious strings appear in place of the service name.

2. Files created by the zimbra user within the last 30 days in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/. Hive Security provides the following for this:

find /opt/zimbra/jetty/webapps /opt/zimbra/jetty_base/webapps /tmp -user zimbra -mtime -30 -ls

Since the attacks reportedly began as early as late July, according to Microsoft, a period longer than 30 days may be appropriate.

Additional traces according to Microsoft

Network indicators

The addresses are written in defanged form as in the Microsoft analysis.

File hashes (SHA-256)

If you find something

A match means the system is considered compromised. Preserve logs and affected files before deleting anything. Because the attackers reportedly gained root privileges and established persistence in multiple locations, according to Microsoft, rebuilding on 10.1.20 or later is safer than removing individual files. Then rotate the exposed secrets: the values from zmlocalconfig -s (including LDAP and database passwords), zimbraPreAuthKey, zimbraAuthTokenKey, and the SSH keys of the zimbra user. According to Microsoft, zimbraTwoFactorAuthSecret was also queried; users’ two-factor registrations should therefore be set up again. For multi-server installations, the check applies to all nodes, as Microsoft reports that the attackers identified mailbox and MTA servers with zmprov and used the SSH key to move between servers.

Context

Affected organizations are those that operate Zimbra as their own mail server and accept mail directly from the internet. The vulnerability is reachable through regular mail receipt, without authentication and without any user interaction. The limitation to zimbra-snmp with active notifications reduces the number of attackable systems; however, anyone who has configured SNMP monitoring is in exactly this configuration. According to SecurityWeek, CISA lists 18 Zimbra vulnerabilities in the KEV catalog, four of them from 2026; previous campaigns against Zimbra have been attributed to state-sponsored groups and financially motivated criminals. CERT-FR reported the vulnerability on August 19, 2026, together with three other CVEs fixed in Zimbra. No advisory from Switzerland’s NCSC regarding CVE-2026-73570 was available at the time of research.