A Zimbra mail server does not need a stolen password to get taken over right now. CVE-2026-73570 is a critical, unauthenticated remote code execution flaw in Zimbra Collaboration Suite, and CERT Polska caught it being used in live attacks on August 19. Two days later CISA added it to the Known Exploited Vulnerabilities catalog and told federal civilian agencies to patch by August 24, a three-day window that is about as tight as these deadlines get.

  • CVE-2026-73570 hits Zimbra Collaboration Suite installs that have the optional zimbra-snmp package installed with SNMP notifications turned on. A crafted SMTP request lets an attacker run arbitrary OS commands as the zimbra user, no login attempt needed.
  • Zimbra shipped the fix in ZCS 10.1.20 on July 20, 2026. Exploitation surfaced roughly a month later, on August 19.
  • CISA added the bug to KEV on August 21 and set a federal patch deadline of August 24. That deadline has already passed.
  • Shadowserver has counted more than 270 compromised Zimbra servers so far. Over 12,000 ZCS instances are reachable from the open internet in total, so the confirmed number is almost certainly a floor, not a ceiling.

What is CVE-2026-73570?

The bug lives in how Zimbra handles SNMP notifications. Zimbra ships zimbra-snmp as an optional component for admins who want their mail platform to trip alerts through an existing monitoring stack. When that package is installed and SNMP notifications are enabled, the notification processing code fails to properly sanitize untrusted input. An attacker who sends a specially crafted SMTP request can get that unsanitized input to reach a command execution path, and the resulting commands run with the privileges of the zimbra service account. No credentials, no session, no prior foothold. Just a malformed request aimed at a server that has the feature turned on.

RelatedCisco UCM SSRF Flaw CVE-2026-20230 Is Under Active Attack

Why is CISA giving federal agencies only three days?

Three factors stack on top of each other here. First, the vulnerability requires zero authentication, so there's no password spray or phishing step slowing an attacker down. Second, Zimbra servers are mail servers, which means they're internet-facing by design; you can't hide an MX record behind a VPN and still receive mail. Third, Zimbra has a track record. APT28, APT29, and Winter Vivern have all previously targeted Zimbra flaws against government and NATO-linked organizations, precisely because Zimbra sits in enough government and defense-adjacent inboxes to be worth the effort, even though its market share is a fraction of Microsoft Exchange or Google Workspace. Put an unauthenticated RCE in front of that history and a three-day clock stops looking aggressive and starts looking overdue.

  1. Jul 20, 2026Zimbra releases ZCS 10.1.20 The patch for CVE-2026-73570 ships quietly, without an accompanying wave of advisories.
  2. Aug 19, 2026CERT Polska flags active exploitation First public confirmation that attackers were hitting live, unpatched servers.
  3. Aug 21, 2026CISA adds the CVE to its KEV catalog Starts the binding patch clock for federal civilian executive branch agencies.
  4. Aug 24, 2026Federal patch deadline Three days after the KEV listing. That deadline has already passed as of this writing.

How does the SNMP-to-shell chain actually work?

The mechanism is worth walking through because it explains why this bug is being described in some reporting as an "SNMP flaw" even though the attacker never touches an SNMP port directly. The entry point is SMTP, the same protocol every mail server has to expose to accept incoming mail. A crafted request reaches Zimbra's mail handling stack and gets routed into the SNMP notification code, since that's the component responsible for firing off an alert when certain mail events happen. That code path trusts its input more than it should. Instead of treating the request as data, it lets part of it get interpreted as a command, and that command executes with the same OS-level permissions the Zimbra service itself runs under.

Zimbra CVE-2026-73570 exploitation chainDiagram showing an unauthenticated attacker sending a crafted SMTP request that reaches zimbra-snmp notification processing, triggers command injection through improper input sanitization, and results in arbitrary OS command execution as the zimbra user. ATTACK CHAIN NO AUTH REQUIRED 01 Unauthenticated attacker 02 Crafted SMTP request, zero credentials 03 zimbra-snmp notification processing 04 Unsanitized input reaches command injection 05 Arbitrary OS commands run as the zimbra user genztech.blog
Fig 1 How a single crafted SMTP request turns into unauthenticated code execution on an unpatched Zimbra server.

Am I affected?

You're at risk if you're running Zimbra Collaboration Suite older than 10.1.20 with the zimbra-snmp package installed and SNMP notifications enabled. That last part matters: the flaw only fires through that specific optional component, so a ZCS deployment that never turned SNMP notifications on isn't exposed through this path, even on an older build. The problem is that most admins don't have a clean inventory of which optional packages are enabled across every mail server they run, especially on installs that have been upgraded in place for years. With more than 12,000 ZCS instances sitting on the open internet and only a few hundred confirmed compromised so far, the gap between "vulnerable" and "already breached" is still closing, not closed.

RelatedCISA Flags TeamCity RCE: An XStream Allowlist Left Open

What should defenders do right now?

Patching is the real fix, and it's a fast one. Everything else below is what to do while that patch rolls out, or after it, to confirm nothing already got in.

What to watch
  • Patch to ZCS 10.1.20 or later. This closes the vulnerable code path entirely and is the only complete fix.
  • Disable zimbra-snmp if you don't use it. If SNMP notifications aren't actively feeding a monitoring system, turning off the package or the notification feature removes the attack surface even before you patch.
  • Check for unexpected Zimbra service restarts. CERT Polska flagged this as a compromise indicator worth reviewing in service logs.
  • Look for new files in three specific paths. Check /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/ for anything created by the zimbra user in the last 30 days that you can't account for.
  • Rotate credentials if you find anything. A confirmed indicator of compromise means treating every credential that touched that server as burned, not just patching and moving on.

Our take

A month between patch and public exploitation used to count as a reasonably wide window. It isn't anymore, and this is a good data point for why. Zimbra fixed this quietly on July 20 with no accompanying advisory blitz, and attackers still found it and started using it by August 19. That gap keeps shrinking across the industry, whether the vendor ships a loud CVE writeup or not, because attackers now treat every changelog and every diff between point releases as a research lead. The other piece worth sitting with is why Zimbra specifically. It's not the biggest mail platform by a long shot, but it's the one that shows up in government agencies and NATO-adjacent organizations that can't or won't move to Microsoft or Google, and state-linked groups have exploited that pattern before. Smaller footprint doesn't mean lower stakes. It just means fewer people are watching, which is exactly the kind of asymmetry a patient attacker looks for.

Primary sources

Original analysis by GenZTech. Source: BleepingComputer.