How CVE-2026-73570 turns a Zimbra log file into remote code execution

We reproduced the Zimbra command injection vulnerability and found that several public PoCs write a payload Swatchdog never matches, so a failed test looks like a patched server.

When we are building detections for various threats, we regularly run the exploits on representative systems to help us build high-quality rules. The Common Vulnerabilities and Exposures (CVE) entry CVE-2026-73570 for Zimbra is no exception. Zimbra is a widely used enterprise email and collaboration software platform, known for its SMTP platform, among other services. SMTP plays a critical role in the infrastructure of many organizations by providing email services that often include either direct or indirect identity management. In addition to the direct appeal for attackers to read emails, attachments, etc., there is also an appeal for compromised identity management. A compromised mail server can be used to impersonate legitimate accounts for further access and exploitation, becoming a staging ground for additional targets.

CVE-2026-73570 is an unauthenticated command injection vulnerability in Zimbra, and one malformed recipient address is enough to trigger it. Send a malformed request and it is logged in /var/log/zimbra.log . From there, the Swatchdog monitoring daemon matches it against a service status pattern and passes it to /bin/sh inside a backticked Perl string. The result is remote code execution as the zimbra user. The account reads every mailbox on the server and sends as any local identity, so compromising the mail server compromises the identities it serves.

We reproduced the full chain while building detections for it, and several of the public proofs of concept (PoCs) we tested write a payload that Swatchdog never matches, so a failed test looks like a patched server. The working chain is shown , along with the rule that fires when a shell spawns anything other than snmptrap .

Note that if you host Zimbra Simple Mail Transfer Protocol (SMTP) services and haven’t patched to version 10.1.20+, please do so before trying out the steps in this blog post.

How the Zimbra command injection vulnerability works

The core entry point for this kind of attack is CVE-2026-73570, a vulnerability in an unpatched Zimbra service (patched as of Zimbra version 10.1.20). When exploited, it can provide arbitrary remote code execution bypassing authentication requirements. To do this, an attacker passes a specifically crafted SMTP message that’s written to the notification file /var/log/zimbra.log for processing. Under normal circumstances, entries are written to this log to keep track of the status of services, such as when a given mailbox service has started or a message delivery has failed:

Figure 2: Log indication that a message failed to be delivered to zimbra@mail.lab.test.

As part of the monitoring components of Zimbra, a daemon called Swatchdog watches this file for specific log entries that match the format of a service status change:

Figure 3: Normal service message.

When an entry is identified and SNMP notifications are enabled, it invokes a notification function that generates an snmptrap , a one-way alert from the mail server to a monitoring host. The target of CVE-2026-73570 is the way that this message is constructed. The SNMP notification message is parsed with Perl. Zimbra packages a copy of the Perl program Swatchdog to handle this parsing and monitor logs. It tails the log file and compiles /opt/zimbra/conf/swatchrc.in into a Perl script using perlcode lines to directly embed Perl commands into that script. By inspecting the contents of swatchrc.in , we can see the vulnerability in this process. In version Release 10.1.16.BETA.4200001.UBUNTU24.64 UBUNTU24_64 FOSS edition , this is line 26, specifically the dosnmp call:

Figure 5: Status 1 for service “mailbox”.

However, the service name is built from $args{SERVICE} and is vulnerable to injection through log messages matching the service format. Injecting a log message is straightforward, as Postfix already records pieces of what any given SMTP client sent. So an attacker just needs to send a message that will end up in this log file. One method of doing this is to supply a message with an invalid address syntax.

A normal SMTP message includes a MAIL FROM section, denoting the sender, and a RCPT TO , specifying the recipient, along with DATA , which is the message. The first two require the email address to be wrapped in angle brackets; for example, . If an attacker doesn’t follow the wrapping and omits the final > , the specified unclosed address will show up in the log file. For example, an address of . Instead of supplying a valid host and service, the service can be replaced with arbitrary commands; for example $(touch /tmp/manual_test.txt) . This will then be run as the original Perl process calls /bin/sh to send the notification. With this, the attacker has arbitrary remote code execution (RCE) on the target, including the ability to masquerade as other email identities from this server.

