Zimbra SNMP RCE (CVE-2026-73570): An Unauthenticated Shell Hiding in Your Homelab Mail Server

Executive Summary

CVE-2026-73570 is an unauthenticated remote code execution flaw in Zimbra Collaboration Suite (ZCS) that lets an attacker with no credentials send a single crafted SMTP message and run arbitrary shell commands on the server as the zimbra user. It is an OS command injection (CWE-78) in the SNMP-notification path, rated CVSS 3.1 8.9 by MITRE/NVD.

Why this matters:

• It is actively exploited. CERT Polska (advisory 145/2026, published 2026-08-17) confirmed an "ongoing campaign" of in-the-wild exploitation. CISA added the CVE to the Known Exploited Vulnerabilities (KEV) catalog on 2026-08-21 with an FCEB remediation due date of 2026-08-24, which has already passed.
• It targets the exact stack most homelab mail operators run. ZCS is the de-facto self-hosted mail platform, and the exploit fires on every unpatched 10.1.x install with the optional zimbra-snmp package and SNMP notifications enabled.
• The persistence is a webshell. Attackers write JSP web shells into Jetty's webapps directories. Patching closes the injection door but does not delete a shell already being served, so you have to hunt for it.
• The exposure is narrowing but not gone. Shadowserver's artifact-based scans peaked at 274 unique compromised IPs on 2026-08-22 and stood at 203 in the 2026-08-27 snapshot, with the United States leading the country breakdown.

Bottom line: If you run ZCS below 10.1.20 with zimbra-snmp installed, you are in scope. Confirm whether SNMP notifications are enabled, check your installed version, and hunt for JSP web shells in your Jetty webapps directories before you declare the instance clean. Patch alone abandons a compromised host.

The Exploit: From an SMTP Message to a Shell

The trigger conditions are narrow. The flaw fires only when three things hold at once: the optional zimbra-snmp package is installed, SNMP trap notifications are enabled via snmp_notify, and the swatchdog monitoring service is running. CERT Polska's advisory is explicit that swatchdog is on by default, so the real gate is whether you installed the SNMP package and turned on snmp_notify. That is the hook: it separates a vulnerable homelab from a safe one.

CERT Polska's own words on the scope (advisory 145/2026):

"Podatność dotyczy instancji posiadających włączoną usługę pułapek SNMP (ang. SNMP trap) za pomocą parametru snmp_notify oraz uruchomioną usługę swatchdog (domyślnie włączona)."

(The vulnerability affects instances with the SNMP trap service enabled via the snmp_notify parameter and the swatchdog service running, which is enabled by default.)

On the exploitation, the advisory states:

"Zespół CERT Polska informuje o aktywnie wykorzystywanej podatności typu OS Command Injection w Zimbra Collaboration Suite."

(The CERT Polska team is informing of an actively exploited OS Command Injection vulnerability in Zimbra Collaboration Suite.)

and, on the recommendation:

"W związku z trwającą kampanią wykorzystującą podatność, zalecamy: …"

(In connection with an ongoing campaign exploiting the vulnerability, we recommend: …)

That "trwającą kampanią" (ongoing campaign) is the operative confirmation language. CERT Polska publishes no actor attribution and no CVSS score; the 8.9 comes from MITRE/NVD.

The pipeline is SMTP to SNMP notification to shell. An unauthenticated attacker sends a specially crafted SMTP request that taints data flowing into SNMP-notification handling inside swatchdog. Somewhere in that path, untrusted input is interpolated into a shell invocation without neutralization and executes as the zimbra user. CISA's KEV description says it the same way: an unauthenticated attacker can "send specially crafted SMTP requests that may result in execution of arbitrary operating system commands as the Zimbra user."

One honest limit: no primary source discloses the exact parameter interpolated unsanitized. The NVD stops at "improper sanitization of untrusted input during SNMP notification processing," and IONIX's secondary explainer adds that the failing component is swatchdog. Anyone naming a specific parameter is speculating.

Patch Details: What 10.1.20 Fixes and What It Does Not

Zimbra shipped the permanent fix in ZCS 10.1.20 (codename Daffodil), released 2026-07-20. The vendor blog calls it "a permanent fix for the critical SNMP vulnerability disclosed in our recent security advisory" on 26th June 2026. The release also closes a stored XSS in the Classic Web Client, a mail-forwarding bypass, and three further issues (EWS access control, mailbox delegation, Nextcloud SSRF). Vendor rates deployment risk as Low.

