The bad Zimbra incident is not the one where the server is unpatched. It is the one where the server was unpatched last week, got patched today, and nobody looked for the shell that arrived in between.

CVE-2026-73570 has crossed that line. Zimbra fixed the issue in 10.1.20 on July 20, 2026. CERT Polska warned on August 17 that the flaw was being actively exploited. CISA added it to the Known Exploited Vulnerabilities catalog on August 21. Shadowserver later reported hundreds of potentially compromised internet-exposed instances.

TL;DR

  • CVE-2026-73570 is a Zimbra Collaboration Suite command injection flaw in the SNMP monitoring path when SNMP notifications are enabled.
  • Zimbra lists 10.1.20 as the fixed release, and CISA added the CVE to KEV after public exploitation reporting.
  • The vulnerable condition is configuration-dependent: the optional SNMP path matters, not merely the existence of a Zimbra host.
  • If a server was exposed before patching, treat this as an incident triage problem, not a normal maintenance ticket.
  • Check Zimbra logs and files created by the zimbra user before wiping useful evidence.

Why This One Matters

Mail servers are high-value infrastructure because they sit at the intersection of identity, secrets, and business context. A compromised mailbox server can expose password reset messages, invoices, legal conversations, internal routing, MFA enrollment links, and the material attackers need for later phishing.

Zimbra is also a familiar target. Hive Security recently covered Russian-aligned half-click webmail exploitation in Zimbra and other platforms. CVE-2026-73570 is a different shape of problem: not JavaScript executing in a user’s webmail session, but unauthenticated command execution on the server under the zimbra account when the vulnerable SNMP notification path is present.

That distinction changes the response. User password resets and mailbox review are not enough if the server itself may have executed attacker-controlled commands.

The Vulnerable Path

Zimbra’s advisory describes the fix as a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled. NVD describes affected systems as Zimbra Collaboration before 10.1.20 where the optional zimbra-snmp package is installed and SNMP notifications are enabled.

CERT Polska’s warning adds the operational conditions defenders should verify: snmp_notify enabled and swatchdog running. The default state of one service in one environment should not be generalized into safety for all environments. Check the actual host.

Think in four states:

StateMeaningResponse
VulnerableVersion and configuration match the flawPatch and remove unnecessary SNMP exposure
ExposedAttackers could reach the required pathPatch urgently and preserve logs
ExploitedLogs or files suggest command executionStart incident response
CompromisedUnauthorized access or persistence is confirmedContain, collect evidence, rebuild if required

Many organizations stop at the first row. Active exploitation means the later rows matter.

What To Check Before You Relax

CERT Polska recommends reviewing /var/log/zimbra.log for suspicious service status changes where attacker-controlled content appears before a stopped/running transition. That is a useful starting point because the exploit path can leave traces around service state handling.

Also inspect files created by the zimbra user during at least the last 30 days in:

/opt/zimbra/jetty/webapps/
/opt/zimbra/jetty_base/webapps/
/tmp/

Those locations matter for different reasons. Jetty web application directories are interesting for web-accessible persistence or dropped server-side payloads. /tmp is a common staging area. Neither is a magic indicator by itself; legitimate activity can create files too. The point is to find anomalies, preserve metadata, and decide whether the host has moved from “patched” to “incident.”

For a first-pass inventory:

Terminal window
find /opt/zimbra/jetty/webapps \
  /opt/zimbra/jetty_base/webapps \
  /tmp \
  -user zimbra -mtime -30 -ls

Do not delete the first suspicious file you find. Record path, owner, timestamps, hash, related log lines, and network activity. If the server is compromised, cleanup without evidence collection makes the later investigation weaker.

Hardening Beyond The Patch

Upgrade to ZCS 10.1.20 or later first. That is the fixed release Zimbra points administrators to for this issue.

Then reduce the path that made exploitation possible:

  1. Confirm whether zimbra-snmp is installed.
  2. Confirm whether SNMP notifications are actually required.
  3. Disable snmp_notify where there is no operational need.
  4. Restrict management and monitoring paths to known internal systems.
  5. Alert on unexpected process execution and file creation by the zimbra account.
  6. Treat internet-exposed mail infrastructure as a high-priority patch class, not a routine server group.

The boring control is the important one: know every exposed mail server, know its exact version, and know which optional packages are enabled. Attackers do not need your asset inventory to be elegant. They only need it to be wrong.

Sources