CVE-2026-73570 sits in a part of Zimbra Collaboration Suite most administrators only touch once, if ever: the optional zimbra-snmp package that feeds monitoring alerts out to network management tools. The flaw is a code injection bug caused by improper sanitisation of untrusted input inside that SNMP notification handling, and it requires nothing more than the optional package being installed and SNMP notifications switched on - a configuration common enough on mail servers that report their own health to a monitoring stack. Zimbra's vendor Synacor disclosed the flaw on 26 June 2026 with a temporary mitigation available from day one, and shipped the proper fix in ZCS 10.1.20 on 20 July.
A month of quiet before anyone flagged exploitation
The gap that matters here isn't disclosure to patch - three and a half weeks is a reasonable turnaround for a collaboration platform fix. It's patch to detected exploitation. Nothing public tied CVE-2026-73570 to active attacks until Poland's CERT flagged compromised instances around 18 August, nearly a month after the fix had already shipped. Help Net Security's coverage reports that the Shadowserver Foundation picked up the scanning work from there: 155 compromised instances by 20 August, rising to at least 274 by 25 August, against a background of more than 8,200 ZCS servers still running vulnerable versions. Attribution remains open - the article notes Zimbra vulnerabilities have historically drawn both state-sponsored actors and opportunistic cybercriminals, and this one hasn't been pinned to either yet.
Why an SNMP monitoring feature is a plausible way in
It's a useful reminder that a mail platform's attack surface isn't just the parts users touch. SNMP notification handling exists to tell an operations team when something's wrong with the server, which means it typically runs with enough privilege to be worth compromising and typically gets far less scrutiny than the webmail interface or authentication flow sitting in front of it. CISA's decision to add CVE-2026-73570 to its Known Exploited Vulnerabilities catalog in the week of 18 August, with the standard three-day remediation window for federal agencies, reflects that: a monitoring feature nobody thinks about until it breaks is exactly the kind of component that stays unpatched longest, because nobody's watching it the way they watch the front door.
8,200 is the number that should worry you more than 274
274 confirmed compromises out of a Shadowserver scan is already a meaningful number for a flaw that's had a fix for five weeks. The more useful number is the 8,200-plus instances still running vulnerable versions of ZCS, because that's the pool the compromise count is drawn from and it isn't shrinking as fast as it should be. A patch that exists doesn't help a server that hasn't applied it, and the exploitation curve here - quiet for a month, then rising fast once one national CERT and one scanning foundation started looking - is a familiar shape from mass-exploitation events involving less obscure components. There's no reason to expect this one to plateau on its own.
- Confirm every Zimbra Collaboration Suite instance is running ZCS 10.1.20 or later, and check specifically whether the zimbra-snmp package is installed even where SNMP wasn't a deliberate choice.
- Where the package is present but SNMP notifications aren't actually needed operationally, disable the feature rather than relying on the patch alone.
- Review server logs from late June onward, not just from the mid-August exploitation reports, since the vulnerability was disclosed and technically exploitable well before Shadowserver's scanning caught up with it.
- Treat monitoring and telemetry features generally as part of your patch-priority surface, not a lower-risk category than user-facing services.
- If you administer Zimbra for a client or managed environment, don't assume a July patch date means the fleet is current - verify version numbers directly rather than trusting change records.
A five-week gap between a patch shipping and anyone publicly noticing it was needed is common enough that it shouldn't be surprising, but 8,200 still-vulnerable servers a month after that gap closed is a patch compliance problem, not a detection one. If you'd like help finding out where your own Zimbra estate sits against that number, email sales@halfteck.com.