The backport question has a concrete answer, and it is the bad kind. No 10.0.x or older-branch backport is documented anywhere in vendor material. The 10.1.20 package lineup is 10.1-series only, and the vendor table lists 10.1.20 as the sole fix release. On 10.0.x or 9.x you get no patch, only a branch upgrade. The only vendor guidance for older versions is the generic note that unsupported versions "often have the same vulnerabilities and should be upgraded."

The vendor disclosed the flaw on 2026-06-26 and shipped the fix on 2026-07-20, but CERT Polska confirmed active exploitation only on 2026-08-17, roughly three weeks later. Patch by mid-July and the window was short; the three-week gap is the exposure everyone else carried.

Scale of Compromise: What Shadowserver Is Seeing

Shadowserver runs artifact-based scans, tagging hosts with "Artifact from probable CVE-2026-73570 compromise." That is a detection signal, not per-host forensic proof. The counts:

The trend is down as patching spreads. These are current-detection figures: instances still showing artifacts in the latest scan window, not a cumulative total.

Country breakdown, latest 2026-08-27 snapshot: the United States leads (28), followed by Sweden (20), Germany (15), France (15), then Indonesia and Russia at 11 each. The Hacker News's 2026-08-24 breakdown also had the US on top (46). For a European homelab the Swedish, German, and French figures are the ones to watch, and the US lead shows this is a global scan-and-exploit, not a regionally targeted effort.

The "at least 8,200 unpatched Zimbra systems" figure, attributed to Shadowserver by eSecurityPlanet, does not hold up to primary verification: it could not be reproduced through Shadowserver's public dashboard, and it overstates exposure anyway since not every unpatched install has the optional SNMP package. Treat it as unconfirmed.

Detection: Is Your Instance Vulnerable, and Is It Compromised?

This splits into two questions with different urgency. First, am I even in scope? Second, if I am, has someone already been in?

Pre-exploit: Am I in scope?

Run these as root (or su - zimbra) and answer in order.

1. Is the zimbra-snmp package installed?

dpkg -l | grep zimbra-snmp        # Debian/Ubuntu
rpm -qa | grep zimbra-snmp        # RHEL/Rocky/CentOS

If neither command returns anything, this host is not vulnerable regardless of ZCS version. The optional package is the gate. Move on.

2. Are SNMP notifications enabled?

zmlocalconfig snmp_notify

If this returns nothing or 0, snmp_notify is off and the exploit path is closed. If it returns 1, notifications are active and you are in scope, assuming your version is below 10.1.20.

3. Which version am I running?

zmcontrol -v

Any version below 10.1.20 with the package installed and snmp_notify = 1 is directly exploitable.

In a multi-host deployment, every mailbox host runs its own SNMP package, so run these on each one, not just the primary.

Post-compromise: Hunt the webshell

This is the part most operators skip, and the part that matters. The exploit gives an attacker zimbra-user code execution, and the observed persistence is a JSP web shell written into Jetty's web application directories, which are directly web-served. CERT Polska points the hunt at files the zimbra user created in the last 30 days in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/. IONIX's secondary explainer names the artifact as JSP web shells in those same directories, consistent with the IoCs.

JSP webshell audit (highest-signal check):

find /opt/zimbra/jetty/webapps/ \
  \( -name '*.jsp' -o -name '*.jspx' -o -name '*.sh' -o -name '*.py' \) \
  -ctime -60 -ls

find /opt/zimbra/jetty_base/webapps/ \
  \( -name '*.jsp' -o -name '*.jspx' \) -ctime -60 -ls 2>/dev/null

Use -ctime (change time), not -mtime, since mtime can be forged. Flag any .jsp not part of a canonical Zimbra deployment: random alphanumeric names, or files masquerading as security.jsp, admin.jsp, monitor.jsp. Run Zimbra's integrity-check script against a known-clean snapshot and diff.

Other IoC locations from CERT Polska:

find /tmp -user zimbra -ctime -30 -ls 2>/dev/null | head -100

Unexpected processes as the zimbra user:

ps -eo user,pid,ppid,start,args --sort=-start | awk '$1 == "zimbra"' | \
  grep -vE '(zmmailboxd|swatchdog|snmptrapd|postfix|milter|zimbramonit)'

ss -tnp user:'zimbra' state established | head -50

Any bash, sh, curl, wget, python, or perl spawned by zimbra outside the standard daemon tree is a red flag.

Crontabs:

