A command injection in Zimbra’s SNMP component is exploited via plain email and joins the KEV

August 13, 2026. The NVD published CVE-2026-73570, a system command injection in Zimbra Collaboration scored 8.9 under CVSS v3.1. August 17, 2026. CERT Polska reported an active exploitation campaign in the wild. August 21, 2026. CISA added the flaw to the KEV catalog and set a federal due date of August 24, 2026.

For a CISO running a Zimbra mail server, the lesson fits in one sentence: a flaw that starts with an inbound email and ends in a system command run as the zimbra user is not a patch ticket — it is a probable compromise.

An unusual injection chain

CVE-2026-73570 is an OS command injection (CWE-78) that lives in Zimbra’s SNMP monitoring component, specifically in the processing of SNMP notifications. The official description is dry but precise: an unauthenticated attacker sends specially crafted SMTP requests and gains arbitrary OS command execution with the privileges of the zimbra user.

The attack path deserves a pause, because it does not look like classic injection. The flaw is not triggered from the web interface or an API endpoint, but from the mail input itself: an inbound SMTP message whose data flows into the processing of SNMP traps is improperly sanitized there, and ends up interpreted as a command. It is a mail → monitoring → shell chain — three systems that should never have shared the same trust flow.

The SMTP vector has an immediate practical consequence: there is no application-level authentication prerequisite to meet. The attacker needs no account, no password, no session. They need the ability to deliver a message to the instance — which, for a mail server, is its very purpose.

The trap of the “optional” component

The NVD entry wraps the flaw in a condition that, read too quickly, is falsely reassuring: the vulnerability only manifests if the optional zimbra-snmp package is installed and SNMP notifications are enabled. Two conditions, the first of which seems to rule out most deployments.

This is where the technical detail reasserts itself. CERT Polska notes that the activation condition is the snmp_notify parameter, and that the service doing the work — swatchdog — is enabled by default. In other words, the “optional” half of the condition is a component that teams install without a second thought (SNMP monitoring is a common operations request), and the “enabled by default” half is on without anyone deciding anything.

The lesson is structural: on an exposed mail product, an SNMP monitoring function is not a harmless module. It becomes a command-execution surface the moment it receives, even indirectly, network-originated data — here, SMTP messages. The patch removes the flaw, but it does not make the reflex less useful: disable what you do not use.

Active exploitation and detection guidance

The KEV entry on August 21, 2026 establishes active exploitation — that is the catalog’s whole criterion. CERT Polska goes further, publishing precise detection guidance as early as August 17 for administrators who want to know whether they are already hit.

The first guidance concerns the logs. The file /var/log/zimbra.log should be searched for lines of the form Service status change: <payload> changed from stopped to running and its counterpart changed from running to stopped. That is the flaw’s signature: the injected payload shows up in the service status tracking, which makes it a simple and reliable marker.

The second concerns the filesystem. Check for files created in the last 30 days by the zimbra user in three sensitive trees: /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/. A web shell dropped in one of those trees survives a service restart and re-serves the attacker after patching.

This guidance is not a universal checklist but a starting point for investigation. The absence of a marker does not prove a server is clean — it only says the most obvious indicator was not found.

The fix and the deadline

The flaw is eliminated in Zimbra 10.1.20. The Zimbra security advisory lists CVE-2026-73570 among the fixes in that release, alongside other identifiers handled in the same publication — CVE-2026-50055, CVE-2026-10631, CVE-2026-50054, among others. The remedy is therefore available, versioned, and documented: there is no waiting excuse for earlier 10.1.x branches.

CISA imposes, through its BOD 26-04 directive, a due date of August 24, 2026 for US federal agencies. Three days between the KEV entry and the deadline: that is a tight window, and it should be read for what it is — an urgency signal, not administrative comfort. A short federal deadline is the most honest indicator of how fast the campaign is spreading.

The pre-10.1.20 range covers all unpatched branches. For deployments still running older versions — Zimbra has a long history of mass-exploited mail flaws — moving to 10.1.20 is the only way out, and it must come with a hunt for compromise, not just an update.

Verdict

If you run Zimbra Collaboration, patch to 10.1.20 immediately, disable the zimbra-snmp module (or the snmp_notify parameter) if it is not essential, and treat investigation as a task separate from the update: search /var/log/zimbra.log for Service status change lines, check the three web trees for recent files created by zimbra, and revoke secrets from a clean machine if any marker appears.

If you do not run Zimbra, take away the pattern, not the product: an “optional” SNMP monitoring module, enabled by default and fed by network-originated data, becomes a command-execution surface. On any exposed mail server, disable what you do not use, and treat inbound email for what it is — untrusted input, even when it lands “only” in a monitoring log.

References

• CISA — Known Exploited Vulnerabilities Catalog, CVE-2026-73570, added August 21, 2026
• NVD — CVE-2026-73570, published August 13, 2026
• CERT Polska — Aktywnie wykorzystywana podatność w Zimbra Collaboration Suite (145/2026), August 17, 2026
• Zimbra — Zimbra Security Advisories, accessed August 22, 2026