Administrators who tested their Zimbra mail servers against CVE-2026-73570 with a public exploit and saw nothing happen may have drawn the wrong conclusion. Eric Forte of Elastic Security Labs reproduced the full attack chain and found that several public proofs of concept write a payload Zimbra's monitoring daemon never matches, so a failed test looks exactly like a patched server.
That matters because this is not a theoretical bug. CISA added it to its Known Exploited Vulnerabilities catalog in August, as IntelFusions reported at the time, and Microsoft later traced real intrusions that went from a crafted email to web shells and root access. A false all-clear on an internet-facing mail server is about the worst result a test can give.
One malformed address, one log line, one shell
Elastic's write-up walks through the chain. An unauthenticated attacker connects to the server's SMTP port and sends a recipient address with broken syntax, for example one missing its closing angle bracket. Postfix rejects it but records the attacker-controlled text in /var/log/zimbra.log.
Zimbra runs a bundled copy of Swatchdog, a Perl log-watching daemon, that looks for lines shaped like "Service status change: host service changed from stopped to running" and, when SNMP notifications are enabled, sends an snmptrap alert to a monitoring host. The service name from that log line is dropped into a backticked Perl command, so it is handed to /bin/sh. If the attacker formats their fake address to match the pattern and replaces the service name with a shell command, that command runs as the zimbra user. Elastic notes that account reads every mailbox on the server and can send as any local identity, which is why a compromised mail server so often becomes a launchpad for wider impersonation.
Why the failed tests mislead
According to Elastic, the public PoCs it tested often wrote incorrectly formatted commands into the log, so Swatchdog never matched them and nothing executed. Elastic built its own PoC, which confirms execution with an out-of-band callback rather than by writing files to the target. The practical lesson is that a scanner or PoC returning no result is not evidence of a fix. Version is.
Upgrade to Zimbra 10.1.20, then hunt
- Upgrade to Zimbra 10.1.20 or later. Elastic calls this the only complete fix. Check the installed version rather than relying on an exploit test.
- Detect exploitation with Elastic's "Zimbra Swatchdog SNMP Command Injection Execution" rule. It looks for a shell started by the Perl Swatchdog script with snmptrap, zmservicename and zmservicestatus in its command line, followed within 30 seconds by that shell launching any process other than snmptrap. Since snmptrap is the only legitimate child, Elastic describes this as a very strong indicator of successful exploitation, and it can be run retroactively over pre-patch telemetry.
- Hunt for malformed RCPT TO entries in zimbra.log that contain the "Service status change" pattern.
- If you find a compromise, Elastic advises checking for phishing sent from the server, theft of local databases and signing keys, and LDAP exports, not just the mail store.
Months after the patch, the most dangerous thing about this bug may be the comfort a broken exploit provides. Trust the version number, not the silence.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.