CVE-2026-73570: How Zimbra's SNMP notification path became command injection

CVE-2026-73570 is an unauthenticated command-injection flaw in Zimbra's optional SNMP notification path. A specially formed email could influence a service-status value later interpolated into a shell command; Zimbra fixed the invocation in 10.1.20. Microsoft later reported scanning tools probing the vulnerable path before public disclosure.^{[1], [2], [5]}

CVSS vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L^{[5], [10]}

💡 Plain English Explainer (ELI5)

A mailroom clerk copies a label from an incoming envelope into a work order. The old process handed the entire work order to a command interpreter, which could mistake label characters for extra instructions. The fix gives the notification program a list of separate arguments, so the label stays data instead of becoming shell syntax.^{[8], [9], [3]}

Core Concepts & Subsystem Terms

swatchdog: A log-monitoring process used by this Zimbra path to match service-status messages and trigger notification code.^[1]
SNMP trap: A notification sent by a managed system to an SNMP monitoring receiver when an event occurs.^[1]
Shell interpolation: Building a command string that a shell parses. Characters in untrusted values can then change how the command is interpreted.^{[8], [7]}
List-form system call: Perl's multi-argument system form starts the program directly and passes each argument separately instead of asking a shell to parse one command string.^{[9], [3]}

Framework mappings

CWE reference for the weakness described in this guide: CWE-78
CISA KEV — added 2026-08-21 — CVE-2026-73570

Root Cause Analysis

The affected code is in rpmconf/Conf/swatchrc, function dosnmp. A swatch rule captures a service name from a status line and passes it through donotify as SERVICE; dosnmp then inserted that value into a backtick command containing $snmptrap. Because backticks invoke a shell, data from the log-derived service value could be interpreted as command syntax. The documented preconditions are conjunctive: Zimbra Collaboration Suite before 10.1.20, the optional zimbra-snmp package installed, and SNMP notifications enabled. Microsoft reports that crafted SMTP input could reach the notification path. It observed scanning tools probing the vulnerable injection point from July 28 through August 7, 2026, after the July 20 patch and before the August 13 public disclosure. Zimbra's fix replaces the shell string with Perl's list-form system(...), supplying the executable and arguments as separate values; the shell is no longer in the execution path. This analysis concerns the SNMP notification code only and does not imply that every Zimbra installation or SMTP message is vulnerable.^{[1], [2], [3], [5], [7]}

CVE-2026-73570 reachability and remediation matrix

Deployment conditions	Does the documented path apply?	Defensive action
Zimbra Collaboration Suite before 10.1.20; optional `zimbra-snmp` package installed; SNMP notifications enabled.	All three conditions are required for the documented notification path. Microsoft reports crafted SMTP input could influence the service-status value later handled by `dosnmp`.	Upgrade to 10.1.20 or later. Review relevant logs and process telemetry for the exposed period; treat indicators as investigation leads, not proof of compromise.
`zimbra-snmp` package absent, or SNMP notifications disabled.	The described `dosnmp` notification path is not active under this configuration. This does not establish that the server is free of other vulnerabilities.	Keep the feature disabled or package absent until the server is patched. Inventory all mailbox nodes and confirm the setting on each.
Zimbra Collaboration Suite 10.1.20 or later, with the vendor-fixed package installed.	The documented shell-command construction is fixed in 10.1.20. A version string alone does not verify every node or local modification.	Verify the installed release and package on every node, then follow normal incident triage for any earlier period that met the three exposure conditions.

Step-by-Step Attack Flow

Step 1

Required Zimbra features are present

The server runs a release before 10.1.20, has the optional zimbra-snmp package installed, and has SNMP notifications enabled. If those components are absent or disabled, this documented path is not reachable.^[1]

Step 2

Mail input reaches service monitoring

Microsoft reports that a specially crafted SMTP request could influence a service-status value recorded in Zimbra's logs. This article omits exploit strings and network instructions.^[1]

Step 3

swatchdog routes the value to the notification handler

A watch rule matches the status line, captures the service field, and passes it through donotify to dosnmp when SNMP notifications are active.^[1]

Step 4

Shell parsing turns data into command syntax

Before the fix, dosnmp used Perl backticks around a command string that included the captured service value. The shell parsed that whole string in the Zimbra service account's context.^[1]

Step 5

10.1.20 removes the shell boundary

The patch invokes snmptrap with list-form system and separate arguments. Upgrade to 10.1.20 or later; investigate potentially exposed systems because patching does not establish whether earlier activity occurred.^[1]

Source Code: Flaw vs. Secure Implementation

The vulnerable backticks pass one interpolated command string to a shell. The upstream patch uses Perl's multi-argument system form and supplies the executable path and each argument separately, preventing shell metacharacters in SERVICE from becoming shell instructions. The snippet focuses on the exact changed call; it is not a runnable exploit or a complete copy of the configuration file.^{[3], [4], [8], [9]}

Source excerpt: rpmconf/Conf/swatchrc: dosnmp

UNPATCHED FLAW

# Condensed from the affected dosnmp implementation; no exploit input shown.
sub dosnmp {
    my %args = (@_);
    `$snmptrap $snmpsvctrap $snmpsvcname s $args{SERVICE} $snmpsvcstatus i $statuses{$args{STATUS}}`;
}

HARDENED SECURE PATCH

# Zimbra 10.1.20 fix: invoke the program directly with separate arguments.
sub dosnmp {
    my %args = (@_);
    system(
        "/opt/zimbra/common/bin/snmptrap",
        "-v", "2c", "-c", "zimbra", $traphost, "",
        $snmpsvctrap, $snmpsvcname, "s", $args{SERVICE},
        $snmpsvcstatus, "i", $statuses{$args{STATUS}}
    );
}

Engineering & System Hardening Checklist

✓Upgrade every Zimbra Collaboration Suite deployment earlier than 10.1.20 to 10.1.20 or later; verify the installed package versions on all mailbox nodes.^{[2], [1]}
✓Inventory whether zimbra-snmp is installed and whether SNMP notifications are enabled. If patching is delayed, remove the optional package or disable notifications as applicable, and restrict SMTP and SNMP access to trusted systems.^[1]
✓Treat internet-reachable, unpatched instances meeting both feature preconditions as exposed. Review Zimbra logs and endpoint telemetry for unexpected service-status values and unusual child processes launched from Perl or swatchdog.^{[1], [6]}
✓If exposure existed before patching, follow incident-response procedures: preserve logs, scope affected mailbox nodes, review persistence and account activity, and rotate secrets when evidence or exposure warrants it.^{[1], [6]}
✓In code review, prohibit shell-string execution for values derived from logs, mail, or other external input. Prefer argument-vector APIs; if a shell is unavoidable, use a rigorously constrained interface and independently validate allowed values.^{[8], [9], [7], [3]}
✓Add a regression test proving that a service value is passed as one literal argument and cannot cause a shell to be started; test the notification path with benign metacharacter strings in an isolated test harness.^{[3], [9]}