Zimbra Command Injection Vulnerability Actively Exploited
A Zimbra command injection vulnerability is under confirmed active exploitation against on-premises mail servers, and CISA’s federal remediation deadline of August 24 has already passed. Tracked as CVE-2026-73570, the flaw lets an unauthenticated attacker execute arbitrary shell commands on any unpatched Zimbra Collaboration Suite instance with SNMP notifications enabled — a configuration many administrators never explicitly reviewed.
What Happened
Zimbra fixed this Zimbra command injection vulnerability on July 20, 2026 in version 10.1.20, but exploitation is now confirmed against servers that never applied the update. CERT Polska first reported active in-the-wild attacks on August 17. CISA added CVE-2026-73570 to its Known Exploited Vulnerabilities catalog on August 21 and set August 24 as the federal civilian remediation deadline — a date that has already passed at time of publication, and a five-week gap between the patch shipping and the deadline landing.
The flaw (CWE-78, OS command injection) sits in Zimbra’s SNMP notification pipeline. An unauthenticated attacker sends a specially crafted SMTP request that abuses insufficient input sanitization to run arbitrary shell commands as the Zimbra service user. It only affects deployments with the optional zimbra-snmp package installed, snmp_notify enabled, and the swatchdog service running — swatchdog runs by default, which is why exposure is broader than the “optional package” framing suggests. Reported CVSS: 8.9.
Detection guidance from the researchers who confirmed exploitation: check /var/log/zimbra.log for unexplained service state transitions (stopped to running or the reverse), a signal the vulnerable notification flow was triggered without a legitimate administrative action behind it.
Why It Matters
Zimbra is widely deployed across DACH SMEs and public-sector organisations specifically as an on-premises alternative to Exchange or Microsoft 365 — the population least likely to have a fast, centrally enforced patch cycle, and the one making a deliberate trade-off to keep mail infrastructure in-house. An unauthenticated RCE on that infrastructure is a direct hit against the exact control such organisations chose on-premises hosting to preserve. The five-week gap between patch availability and the federal deadline is a familiar pattern: a fix existing is not the same as a fix being applied.
What You Should Do Now
- Immediate: upgrade to Zimbra Collaboration Suite 10.1.20 or later on every instance that has not already applied it.
- Verify: check whether the zimbra-snmp package is installed and whether snmp_notify is enabled; if SNMP monitoring is not actively used, disabling it removes the exposed code path entirely, patch or not.
- Mitigate: if upgrading immediately is not possible, disable the swatchdog service or block inbound SMTP from untrusted sources at the network layer as an interim measure.
- Monitor: review
/var/log/zimbra.logfor unexplained service state transitions covering the period since July 20, and treat any found as a potential compromise requiring full incident response.
DIESEC Perspective
This is a pattern we see regularly in Mittelstand environments: a self-hosted platform chosen deliberately to avoid cloud dependency, running a monitoring feature nobody remembers configuring, that turns out to be the exposed attack surface once a researcher looks closely enough. The patch existing since July did not protect anyone who didn’t apply it — and CERT Polska, not a DACH or US source, was first to confirm exploitation.
Not sure whether your on-premises mail infrastructure has this gap? Contact DIESEC for a rapid patch verification and exposure review.
Sources: BleepingComputer | The Hacker News
Published: 2026-08-26 | Category: Vulnerabilities & Patches | ~4 min read
