A failed public exploit test can give the wrong answer on a vulnerable Zimbra mail server. Elastic Security Labs researcher Eric Forte reproduced command execution through CVE-2026-73570, then found that several public proofs of concept wrote log lines that Swatchdog never matched. The October 23 research gives teams running Zimbra Collaboration a more useful question than whether a test returned a callback: did the mail server’s monitoring process actually launch an unexpected command?
The CVE record scopes the vulnerable installation to Zimbra Collaboration before 10.1.20 with the optional zimbra-snmp package installed and SNMP notifications enabled. An unauthenticated SMTP client can reach this path. CISA’s enrichment in that record marks exploitation active; Elastic’s own callback came from its controlled reproduction. The consequence on a susceptible server is command execution as the zimbra user, an account Elastic says can read its mailboxes and send as local identities.
A rejected recipient reaches Swatchdog
Postfix can write a malformed SMTP recipient to /var/log/zimbra.log even when it rejects the address. Swatchdog also tails /var/log/zimbra.log for Zimbra service-status messages. Elastic traced how attacker-controlled recipient text could land in a log entry matching the daemon’s service-status pattern. The watcher reads the rejected-address line if it fits the status pattern; SMTP acceptance is beside the point.
When SNMP notifications are enabled, Swatchdog uses its generated Perl script, built from /opt/zimbra/conf/swatchrc.in, to prepare a service-status trap. The dosnmp function inserts the matched service name into an snmptrap command run through Perl backticks. That hands the assembled command to /bin/sh. A service name taken from the log can therefore become shell input under the zimbra account. From that account, commands can read local mailboxes and send as local identities.
Failed test traffic can mislead
Forte’s team saw a callback from a working laboratory test and the process ran as zimbra. But several public PoCs produced strings that never satisfied Swatchdog’s pattern. As the research puts it, “a failed test looks like a patched server.” A log line containing unusual recipient text marks an investigation starting point. Check process telemetry for the Swatchdog shell and its next child to determine whether a command ran.
Use the installed version and the affected SNMP configuration to assess exposure. Treat a failed public test on a pre-10.1.20 installation as a test-result question, not evidence of a fix. Keep reproduction to an authorized representative system; the process telemetry in Elastic’s research supplies a less ambiguous way to assess execution without relying on an untrusted public payload.
Process lineage distinguishes execution
Elastic’s Zimbra Swatchdog SNMP Command Injection Execution rule looks for a shell spawned by the Swatchdog Perl script, with snmptrap, zmServiceName and zmServiceStatus in its arguments. On the same host, within 30 seconds, it then looks for that shell launching a process whose name is other than snmptrap. A normal service notification runs snmptrap; a different child is the signal Elastic uses for command execution. The rule keys the two process events on their entity IDs, so a search for an snmptrap string alone misses the relationship.
That check requires Linux process-start telemetry from the mail host. Elastic recommends deploying Elastic Defend and enabling its named rule, including for a retrospective search over available process events. Teams using other endpoint telemetry can inspect the same parent Perl script, shell command line and subsequent child-process relationship. Missing process events are a detection gap: preserve /var/log/zimbra.log for the recipient and service-status context, but rely on process lineage or equivalent host evidence to make an execution finding.
If that unexpected child appears, investigate access to mailboxes, outgoing phishing from the server, local databases, signing keys and LDAP exports, as Elastic advises. A patched server still needs incident review if it ran the command before the update.
Upgrade Zimbra and verify the release
Inventory Zimbra mail hosts for the installed release, the optional zimbra-snmp package and enabled SNMP notifications. Upgrade affected installations to 10.1.20 or later. Elastic calls the upgrade “the only complete fix.” Restrict SMTP access to intended senders and networks where your mail architecture permits it; that limits who can deliver untrusted input, while the upgrade removes the vulnerable handling.
After the change, verify the installed release on each affected host rather than inferring it from an update job. Check that the expected process-start telemetry reaches your detection system and that the Swatchdog rule is enabled. In an authorized test environment, validate that a normal service-status notification produces its expected snmptrap child and that your detection catches an unexpected child from that shell. Use the version check for patch confirmation; use the process relationship to investigate execution. Confirm host process telemetry alongside a quiet rule search so an absent alert has meaning.