Zimbra SMTP Exploitation Makes SNMP Monitoring An Incident Boundary

CISA added CVE-2026-73570 in Zimbra Collaboration Suite to the Known Exploited Vulnerabilities catalog on August 21. The flaw can let an unauthenticated attacker send specially crafted SMTP requests that reach the SNMP notification path and execute operating-system commands as the Zimbra service user. The vulnerable condition is narrower than every Zimbra deployment: the optional zimbra-snmp package must be installed, SNMP notifications must be enabled through snmp_notify, and CERT Polska says the swatchdog service must be running. It is enabled by default in the relevant deployments.

Zimbra fixed the command injection in 10.1.20, released July 20, and describes that release as the permanent fix. CERT Polska says it has seen an active campaign and provides a 30-day hunt window, log strings, and three file-system locations for review. Operators should preserve evidence before updating, verify all three preconditions, install a supported fixed release, and treat positive indicators as a server compromise. CISA's August 24 due date applies to covered federal agencies under BOD 26-04; other organizations should use the KEV entry and the observed campaign as urgent risk evidence, not as proof that their own mail server was breached.

The CVE record describes improper sanitization in Zimbra's SNMP notification processing. An unauthenticated attacker can send specially crafted SMTP requests and, when the vulnerable monitoring path processes attacker-controlled input, execute arbitrary operating-system commands as the Zimbra user. SMTP exposure is important because accepting mail from outside networks is a normal function of a public mail server. Protecting only the web client or administration console does not establish that this path is unreachable.

NVD records a CVSS 3.1 vector with network access, high attack complexity, no privileges, no user interaction, changed scope, and high confidentiality and integrity impact. CISA's current SSVC enrichment marks exploitation active and technical impact total. Those labels establish urgency, but they do not add a public exploit transcript, victim count, attacker identity, or complete post-compromise sequence. CISA also lists known ransomware use as unknown.

Execution is reported as the Zimbra service user, not root. That is a meaningful technical limit and should remain in incident communications. It is not a reason to classify the result as harmless. A mail-service identity can reach application files, message-processing components, configuration, logs, and connected services according to the permissions of that deployment. Investigators must determine the actual reachable data and privilege on each host instead of assuming either total system ownership or no sensitive access.

The vulnerable condition is not simply any server with the letters SNMP in its inventory. CERT Polska identifies three requirements: the optional zimbra-snmp package is present, the snmp_notify setting enables SNMP traps, and swatchdog is running. The advisory notes that swatchdog is enabled by default, but package installation and notification state still need local verification. Record the evidence from the running host rather than relying only on an old build sheet or a configuration-management database.

Build an inventory that separates Internet-facing mail exchangers, internal relays, mailbox nodes, monitoring nodes, standby systems, and disaster-recovery images. For each system, capture the installed and running Zimbra version, package state, snmp_notify value, swatchdog state, SMTP reachability, public names and addresses, load balancers, network translations, and the dates those conditions applied. A server that is not vulnerable now may still have been exposed earlier in the 30-day review window.

Disabling notifications or removing an unused optional package can remove a precondition while maintenance is prepared, but Zimbra names 10.1.20 as the permanent fix. Do not treat a web application firewall as a complete substitute when the trigger travels through SMTP. Likewise, blocking all external SMTP may be technically effective but operationally equivalent to taking a receiving mail service offline. The right temporary control depends on whether the affected component is actually required and on the organization's tested mail-continuity plan.

Zimbra released 10.1.20 on July 20 and rated the patch security severity high with low deployment risk. The release note calls the SNMP correction a permanent fix for a critical issue first disclosed in a June advisory. It also includes unrelated security fixes for the Classic Web Client, mail forwarding, EWS, mailbox delegation, and a Nextcloud integration. Those additional changes make a carefully staged update more important, not less.

