Zimbra CVE-2026-73570: Unauthenticated SNMP Command Injection to the zimbra User, Exploited and on KEV

Introduction

CISA added CVE-2026-73570 to KEV on August 21 after CERT Polska reported active exploitation around August 17. The bug is OS command injection (CWE-78, CVSS 8.9) in Zimbra Collaboration Suite's SNMP monitoring stack. If the optional zimbra-snmp package is installed and SNMP notifications (snmp_notify) are enabled, an unauthenticated remote attacker can run commands as the zimbra user. That is not automatically root — it is the account that owns mailboxes, Jetty, and most of /opt/zimbra. Fixed in ZCS 10.1.20. Every older 10.1 (and anything still on that SNMP path) with snmp_notify on is in play.

What Happened

Zimbra's swatchdog, bundled with zimbra-snmp, fails to sanitize input used in OS commands when it handles SNMP notifications. Once that package is present, swatchdog runs by default; the extra gate is snmp_notify. Some write-ups describe the trigger arriving through crafted SMTP-adjacent notification handling — the operational takeaway is: you do not need a Zimbra admin session.

Zimbra 10.1.20 (blogged as a patch release containing a permanent SNMP fix plus other issues: mail-forwarding restriction bypass, EWS access control, mailbox-delegation authz, Nextcloud integration SSRF) is the floor. CISA's KEV add is the "stop debating the change window" event.

Observed post-exploitation in public notes: files dropped as zimbra under Jetty webapps and /tmp. That is a webshell-shaped follow-on, not a theoretical RCE.

Why It Matters

Self-hosted Zimbra is still how a lot of governments, universities, and smaller enterprises avoid Exchange. Command execution as zimbra is mailbox access, filter rules, and a short walk to whatever the service account can write in Jetty. Check Point's Lazarus reporting the same month also showed compromised Roundcube as C2 — mail servers are load-bearing C2 now, not just phishing targets.

Who Is Affected

  • Zimbra Collaboration Suite before 10.1.20 with zimbra-snmp installed and SNMP notifications enabled
  • Instances that installed zimbra-snmp "for monitoring" and forgot it
  • Internet-exposed mailboxd / notification paths
  • 10.1.20 and later — not vulnerable to this CVE; still apply later Zimbra security patches as they ship

How to Protect Yourself

1. See whether SNMP notify is even on, then upgrade to 10.1.20 or newer.

su - zimbra -c 'zmcontrol -v'
rpm -q zimbra-snmp 2>/dev/null || dpkg -l | grep zimbra-snmp
su - zimbra -c 'zmlocalconfig snmp_notify'

Follow Zimbra's 10.1.20 patch-release notes for your OS. If you cannot patch this hour, disable SNMP notifications and stop exposing snmp/swatchdog; that is a workaround, not the fix.

2. Hunt as the zimbra user from 17 August (or earlier if you were exposed).

# unexpected web artifacts
find /opt/zimbra/jetty/webapps /opt/zimbra/jetty_base/webapps /tmp \
  -user zimbra -mtime -45 -type f \( -name '*.jsp' -o -name '*.php' -o -name '*.class' \) -ls

grep -iE 'snmp_notify|swatchdog' /var/log/zimbra.log | tail -n 200

Unexpected service status flips in zimbra.log are in vendor/CERT hunt lists. Report confirmed compromise to your national CERT.

3. If you find a dropper, treat the mailbox store as untrusted. Rebuild or restore from a pre-window backup, rotate zimbra and LDAP bind passwords, mailbox encryption keys if you use them, and every downstream token in Zimbra (EWS, Nextcloud, SMTP relay). Patch the other 10.1.20 issues (forwarding bypass, EWS, delegation, SSRF) in the same window so you do not leave a second hole.

4. Do not run optional monitoring packages on internet MX unless you have a specific need and they are patched. SNMP on a mailer is a gift.

Source