Zimbra Collaboration — pre-authentication command injection in SNMP notification processing reaching OS command execution as the Zimbra user; fixed in 10.1.20 (21 July 2026), CVE published 13 August, ENISA records exploitation from 2026-08-18.

CVE-2026-73570 — Zimbra Collaboration: a pre-auth command injection patched without a CVE in July is now recorded as actively exploited, four weeks after the fix shipped

Zimbra's own security-advisory table records the fix for CVE-2026-73570 as "Fixed a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled", shipped in release 10.1.20 (Zimbra, 2026-08-13). That release went out on 21 July 2026 carrying nine fixes, and at the time none of them had been flagged as actively exploited; the vendor's stated position was that "in line with industry best practices, information disclosure is limited for security vulnerability fixes" (The Hacker News, 2026-07-21). The identifier arrived nearly four weeks later, on 13 August, and the ENISA record describes the mechanism in full: because untrusted input is not properly sanitised during SNMP notification processing, "an unauthenticated attacker can send specially crafted SMTP requests that may result in execution of arbitrary operating system commands as the Zimbra user" (ENISA EU Vulnerability Database, 2026-08-13). ENISA scores it 8.9 with high attack complexity (ENISA EU Vulnerability Database, 2026-08-13), and the flaw applies only to deployments where the optional zimbra-snmp package is installed and SNMP notifications are enabled.

On 19 August CERT-FR issued its own advisory for the Zimbra bulletin and stated plainly that ENISA records CVE-2026-73570 as actively exploited (CERT-FR, 2026-08-19). ENISA's record dates that exploitation from 18 August (ENISA EU Vulnerability Database, 2026-08-13). What makes this worth an out-of-band look rather than a place in the next patch window is the sequence rather than the score: the code was fixed in July with no identifier attached, so an estate that drives its patching from CVE feeds, scanner signatures or an SBOM pipeline had nothing to match against for four weeks, and the flaw only became visible to those processes five days before it was recorded as exploited. Anyone who upgraded to 10.1.20 in July for unrelated reasons is already covered and does not know it; anyone who deferred is now unpatched against a flaw with a published exploitation status.

The behaviour to look for follows from the mechanism. Command injection at the point where a notification is formatted means the observable is a mail-server process tree spawning something it has no business spawning: an interpreter or utility process whose parent is the Zimbra mail or notification component, running under the zimbra service account rather than under a scheduled administrative task. In process-execution telemetry with parent lineage, that lineage is the signal — SNMP notification handling legitimately produces notification traffic, not shells. On the network side, an outbound connection initiated by the zimbra account immediately after inbound SMTP is the same event viewed from the other end. Triage: Zimbra hosts do legitimately run monitoring integrations under the same account, so process identity alone will not separate them; the discriminators are the parent process being the notification path rather than a cron or monitoring agent, and the absence of a matching operator change record for a host that has no history of spawning interpreters at all.