CVE-2026-73570 Exploited Against Zimbra Servers

Brendan Smith
Brendan Smith - Cybersecurity Analyst
7 Min Read
Zimbra CVE-2026-73570 crafted email becoming a server command
A crafted SMTP message can reach the Zimbra SNMP notification component and trigger server commands on vulnerable installations.

CISA added CVE-2026-73570 to its Known Exploited Vulnerabilities catalog on August 21, confirming that attackers are using the Zimbra Collaboration flaw in the wild. The command-injection path affects ZCS versions before 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. An unauthenticated attacker can send a crafted SMTP request that leads to operating-system commands running as the zimbra user.

Administrators who meet those conditions should update to 10.1.20 or later immediately and investigate the period before the patch. Installing the fixed version closes the documented path, but it does not remove a web shell, modified file, stolen credential, or other persistence created during an earlier compromise.

Which Zimbra servers are affected?

The vulnerable path is narrower than “every Zimbra server,” but it is still urgent because no account or user click is required. Check the installed version, whether the optional SNMP package is present, whether snmp_notify is enabled, and when that configuration became reachable through the mail service.

  • ZCS 10.1.20 or later: The documented flaw is patched. Confirm the upgrade completed on every node and review earlier exposure if the vulnerable configuration existed before the update.
  • Earlier ZCS without zimbra-snmp: The optional component required by the documented attack path is absent. Verify that across all nodes and upgrade to a supported current release.
  • Earlier ZCS with the package installed but SNMP notifications disabled: The published conditions are not all met. Verify the current and historical snmp_notify state, then patch rather than treating configuration alone as a permanent fix.
  • Earlier ZCS with zimbra-snmp installed and notifications enabled: Treat the server as vulnerable. Preserve evidence, install 10.1.20 or later, and hunt for signs of exploitation.

Zimbra’s advisory lists the fix in 10.1.20 and notes that unsupported older releases can share vulnerabilities even when only supported versions appear in its table. If a legacy deployment cannot move directly to 10.1.20, contact Zimbra support for a supported upgrade path instead of assuming the old branch is unaffected.

How the SMTP-to-SNMP command injection works

The entry point is an SMTP message, but the vulnerable code is in Zimbra’s SNMP monitoring and notification processing. When the optional package and notifications are active, attacker-controlled input can reach a command context without proper sanitization. The result is command execution as the zimbra operating-system user.

This is a server-side issue. A mailbox user does not need to open an attachment, click a link, or approve a prompt. The public advisories do not identify the attacker, provide a victim count, or establish ransomware use. CISA lists ransomware use as unknown, so claims about a named campaign or payload would go beyond the available evidence.

What to check for exploitation

CERT Polska reported an active campaign and published two concrete hunting paths. Review /var/log/zimbra.log for unusual service-status changes in which attacker-controlled text appears before either of these transitions:

  • changed from stopped to running
  • changed from running to stopped

Also identify files created by the zimbra user during at least the previous 30 days in these locations:

  • /opt/zimbra/jetty/webapps/
  • /opt/zimbra/jetty_base/webapps/
  • /tmp/

Do not delete a suspicious file before recording its path, owner, timestamps, hash, and surrounding process or network activity. A matching log line or unexpected web-root file is a reason to escalate the incident. The absence of those artifacts is not proof that exploitation did not occur: logs may have rotated, the attacker may have used another filename, and a compromised account can be used after the original entry point is closed.

Zimbra CVE-2026-73570 response checklist

  1. Record the exposure state. Document the ZCS version on every node, the presence of zimbra-snmp, the snmp_notify setting, public mail reachability, and the earliest date that configuration existed.
  2. Preserve volatile and short-lived evidence. Save Zimbra, mail, authentication, reverse-proxy, firewall, EDR, and relevant system logs before routine rotation or cleanup removes them.
  3. Update to 10.1.20 or later. Follow Zimbra’s release guidance and verify the running version after services restart. CISA’s August 24 due date is mandatory for covered U.S. federal agencies, but other organizations should not treat it as a safe waiting period.
  4. Hunt beyond the patch. Review files owned by zimbra, web application directories, new processes, scheduled jobs, SSH keys, accounts, outbound connections, and changes to mail or proxy configuration.
  5. Contain and rotate secrets if compromise is suspected. Isolate affected nodes without destroying evidence. Revoke administrative sessions and rotate service, mailbox, API, database, and infrastructure credentials from a known-clean system after containment.
  6. Restore trust deliberately. If command execution is confirmed or system integrity cannot be established, rebuild from known-good media and restore only verified data and configuration.

The older Zimbra SQL injection update covers different vulnerabilities and versions. Do not use its fixed-build table for CVE-2026-73570. The important distinction here is the optional SNMP configuration, the 10.1.20 fix, and the need to investigate the pre-patch window after active exploitation.

FAQ

Can a normal Zimbra user be infected by opening an email?

The published CVE-2026-73570 path does not require a recipient to open or click the message. It targets a vulnerable server configuration during SMTP and SNMP notification processing. Users should not turn this into a claim that every delivered email or mailbox was compromised.

Does updating Zimbra prove the server is clean?

No. Version 10.1.20 fixes the documented command-injection path, but a successful attacker could have changed files or credentials before the update. Patch status and incident status answer different questions.

References

  1. Cybersecurity and Infrastructure Security Agency. “CISA Adds One Known Exploited Vulnerability to Catalog.” CISA, August 21, 2026. CVE-2026-73570 KEV addition and remediation date.
  2. Zimbra. “Patch Release Update: Zimbra 10.1.20.” Zimbra Blog, July 20, 2026. vendor fix and affected component.
  3. CERT Polska. “Aktywnie wykorzystywana podatność w Zimbra Collaboration Suite.” CERT Polska, August 17, 2026. active-exploitation notice and hunting paths.
Share This Article
Cybersecurity Analyst
Follow:
Brendan Smith has spent over 15 years knee-deep in cybersecurity, chasing down malware from the gritty reverse-engineering of old-school trojans all the way to wrangling full-blown incident responses for small-to-medium businesses that couldn’t afford a full-blown breach. Over at Gridinsoft, he’s the guy piecing together those double-checked guides on nasty stuff like AsyncRAT ransomware—take last year, for instance, when his breakdowns caught more than 200 sneaky variants right in live scans, knocking user cleanup jobs down by a solid 40% and saving folks hours of headache.
Leave a Comment

AI Assistant

Hello! 👋 How can I help you today?