The current vendor security table lists 10.1.20 as the fix for CVE-2026-73570 and explains that only supported versions appear in the table. It warns that older unsupported releases often share vulnerabilities and should be moved to a supported version. NVD describes affected Zimbra Collaboration versions as those before 10.1.20. Administrators should not infer that an older 10.0, 9.0, or 8.8.15 build is safe merely because the vendor does not list a parallel patch for it.

Follow Zimbra's supported package-update process, preserve a recoverable backup, and validate service dependencies before maintenance. After the update, verify the installed packages, the running version on every node, normal SMTP delivery, mailbox access, monitoring, extensions, and failover. Remove or update dormant images and automation that could restore a vulnerable build. A successful package-manager exit code does not prove that every cluster member restarted on the fixed code.

CERT Polska recommends searching /var/log/zimbra.log for service-status messages containing a malicious payload and checking files created by the Zimbra user during the previous 30 days under /opt/zimbra/jetty/webapps, /opt/zimbra/jetty_base/webapps, and /tmp. Preserve those records, relevant package and configuration state, a timestamped file listing, process and network data, and available mail, identity, endpoint, DNS, proxy, firewall, and backup logs before restarts or upgrades rotate them.

Treat the CERT entries and paths as high-value starting points, not a complete detection signature. Review unexpected child processes, shell invocation, web content, scheduled jobs, service or startup changes, SSH material, new accounts, outbound connections, archive creation, and modifications outside normal deployment windows. Compare application files and packages with trusted artifacts. Separate normal administrative activity from attacker behavior using timestamps, operator records, change tickets, and known monitoring actions.

A negative search does not conclusively clear a server. Retention may be shorter than the exposure window, log entries may have been removed, payloads can change, and files can be deleted after execution. Document which evidence sources existed, which time periods they cover, and what telemetry was unavailable. That record makes the final assessment reviewable and prevents a thin log search from becoming an unsupported declaration that no compromise occurred.

If the server met all vulnerable preconditions and was reachable but the preserved evidence shows no suspicious activity, install the fixed release urgently, tighten the monitoring surface, and continue heightened review. If the CERT indicators, unexplained command execution, altered files, persistence, or suspicious outbound activity appear, isolate the host and treat it as compromised. Installing 10.1.20 over an attacker-controlled system cannot prove that unauthorized changes or credentials have been removed.

Rebuild confirmed compromised nodes from trusted media or a verified pre-compromise baseline using a supported fixed version. Restore only reviewed configuration and data, validate cluster membership, compare deployed application content with trusted sources, and reconnect the server in stages. Rotate operating-system, Zimbra administration, directory, database, backup, monitoring, API, and relay credentials that were present or usable from the host. Replace TLS keys where evidence or access rights make exposure plausible.

Scope mailbox and tenant actions to evidence. Review administrator changes, authentication events, delegated access, forwarding rules, filters, application passwords, active sessions, OAuth integrations, and bulk mail access where logs support those questions. Do not claim that every message, address book, password, or mailbox was stolen solely because the server was vulnerable. Notify affected people and partners with the confirmed time window, data boundary, actions taken, and remaining unknowns.

Monitoring is often trusted because it observes production rather than serving users directly. This case shows why that trust model is incomplete. A notification component parsed data derived from hostile SMTP traffic and crossed into a command context. Optional operational tooling belongs in the external-input threat model whenever it consumes mail headers, message metadata, log lines, alerts, or protocol events that an unauthenticated sender can influence.

Remove unused packages and features, run mail services with the least practical operating-system authority, centralize security logs outside the host, and restrict management and monitoring access to dedicated networks. Baseline files in executable web paths, alert on unusual child processes and outbound destinations, and separate monitoring credentials from mailbox and directory administration. A monitoring failure should not grant a quiet route to durable application control.

Finally, rehearse a mail-server recovery that does not depend on the suspected host. Keep trusted packages and configuration evidence outside the cluster, document MX and relay failover, preserve a route for incident communications, and know how to verify queued and delivered mail after restoration. Email is both a business channel and an authentication dependency. Recovering it safely requires version proof, evidence preservation, secret decisions, and continuity testing as one coordinated operation.