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
Barracuda's Chained Root Bug: It's About Where Your Admin Interface Lives
Barracuda has published details of two vulnerabilities that, chained together, hand an attacker root on the appliance. The Hacker News has the full breakdown; BleepingComputer corroborates the disclosure. If you run a Barracuda Email Security Gateway in front of your mail flow — and plenty of shops still do, sitting it ahead of Postfix or a Zimbra edge — this is worth ten minutes of your attention today. But read past the CVSS scores before you panic, because the two numbers tell you more about how you're exposed than whether you're doomed.
Two PHP Engine Bugs Hit the KEV List — Your Webmail Is the Exposed Part
On 26 October, CISA added two PHP flaws to its Known Exploited Vulnerabilities catalog and refreshed its earlier PHP alert ("Critical Vulnerabilities in PHP Require Immediate Patching," from 21 October):
The Brotli RCE is an HTTP problem, not a TLS one
A memory-corruption bug in Google's Brotli decoder, CVE-2026-111497, got the scary framing it deserves — The Hacker News leads with the Node.js RCE and the long tail of affected software, and the oss-security list carried the coordination thread. Before you start grepping your mail stack in a panic, though, let me narrow the blast radius, because the triage instinct ("Brotli is in TLS, so my mail TLS is exposed") is wrong.
Two Linux Bugs, One Scary Number, and Which One Is Actually Rooting Servers
This week produced two separate Linux kernel stories that are very easy to mash into one, and the triage note that landed on my desk did exactly that. They are not the same bug, they do not carry the same urgency, and treating them as one leads you to patch the wrong thing first. Let me pull them apart.