The Zimbra SNMP hole: who's actually exposed to CVE-2026-73570
Shadowserver's scans put the count at 274 internet-facing Zimbra instances already compromised through CVE-2026-73570, up from 155 flagged on August 20. That's the headline, and both Help Net Security and BleepingComputer reported it on the same Monday. If you run Zimbra Collaboration Suite on the public internet and you haven't moved to v10.1.20, this is your problem now, not next sprint.
But before you schedule an emergency maintenance window at 2am, read the condition that makes this exploitable — because it's the difference between "I'm exposed" and "I'm fine, and I can patch on my normal cadence."
The bug only fires in a non-default configuration
Per the CVE record quoted by Help Net Security, CVE-2026-73570 is a code injection flaw in how Zimbra handles SNMP notification processing. Untrusted input isn't sanitised, so an unauthenticated attacker can trigger execution of arbitrary OS commands as the Zimbra user. The crucial qualifier: it only affects mailservers that have the optional zimbra-snmp package installed and have SNMP notifications enabled.
That is not the default. A stock ZCS install does not ship you into the blast radius. Shadowserver counted roughly 8,200 instances still not updated to 10.1.20, and they were careful to say not all of those are attackable — the vulnerable path requires that non-default setup. So the honest read is: the pool of genuinely exposed servers is much smaller than 8,200, and the 274 already popped are the ones who both skipped the patch and had SNMP wired up.
If you never touched SNMP on your Zimbra box, you are almost certainly not in the exploitable set. That doesn't mean skip the patch forever — it means you're not on fire, and you can breathe while you confirm it.
What to actually check
Two questions, in order. First, is the zimbra-snmp package present on the host? Second, are SNMP notifications turned on? If both are true and you're pre-10.1.20, treat the machine as a live target and assume it may already be touched. If either is false, your urgency drops considerably.
I'm not going to hand you a one-liner for this, because neither source published one and I won't invent a command you'll paste into a production mail store. Check the installed packages and your SNMP notification config the way you normally audit that host, and confirm your running ZCS version against 10.1.20.
For the "am I already breached" question, the Polish CERT (CERT Polska) published log entries and a list of files created during exploitation — the concrete indicators of compromise. Help Net Security links to that advisory. Those IOCs are worth more than a version check right now, because a patch closes the door but does nothing about a shell that walked in last week. Run as the Zimbra user, that shell had exactly the access your mail daemon has: the spool, the config, any credentials Zimbra reads. Patching a box that's already compromised just locks the attacker inside.
Timeline and pressure
This wasn't a surprise. The flaw was disclosed June 26, a temporary mitigation was available before the fix, and Synacor shipped 10.1.20 on July 20. That's over a month of runway. CISA has since added it to the Known Exploited Vulnerabilities catalog and gave federal civilian agencies three days to remediate and check for compromise — which is the government's way of saying the exploitation is real and indiscriminate, not theoretical.
Who's behind it is unknown. Help Net Security notes Zimbra bugs get worked by both state crews (often as zero-days) and opportunistic criminals, and there's no attribution here yet. For a defender that distinction barely matters: the exploit is public enough that 274 hosts fell, so assume anyone can reach you.
If you administer Zimbra, do the two-question triage tonight, pull the CERT Polska IOCs if you had SNMP enabled, and get to 10.1.20. A clean box just needs the patch. A dirty one needs rebuilding, and the sooner you know which you have, the better.
Sources
Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.
More about the author →Was this article helpful?
Tap a star — no sign-in needed.
Be the first to rate this article.
Related guides
OVSwrap (CVE-2026-64531): a local-root kernel bug hiding in a very large patch wave
On 21 August 2026 Canonical pushed out a broad set of kernel security notices, and threaded through most of them is one identifier: CVE-2026-64531 , nicknamed OVSwrap , an Open vSwitch flaw in the Linux kernel that leads to local root. The oss-security post that carries the name declines AI crawlers , so I only have its subject line to confirm the classification — Linux kernel / OVS, local privilege escalation. The details of the write-up I can't quote, and won't guess at.
SharePoint's JWT Bypass, and Why the UPN Prerequisite Is Barely a Speed Bump
If you run an on-premises Microsoft stack, SharePoint usually isn't the box you think about first — it sits next to Exchange, shares the same Active Directory, and gets patched on whatever cadence the Windows team keeps. This one is worth pulling forward, and not for the reason the headline gives.
The AI Kernel Exploit Got the Headline; These Patches Got Shipped
Two things landed on the same day, 28 July 2026, and it's worth being clear about which one you can act on.
NTFS-3G Gets a Pile of Overflows — But Ask Where You Actually Mount NTFS
Debian shipped DSA-6389-1 for ntfs-3g on 15 July, and Ubuntu followed with USN-8554-1 the next day. Between them they close a batch of nine CVEs: seven heap buffer overflows (CVE-2026-42616, 42617, 42618, 46569, 46570, 46572 and 56135) and two out-of-bounds reads (CVE-2026-46571 and 56136). The overflows can lead to arbitrary code execution; the reads can leak memory contents.