Zimbra CVE-2026-73570: An Unauth RCE Hiding in SNMP — 274 Servers Already Compromised

The patch has been available since July 20. The exploitation started anyway — and by August 24, at least 274 Zimbra servers had already been compromised. CVE-2026-73570 is an unauthenticated command-injection flaw in Zimbra Collaboration that hands an attacker shell access as the zimbra user, and the ugly part is where it hides: not in the webmail front end anyone would think to harden, but in an optional SNMP monitoring component most admins forget is even installed. CISA added it to the Known Exploited Vulnerabilities catalog on August 21. If you run Zimbra on-prem, this one is overdue.

What the bug is

CVE-2026-73570 is an OS command injection flaw (CWE-78) in Zimbra Collaboration Suite, rated CVSS 8.9. It requires no authentication and no user interaction. An attacker sends a specially crafted SMTP message — that is, an email — to the target server. When Zimbra processes that message for SNMP notification, untrusted input from the message is passed into a shell context without proper sanitization, and the attacker’s commands execute as the zimbra user.

The vulnerable code lives in the swatchdog service, a log-monitoring component bundled with the optional zimbra-snmp package. Think about what that means as an attack surface: the delivery mechanism is an ordinary email to a mail server whose entire job is to accept ordinary email. There is no exposed admin panel to firewall off, no login to brute-force, no unusual port to close. If your server accepts mail from the internet — and it does, because it is a mail server — the attacker can reach the vulnerable code path.

• Affected: Zimbra Collaboration (ZCS) versions before 10.1.20, where the zimbra-snmp package is installed and SNMP notifications are enabled
• Fixed in: ZCS 10.1.20, released July 20, 2026
• Impact: unauthenticated remote command execution as the zimbra user
• CISA KEV: added August 21, 2026, with a federal remediation deadline of August 24

The trap: you probably didn’t choose to enable this

The condition that makes a server exploitable deserves its own section, because it is exactly the kind of detail that turns “we’re probably fine” into a breach.

The zimbra-snmp package is optional. But once it is installed, the snmp_notify parameter that triggers the vulnerable path is enabled by default. Nobody has to have deliberately switched on a risky feature. Somebody, possibly years ago, ticked a box during installation to get monitoring working — and that decision is what determines whether today’s crafted email becomes a shell on your mail server.

This is a pattern worth internalizing beyond Zimbra: your real attack surface includes every optional component you installed once and never thought about again. Not the software you actively use, but the software that is merely present. Ask yourself which packages on your production boxes you could not confidently justify keeping.

The campaign: 274 compromised, thousands still exposed

This is not a proof-of-concept waiting for someone to weaponize it. There is an active, ongoing campaign against internet-exposed Zimbra instances, and the numbers tell a familiar and depressing story:

• At least 274 servers were confirmed compromised as of August 24, per Shadowserver’s tracking.
• Roughly 8,200 vulnerable instances remained unpatched — the population the campaign is still working through.
• The patch had been available for over a month when compromises were being counted.

After landing code execution, attackers have been observed writing a JSP web shell into Zimbra’s Jetty web application directory, typically under /opt/zimbra/jetty/webapps/. That converts a one-shot injection into durable, convenient access — and on a mail server, access means every message, every attachment, and every credential that has ever passed through it. Mail servers are a uniquely rich target: they hold password-reset emails, internal discussions, invoices, and contracts, all in one searchable place.

The window between “patch released” and “mass exploitation” keeps shrinking. A month used to feel like a comfortable buffer. Here it was not one.

What to do right now

1. Check your version. Anything below 10.1.20 is potentially affected. Upgrade to 10.1.20 or later — this is the actual fix, and everything else on this list is a stopgap.
2. Check whether zimbra-snmp is installed. If you don’t use SNMP monitoring, remove the package. If you can’t upgrade immediately, disabling SNMP notifications removes the exploit condition and buys you time.
3. Assume compromise if you were exposed and unpatched. If your server was internet-facing and running a vulnerable build during August, patching now closes the door but does not evict anyone already inside. Hunt before you relax.
4. Rotate credentials after cleanup. Code execution as the zimbra user means service credentials, tokens, and stored secrets on that host should be treated as burned.
5. Audit what else is listening. While you’re in there, inventory the optional packages on your mail infrastructure and remove what you don’t use.

Have you already been hit? Where to look

Public reporting points to a concrete set of indicators. On any Zimbra host you’re responsible for, check for:

• New or unexpected files created by the zimbra user in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, or /tmp/ within roughly the last 30 days — particularly unfamiliar .jsp files.
• Unexplained Zimbra service restarts in your logs, which have been reported alongside exploitation.
• Outbound connections from the mail server to destinations that have no business reason to be there.

A JSP web shell in a webapps directory is not subtle once you know to look. The problem is that almost nobody looks at that directory on a normal day — so make today the day you do.

The bottom line

CVE-2026-73570 turns a routine email into command execution on your mail server, and it does so through a monitoring package many admins don’t remember installing and never chose to enable. The fix has existed since July 20; hundreds of organizations found out the hard way that an available patch and an applied patch are very different things. Upgrade to ZCS 10.1.20, rip out zimbra-snmp if you don’t need it, and go look in /opt/zimbra/jetty/webapps/ before someone else tells you what’s in there.

---

Sources: The Hacker News — Attackers Exploit Zimbra SNMP Flaw for Unauthenticated RCE · BleepingComputer — Hackers breached over 270 Zimbra servers · Help Net Security — Unpatched Zimbra servers are falling to CVE-2026-73570 · Dark Reading — Exploited Zimbra Flaw Highlights Shrinking Window to Patch. Confirm affected builds against Zimbra’s own security advisory before acting. Only test systems you are explicitly authorized to assess.