Zimbra's SNMP notifier turns a crafted SMTP message into command execution as the zimbra user

CERT Polska has published an advisory dated 17 August 2026 on CVE-2026-73570 in Zimbra Collaboration Suite: an unauthenticated attacker who can reach the SMTP service on a server that has zimbra-snmp installed and SNMP notifications enabled can execute operating system commands as the zimbra user ^[1][2]. The Polish CERT rates it critical and says active exploitation has been confirmed on the internet ^[3][4].

The path is worth understanding because it does not run through mail parsing. According to CERT Polska, the attacker sends a crafted SMTP request that injects malicious strings into the service status notification, and the swatchdog / SNMP notification process does not handle those strings safely, executing them as OS commands ^[5][6]. Execution lands with zimbra user privileges, which is enough to place files in web directories or temporary directories, and from there to install web shells, deploy tooling, or read mail and configuration data ^[7][8]. The vulnerable component is the monitoring plumbing, not the mail transfer agent, which is why a server can be compromised while sending and receiving look entirely normal, with no user action required ^[9].

CERT Polska lists three prerequisite conditions: zimbra-snmp with notifications enabled, attacker reachability to the SMTP service, and a zimbra user with write and execute permissions in accessible locations plus permitted outbound traffic ^[10][11]. The fix is ZCS 10.1.20 or later ^[12]. The advisory also recommends disabling the SNMP notification feature until patches are applied, and controlling SMTP exposure, process execution, web directory write access and egress ^[13][14]. Read those together and the sequencing is clear: disabling the notification feature removes a stated necessary precondition, so it takes the host out of scope without waiting on a maintenance window ^[1]. Patch cadence still matters, but it is the slower of the two levers.

For anyone checking whether they are already on the wrong side of this, the advisory is specific. Exploitation requests may never reach a user mailbox, so inspection has to cover SMTP sessions and commands rather than delivered mail ^[15]. Indicators include unusual "Service status change" entries in /var/log/zimbra.log, new files owned by the zimbra user, and child processes or outbound connections immediately following SMTP traffic ^[16]. CERT Polska points at new zimbra-owned files under /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ and /tmp/, at shells and curl or wget spawned under the notification process, and at suspicious administrator or mail account logins, authentication tokens and password changes ^[17][18][19]. It also flags tool downloads or C2 connections from the Zimbra host to unknown addresses, and connections onward to internal IMAP, LDAP or management ports ^[20][21].

The advisory sets out a five-stage confirmation ladder, from attempt observed with success unconfirmed, through initial execution, malware or authentication success, information theft, and subsequent compromise ^[22]. It explicitly warns that a pattern-matched request or a suspicious log string is not evidence of code execution or data theft ^[23]. That distinction is doing real work here: teams that escalate on log strings alone will burn the week rebuilding hosts that were only scanned.

Two things to watch. CERT Polska says cloud exploitation has not been confirmed in public reports but recommends checking instance role use and snapshot modifications anyway ^[24], so the question is whether hosted deployments start showing credential theft at the metadata layer. And no threat actor or malware family has been identified in the reporting so far ^[25][26], which means attribution and tooling detail are both still open, and defenders are working from behaviour rather than named indicators.