Zimbra Patched This on July 20. CISA Gave Federal Agencies Until Tomorrow. The Bug Only Fires If Three Things Are True — and the Third One Is On by Default.
- Patrick Duggan
- 5 hours ago
- 5 min read
CISA added [CVE-2026-73570](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-73570) to the Known Exploited Vulnerabilities catalogue on August 21, with a federal remediation deadline of August 24 — that is tomorrow. Zimbra shipped the fix in 10.1.20 on July 20. CERT Polska, Poland's national CERT, confirmed this week that it is being exploited in the wild.
Do the subtraction: a month between the patch and the confirmation of exploitation, and a three-day federal deadline once the government decided to say so. If you run Zimbra and you have not applied 10.1.20, you have been exposed for roughly thirty-four days and somebody has been using it.
CVSS 8.9. Unauthenticated. Arbitrary operating system commands as the zimbra user.
The mechanism, and the part that will cost people
Per NVD's description: due to improper sanitisation of untrusted input during SNMP notification processing, an unauthenticated attacker can send specially crafted SMTP requests that may result in execution of arbitrary operating system commands as the Zimbra user.
Read that twice, because there are two protocols in it and that is the whole trap. The flaw lives in SNMP monitoring functionality. The flaw is reached over the mail path. You do not need to expose an SNMP port to the internet to be hit — you need to be running a mail server, which is the entire point of Zimbra.
Three conditions have to hold for the bug to fire:
One, the optional `zimbra-snmp` package is installed. Optional. Many deployments have it because monitoring was set up at some point by somebody who has since left.
Two, SNMP notifications are enabled via the snmp_notify parameter. Also a deliberate choice somebody made once.
Three, the `swatchdog` service is running. And here is the sting: swatchdog is enabled by default.
So the exposure profile is a conditional that reads as reassuring — "only if you enabled SNMP" — attached to a component that is on unless you turned it off. That is precisely the combination that produces a wrong answer in a hurry. An administrator asked "are we affected?" at 4pm on a Friday looks at the first condition, remembers not choosing SNMP monitoring, and says no. The package may still be installed from a template, an inherited build, or a monitoring rollout from three years ago, and the default-on service completes the chain.
Do not answer this from memory. Check the box.
What to check tonight, free, no product required
CERT Polska published detection guidance, and it is the kind we like — specific, cheap, and runnable by an organisation with no budget and one overworked administrator.
Look in `/var/log/zimbra.log` for suspicious Zimbra service restarts. Command injection in this position tends to leave restart artefacts, and a restart nobody scheduled is a cheap high-signal indicator.
Look for files created within the last 30 days in three directories: /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/. The first two are where a webshell would go to be served by Jetty; the third is where staging lands. A file with a recent creation date in a webapps directory on a mail server you have not deliberately modified is not ambiguous.
Thirty days is the right window and it is not arbitrary — it is roughly the gap between the July 20 patch and CERT Polska's confirmation, which is the period during which an unpatched instance was reachable by anybody who had worked out the bug from the fix.
There are no public IOCs — no attacker IPs, no domains, no malware hashes have been disclosed in the reporting. That is worth stating plainly rather than implying we have something we do not. What exists is behavioural detection guidance, which for this class of bug is more durable anyway: infrastructure rotates, but a webshell dropped in a Jetty webapps directory looks the same regardless of who dropped it.
Zimbra is a standing target and this is chapter two
On July 10 we wrote about a different Zimbra bug — a critical stored cross-site-scripting flaw in the Classic Web Client, patched with no CVE assigned at the time, where a crafted email ran attacker JavaScript in your session the moment you opened it. The detail that mattered in that post was who reported it: Google's Threat Analysis Group. TAG does not spend its time on ordinary bug hunting. TAG reporting a bug is a tell that somebody was already using it against somebody worth defending, and our read then was to assume a state actor had it.
That was six weeks ago. Now there is a second, unrelated, unauthenticated RCE in the same product, confirmed exploited, on a KEV clock.
This is what a standing target looks like, and it is not an accident of code quality. Self-hosted mail is the highest-value box in most small and mid-sized organisations: it holds the correspondence, it holds the password-reset destination for every other service, and it is run by organisations who chose self-hosting specifically because they could not or would not pay for hosted mail. That last property is the one attackers price in. The people running Zimbra are disproportionately the ones without a security team, and the attackers know the patch cycle is slow because there is nobody whose job it is to run it.
Which is exactly the population we exist to cover, so here is the short version for them, with no vendor pitch attached: upgrade to 10.1.20 or later. If you cannot upgrade tonight, remove or disable the zimbra-snmp package and turn off snmp_notify — that breaks condition one and two, and is a legitimate stopgap while you schedule the real fix. Then run CERT Polska's three checks above, because if you were exposed for a month you need to know whether that month was uneventful.
Capped where we always cap it: we have no first-party telemetry on this campaign — no honeypot catches attributable to it, no exploit attempts we can tie to CVE-2026-73570 in our own edge data, and we are not going to dress up somebody else's finding as our observation. What we can tell you is what the exposure shape is, why the conditional will mislead people, and what to look for tonight. The exploitation confirmation belongs to CERT Polska and the catalogue entry belongs to CISA; credit sits where it sits.
Sources
CVE-2026-73570, CVSS 8.9, OS command injection in Zimbra Collaboration Suite SNMP notification processing; fixed in ZCS 10.1.20, released 20 July 2026. Added to the CISA KEV catalogue 21 August 2026 with a 24 August 2026 federal remediation due date. Active exploitation confirmed by CERT Polska, August 2026; detection guidance theirs. Reported by The Hacker News, SecurityWeek, Security Affairs and securityonline.info.
Our own prior Zimbra coverage: the Google TAG-reported Classic Web Client stored XSS with no CVE (10 July 2026).
If you run Zimbra and you go and check those three directories tonight, tell me what you find. A clean result is as useful to publish as a dirty one, and almost nobody publishes the clean ones. Rate this post below.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=zimbra-patched-this-on-july-20-cisa-gave-federal-agencies-until-tomorrow-the-bug-only-fires-if-thr
Comments