crontab -u zimbra -l 2>/dev/null
crontab -u root -l 2>/dev/null
cat /var/spool/cron/crontabs/zimbra 2>/dev/null

The standard Zimbra crontab entries are predictable (zmstat*, zmmtaconfig, zmlogrotate). Any new entry pointing at /tmp or an obfuscated script is incident-response territory.

Log location: /var/log/zimbra.log is the primary IoC location. Look for Service status change: entries in the last 30 days, especially around the SMTP service, and correlate those timestamps against any suspicious outbound connection you find.

Operator Recommendation: Patch, Then Prove It Clean

Patching ZCS to 10.1.20 is mandatory; it closes the SNMP-notification injection path so no new exploitation can occur. But patching is necessary and not sufficient. A JSP web shell already written into /opt/zimbra/jetty/webapps/ keeps running after the upgrade: still web-served, still executing with zimbra-user privileges. You would be running a clean mail daemon on top of an attacker-controlled shell. So the patch is not the finish line. You must hunt for a webshell and confirm the instance is clean before you declare it recovered.

The order:

1. Isolate and preserve. Stop ZCS with zmcontrol stop. If you may need an IR image, snapshot / and /opt/zimbra plus memory now: the upgrade restarts services and burns the volatile state (running attacker processes, open sockets).
2. Patch. Upgrade to 10.1.20. Vendor rates deployment risk as Low. This closes the injection path and stops the compromise from growing. The host is already isolated, so even if a webshell survives the upgrade, it can no longer be reached over the network.
3. Hunt. Run the post-compromise checks above against the patched host. Record exact file paths, SHA256 hashes, and stat timestamps for anything suspicious.
4. Decide: rebuild or sanitize. Zimbra's guidance is to rebuild if there is evidence the vulnerability was leveraged. CERT Polska asks operators to report suspected compromise. If the hunt comes back clean, forensically sanitize and document why you trust the instance; if not, rebuild.

The point of proving it clean: a patched server with a webshell still in /opt/zimbra/jetty/webapps/ is, from the attacker's seat, still fully compromised. The find commands take seconds; skipping them and declaring a KEV-patched host clean is how operators keep a backdoor they do not know they have.

Timeline

Confidence and Caveats

• Active exploitation: primary. CERT Polska 145/2026 (2026-08-17) and CISA KEV (2026-08-21) both confirm it.
• CVSS 8.9: primary, but from MITRE/NVD, not CERT Polska, which publishes no score; Zimbra's own wiki column reads "TBD."
• JSP webshell persistence: the strongest available characterization, but secondary. It comes from IONIX's explainer and matches CERT Polska's jetty/webapps IoC locations; the conclusion follows from the IoCs, not a named payload.
• Coin-miner payload: unverified. Reddit threads claim a coin miner, but no primary source names a malware family or payload.
• 8,200 unpatched systems: unconfirmed. Attributed to Shadowserver by secondary reporting but not reproducible through Shadowserver's public API, and it overstates real exposure since the optional SNMP package is not installed everywhere.
• Exact unsanitized parameter: not public. Any specific parameter or line of code named in secondary coverage is speculation.

One secondary reporting error is worth flagging: Dark Reading described SNMP notifications as "turned on by default in vulnerable versions." That is wrong. The zimbra-snmp package is optional and snmp_notify must be explicitly enabled; only swatchdog is on by default once the package is present.

Sources

• CERT Polska, advisory 145/2026, "Aktywnie wykorzystywana podatność w Zimbra Collaboration Suite" (2026-08-17) [primary]
• CISA Known Exploited Vulnerabilities catalog, CVE-2026-73570 entry (added 2026-08-21) [primary]
• NVD, CVE-2026-73570 (CVSS 3.1 8.9, CWE-78) [primary]
• Zimbra blog, "Patch Release Update: Zimbra 10.1.20" (2026-07-20) [vendor]
• Zimbra wiki, "Zimbra Daffodil (v10.1.20) Patch Release" and "Zimbra Security Advisories" [vendor]
• Shadowserver dashboard JSON API, tag zimbra-compromised+, unique_ips dataset (fetched 2026-08-29) [primary data]
• IONIX Threat Center, CVE-2026-73570 explainer [secondary]
• The Hacker News, "Attackers exploit Zimbra SNMP flaw" (2026-08-20/22) [secondary]
• Dark Reading, "Zimbra flaw exploitation" (2026-08-24) [secondary, flagged]