The full chain, from inbound message to code execution, is as follows:

Malformed RCPT TO logged to /var/log/zimbra.log.

Log line matches the service status pattern.

Backticks pass $args{SERVICE} to /bin/sh.

Code execution, identity access.

Why most public CVE-2026-73570 PoCs fail

Given the ability to execute arbitrary code, an attacker can use a number of different mechanisms to establish persistence and gain further access. In testing these approaches, we found that many of the existing PoCs didn’t fully establish the RCE chain. In some cases, the PoCs wrote incorrectly formatted commands to the log file, preventing their execution. As a result, we developed a PoC that runs a variety of commands. We also include tests that run against a remote host and send a callback to a locally running web server. With this approach, we can see that the attack works without causing any additional on-disk changes to the target:

Figure 8: PoC successful execution using a callback.

How to patch and detect CVE-2026-73570

Zimbra has patched this vulnerability. To remediate and detect CVE-2026-73570, take the following steps:

Upgrade to Zimbra 10.1.20 or later. This is the only complete fix.

Upgrade to Zimbra 10.1.20 or later. This is the only complete fix.

Install Elastic Defend (if you haven’t already).

Install Elastic Defend (if you haven’t already).

Enable the Zimbra Swatchdog SNMP Command Injection Execution security information and event management (SIEM) rule to detect exploitation and to hunt retroactively for pre-patch attempts.

Enable the Zimbra Swatchdog SNMP Command Injection Execution security information and event management (SIEM) rule to detect exploitation and to hunt retroactively for pre-patch attempts.

The Zimbra Swatchdog detection rule identifies a sequence of processes that break from the normal Zimbra pattern. First, a shell process, /bin/sh in the prior example, is started from a parent watchdog script Perl process and has snmptrap in its command arguments, matching the expected call /opt/zimbra/common/bin/snmptrap ... ZIMBRA-MIB::zmServiceName s mailbox ... from earlier. Second, the rule detects a subprocess launched by the shell identified in the first step, provided that the subprocess isn’t snmptrap . Since the only process that should run under legitimate circumstances is snmptrap , this is a very strong indicator of successful exploitation.

If you detect a compromise, hunt for:

Standard indicators of remote code execution on the host.

Standard indicators of remote code execution on the host.

Phishing emails originating from the server.

Phishing emails originating from the server.

Compromise of local databases and signing keys, as well as LDAP exports.

Compromise of local databases and signing keys, as well as LDAP exports.

Less direct surfaces beyond the mail store itself.

Less direct surfaces beyond the mail store itself.

Zimbra detection rules in Elastic Security

Zimbra Swatchdog SNMP Command Injection Execution

Zimbra Swatchdog SNMP Command Injection Execution

CVE-2026-73570: Zimbra Collaboration unauthenticated RCE via Swatchdog/SNMP log-injection command injection swatchrc dosnmp Perl backtick

CVE-2026-73570: Zimbra Collaboration unauthenticated RCE via Swatchdog/SNMP log-injection command injection swatchrc dosnmp Perl backtick

Unauthenticated command injection on internet-facing mail servers: tracking CVE-2026-73570

Unauthenticated command injection on internet-facing mail servers: tracking CVE-2026-73570

Zimbra Daffodil (v10.1.20) Patch Release

Zimbra Daffodil (v10.1.20) Patch Release

php2shell: Assessing Elastic detection coverage relevant to CVE-2026-109618 and CVE-2026-109619

Cloud Threat Emulation on Autopilot: Context is Everything

Linux Detection Engineering - Local Privilege Escalation

How to correlate Kubernetes audit logs with container runtime data

REVSTEALER ramps up: analysis of up-and-coming infostealer