Attackers are exploiting a Zimbra Collaboration flaw that turns crafted SMTP requests into operating-system commands on the mail server. No login is required. Successful commands run as the zimbra user, giving the attacker access to the same files and services available to that account.
The path is narrower than Zimbra’s entire installed base. The CVE record says CVE-2026-73570 affects releases before 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. CERT Polska reported active exploitation on August 17. CISA’s catalog entry set an August 24 due date for covered federal systems after listing CVE-2026-73570 on August 21.
Exploitation reached mail servers
Zimbra’s advisory describes the fix in one sentence: “Fixed a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled.” The vendor identifies 10.1.20 as the fixed release. Older supported versions and unsupported installations should be treated as affected when they meet the package and notification prerequisites because the public sources list no backported fixed build.
The exposure begins on SMTP, the service that receives mail. CISA says a specially crafted SMTP request can reach the vulnerable processing and execute arbitrary operating-system commands. This is a server-side path: a mailbox user does not have to open a message or click a link.
CERT Polska adds two configuration details. Its notice says snmp_notify must be enabled and the swatchdog service must be running; the service is enabled by default. The optional monitoring component watches service-state events and produces SNMP notifications. The flaw fails to sanitize untrusted text before notification processing uses it, allowing message-controlled data to cross into a shell command.
SMTP crossed into SNMP
The public chain has four established steps. An unauthenticated sender submits crafted SMTP data. Zimbra records a service-status event. The SNMP notification path processes attacker-controlled text without sufficient neutralization. The operating system then runs the injected command under the zimbra account.
Figure details
The figure separates two lanes. The affected command path starts with an external sender delivering a crafted SMTP request to a Zimbra server. Service-status monitoring passes attacker-controlled text into the SNMP notification component. On a pre-10.1.20 server with zimbra-snmp installed and snmp_notify enabled, insufficient sanitization lets that text reach a shell command running as the zimbra user. The evidence path moves from unexpected service text in the log, to files created under webapps or /tmp, to process and file evidence of host execution. A footer states that public sources name no operator, victim count, common payload, or ransomware use.
That privilege boundary matters operationally. The flaw does not directly grant root in the published record, yet the zimbra account owns important application paths and data. CERT Polska specifically asks administrators to examine /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/ for files the account created during the previous 30 days. A file planted in a web application directory could outlive the one command that created it.
The sources do not name an operator, victims, an affected geography, a common payload, or later attacker behavior. CISA marks known ransomware use as Unknown. CERT Polska and CISA establish active exploitation, while neither source quantifies exploited servers or successful compromises.
Logs separate attempts from execution
Start recognition with the configuration state. A server before 10.1.20 with zimbra-snmp installed and snmp_notify enabled matches the published exposure conditions. A current version, an absent monitoring package, or disabled notifications changes that assessment, but version 10.1.20 or newer is the vendor’s durable fix.
CERT Polska supplies two log patterns for /var/log/zimbra.log:
Service status change: <malicious payload> changed from stopped to running
Service status change: <malicious payload> changed from running to stoppedOrdinary service changes can use the same surrounding words. The useful signal is unexpected text in the service-name position, especially shell syntax, paths, encoded strings, download utilities, or commands that do not correspond to a configured Zimbra service. A suspicious SMTP request or malformed log entry establishes an attempt. A child process, created file, outbound connection, persistence change, or altered application content establishes host execution or follow-on activity.
Files owned by zimbra in the three named directories are also leads rather than automatic proof. Compare their paths, timestamps, hashes, and deployment provenance with the mail server’s package database, release records, and configuration-management history. Preserve the logs and files before cleanup so the event can be reconstructed.
Verify exposure and execution
Run the following inventory on every Zimbra node, using the platform’s normal privilege controls:
sudo -iu zimbra zmcontrol -v
sudo -iu zimbra zmlocalconfig snmp_notify
dpkg-query -W -f='${Status} ${Version}\n' zimbra-snmp 2>/dev/null || rpm -q zimbra-snmpThe expected remediated result is Zimbra Collaboration 10.1.20 or newer on every relevant node. That release supersedes all affected pre-10.1.20 builds described by the advisory. The package and configuration results identify which older nodes had the vulnerable path available; retain those results for incident scoping even after upgrading.
Search the published log pattern and the 30-day file locations:
sudo grep -E 'Service status change: .+ changed from (stopped to running|running to stopped)' \
/var/log/zimbra.log
sudo find /opt/zimbra/jetty/webapps /opt/zimbra/jetty_base/webapps /tmp \
-xdev -user zimbra -type f -mtime -30 \
-printf '%TY-%Tm-%TdT%TH:%TM:%TS %u %m %p\n'The expected clean result is a fully upgraded fleet, no unexplained text in the service-name field, and no zimbra-owned file that falls outside the known application and deployment baseline. Investigate every positive with process, file, network, package, and change-history evidence. Isolate a server when those records show command execution or when critical telemetry cannot account for an exposed system during the exploitation window.
Patching closes the vulnerable notification path. It cannot reconstruct commands that already ran. A defensible result pairs 10.1.20 or newer with a documented review of the specific log and filesystem evidence on every server that previously met the exposure conditions.