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
Update (October 2, 2026): Microsoft Security Research has published its analysis of CVE-2026-73570 exploitation, and it shows that patching alone is not enough. Exploitation occurred between Zimbra’s fix on July 20 and the public disclosure on August 13, with scanning visible from July 28. After initial access, attackers deployed JSP web shells, established persistence through systemd services, cron and modified sudo configuration, and targeted Zimbra’s centralized secrets (service credentials, preauth and authentication-token keys, and two-factor secrets) rather than individual mailbox passwords. On one server they staged mailbox backup content and attempted to transfer it to cloud storage; Microsoft states it cannot confirm that the transfer completed. Organizations whose Zimbra servers were reachable before patching should rotate Zimbra authentication secrets, search for web shells and new persistence mechanisms, and remove the zimbra-snmp package if SNMP monitoring is not in use.
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
