SURIQ
The headlines call CVE-2026-73570 a Zimbra SNMP flaw, which makes it sound like a problem only for shops that expose network monitoring to the internet. That framing hides the real risk. The bug is triggered over SMTP, the one port a mail server has to keep open, and it runs attacker-chosen commands on the host with no login. Poland's national CERT reports it is being exploited in the wild, and on August 21 CISA added it to its Known Exploited Vulnerabilities catalog with a three-day federal patch deadline. If you patched a Zimbra box a few weeks ago, you are probably still open.
The flaw carries a CVSS score of 8.9 and affects every Zimbra Collaboration Suite build before 10.1.20. There is no authentication, no user interaction, and no special network position required. That combination is why it moved into active exploitation so fast.
How a mail message becomes a command on the host
Zimbra ships an optional monitoring path built on swatch, a log watcher that reads server logs and fires SNMP notifications when it matches certain events. The vulnerable code sits in that notification handling. Content that reaches the notification path is not cleaned before it is handed to a shell, so an attacker who can get a crafted string into a monitored log line can have that string run as a command. The delivery vector is a specially built SMTP interaction, which is why The Hacker News headlines it as an SNMP flaw while CISA's own catalog entry describes crafted SMTP requests. Both are describing the same defect: SMTP is the way in, the SNMP notification code is where the injection lands.
The commands run as the zimbra user, the service account that owns the mail stack. That is not root, but it is the account that can read every mailbox on the server, write into the web roots that serve the client, and reach whatever internal systems the mail host talks to. A shell as zimbra on a collaboration server is a foothold into the whole mail estate, and mail servers hold the password-reset keys to everything else.
Who is exposed, and why "we don't run SNMP" is not an answer
A host is only reachable when three things line up. The zimbra-snmp add-on has to be present, trap notifications have to be turned on, and the swatch watchdog has to be running. Here is the trap. The watchdog service runs by default. Plenty of administrators who never consciously enabled SNMP trap monitoring still have the vulnerable path live, because it came up on its own. Treat "we don't use SNMP" as a claim to verify on the box, not an assumption to rest on. Check whether the package is present and the watchdog is running before you decide you are safe.
The dates are the story. Zimbra shipped the fix in 10.1.20 on July 20, a quiet point release. About a month later, CERT Polska confirmed attackers were exploiting it. CISA listed it on August 21 and set the federal remediation deadline at August 24, a three-day clock. The month between the maintenance release and mass exploitation is the pattern to internalize: on Zimbra, a point release is not routine housekeeping, it is an emergency patch waiting for someone to notice.
Patched to 10.1.19 a few weeks ago? You are still open
This is the part the wire coverage misses. We recently walked through a separate Zimbra fix that pushed admins to 10.1.20's predecessor, 10.1.19, to close a crafted-email code-execution bug in the Classic Web Client. That release does not contain the SNMP notification fix. An operator who did that emergency patch a few weeks ago and moved on is still exposed to CVE-2026-73570. The only build that closes this one is 10.1.20. If your change record shows a recent Zimbra bump, check the exact version before you assume you are covered.
None of this is new territory for Zimbra. The platform has been a repeat target, from the webmail zero-day that Russian operators used to steal mail and mint MFA-bypass passwords to a run of client-side code-execution bugs. Two emergency Zimbra patches inside a short window is the current reality of running this stack, and the operators who fare best are the ones who treat every Zimbra release as security-relevant until proven otherwise. Unauthenticated webshell drops are a well-worn playbook here, the same one behind mass exploitation of other self-hosted apps.
Upgrade to 10.1.20, then hunt the notification log
The first action is not a detection, it is the patch. Upgrade every Zimbra Collaboration Suite host to 10.1.20 or later. That is the only real fix, and with a three-day federal deadline on a bug already under attack, it is today's work, not this week's.
If you genuinely cannot patch inside the window, the same three preconditions that make you vulnerable are the ones to remove. Taking the SNMP notification path offline, by disabling the trap notifications and the swatch watchdog, closes the vulnerable code path as a stopgap. It is a stopgap, not a substitute for 10.1.20, and you still patch as soon as your change window allows.
For the window between disclosure and a completed patch across a fleet, hunt. CERT Polska points defenders at a specific tell: watch /var/log/zimbra.log for swatch service-status lines that report an unfamiliar payload flipping between stopped and running, which is what the abused notification flow looks like from the log side. Then look for files written by the zimbra user in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/ in the last month, plus unexplained restarts of the Zimbra services. Those are the webshell-drop and persistence signs of a host that has already been hit.
Two controls turn that hunt into an alert instead of a forensic exercise. File integrity monitoring on the Jetty web roots flags a silent webshell the moment it lands, and egress monitoring from the mail host catches the outbound command-and-control that a zimbra-user shell reaches for. A managed detection service watching those log paths and file writes is how you cover the gap between a KEV listing and a fully patched fleet, rather than finding out at the next incident review. Expect the next wave of Zimbra scanning to key on exactly this notification path, and the servers that ride it out will be the ones already on 10.1.20.