--- schema: 1 kind: vulnerability title: "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" headline: "The patch landed on 21 July, the identifier on 13 August, the exploitation on 18 August — a CVE-driven patch process could not see this one at all" summary: > Zimbra shipped ZCS 10.1.20 on 2026-07-21 with a fix for a command injection in the SNMP monitoring component, described at the time only in general terms and with no vulnerability flagged as exploited. The identifier CVE-2026-73570 was published on 2026-08-13, and ENISA's EU Vulnerability Database now records the flaw as exploited since 2026-08-18 — a determination CERT-FR relayed to its constituency on 2026-08-19. The flaw needs no authentication: improper sanitisation of untrusted input during SNMP notification processing lets a crafted SMTP request reach arbitrary operating-system command execution as the Zimbra user. It applies only where the optional zimbra-snmp package is installed and SNMP notifications are enabled, which is the check that decides whether an estate is affected at all. discovered_at: "2026-08-20T04:36:00Z" event_date: "2026-08-18" run_id: 2026-08-20T0409Z-intel priority: high immediate_action: null tags: [vulnerabilities, rce, pre-auth, actively-exploited, patch-available] regions: [global, europe] sectors: [public-sector, education, telco] entities: [] techniques: [T1190, T1059.004] affected_products: ["Zimbra Collaboration"] cves: - id: CVE-2026-73570 cvss: "8.9" epss: 0.54 type: rce vector: zero-click auth: pre-auth status: [exploited, patch-available] affected: "Zimbra Collaboration before 10.1.20, where the optional zimbra-snmp package is installed and SNMP notifications are enabled" fixed: "10.1.20" sources: - url: "https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories" publisher: "Zimbra (vendor security advisories)" date: "2026-08-13" role: primary - url: "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-1041/" publisher: "CERT-FR (ANSSI)" date: "2026-08-19" role: corroborating - url: "https://euvd.enisa.europa.eu/vulnerability/CVE-2026-73570" publisher: "ENISA EU Vulnerability Database" date: "2026-08-13" role: corroborating - url: "https://thehackernews.com/2026/07/zimbra-patches-critical-snmp-command.html" publisher: "The Hacker News" date: "2026-07-21" role: corroborating closed_sources: [] evidence: - quote: "L'ENISA indique que la vulnérabilité CVE-2026-73570 est activement exploitée." publisher: "CERT-FR (ANSSI)" - quote: "Fixed a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled." publisher: "Zimbra (vendor security advisories)" - quote: "none of the identified vulnerabilities have been flagged as actively exploited" publisher: "The Hacker News" verification: multi-source sourcing_note: > The exploitation determination rests on one assessor: ENISA's EU Vulnerability Database, which records the flaw as exploited from 2026-08-18 and which CERT-FR relays rather than assessing independently. No vendor, national authority or research lab fetched this run reports observed intrusions, a proof of concept or a scanning campaign, and Zimbra's own advisory table carries no CVSS score for this CVE at all (its score column reads TBD) — the 8.9 and the EPSS figure come from the ENISA record, which is cited directly. The description quoted in the body was read from the database's search API; the per-CVE page it is cited to carries the same record. confidence: high update_of: null references: [] deep_dive: false deep_dive_category: null org_triage: null classification: reliability: A credibility: 2 watchlist_hit: false actions: - "Determine on every Zimbra Collaboration host whether the optional zimbra-snmp package is installed and SNMP notifications are enabled; where it is, upgrade to 10.1.20, and where the upgrade cannot be scheduled immediately, remove the package or disable SNMP notifications — that removes the vulnerable path rather than mitigating around it." - "Treat any Zimbra host that has run a pre-10.1.20 build with SNMP notifications enabled since 21 July as warranting a compromise assessment rather than an upgrade alone, scoped to command execution under the zimbra service account: child processes spawned from the mail-server process tree, and files or scheduled work created by that account since that date." migrated_from: null --- 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](https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories)). 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](https://thehackernews.com/2026/07/zimbra-patches-critical-snmp-command.html)). 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](https://euvd.enisa.europa.eu/vulnerability/CVE-2026-73570)). ENISA scores it 8.9 with high attack complexity ([ENISA EU Vulnerability Database, 2026-08-13](https://euvd.enisa.europa.eu/vulnerability/CVE-2026-73570)), 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](https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-1041/)). ENISA's record dates that exploitation from 18 August ([ENISA EU Vulnerability Database, 2026-08-13](https://euvd.enisa.europa.eu/vulnerability/CVE-2026-73570)). 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. **Defender takeaway:** the check that scopes this is a package check, not a version check — a Zimbra estate without the optional zimbra-snmp package installed and SNMP notifications enabled is not exposed to this flaw regardless of build. For everyone else, 10.1.20 is the remediation and removing the package or disabling notifications is the control that works without a maintenance window. The broader lesson is one this constituency has now met several times in a month: a vendor fix that ships ahead of its identifier is invisible to every CVE-keyed process an organisation runs, so "we patch what the scanner shows" leaves a gap exactly as long as the gap between the release and the CVE.