CISA Flags Actively Exploited Zimbra Command-Injection Flaw

CISA has added CVE-2026-73570, an unauthenticated command-injection vulnerability in Zimbra Collaboration Suite, to its Known Exploited Vulnerabilities catalog after confirming exploitation in the wild.

The flaw affects Zimbra Collaboration releases earlier than 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. A successful attack can execute operating-system commands as the zimbra user.

⚠️ Immediate priority: Administrators should identify affected Zimbra servers, install version 10.1.20 or later, and investigate previously exposed systems for possible compromise.

⚡ Vulnerability at a Glance

🛡️ What CISA Confirmed

CISA added CVE-2026-73570 to the Known Exploited Vulnerabilities catalog on August 21, 2026. The catalog listed August 24 as the remediation deadline for affected US federal civilian agencies under the applicable binding directive.

KEV inclusion is operationally important because it represents observed exploitation rather than a risk inferred only from a severity score or proof of concept.

CISA has not publicly identified the attackers, disclosed the number of compromised systems or provided a complete technical account of the campaign.

The vulnerability was published in the National Vulnerability Database on August 13. It carries a CNA-assigned CVSS 3.1 score of 8.9 and is classified as a high-severity command-injection issue.

🔍 Which Zimbra Servers Are Affected?

The documented exposure is narrower than “every Zimbra server.” According to the Zimbra advisory and the NVD record, the vulnerable configuration requires all three of the following conditions:

• Software version: Zimbra Collaboration earlier than 10.1.20.
• Optional component: The zimbra-snmp package is installed.
• Active setting: SNMP notifications are enabled.

The vulnerable SNMP notification process does not adequately sanitize untrusted input. An unauthenticated attacker can send specially crafted SMTP requests that may result in arbitrary operating-system command execution.

The attack requires no valid Zimbra account and no user interaction. Its attack complexity is rated high, and the configuration requirements narrow the affected population, but neither condition is sufficient reason to delay verification.

💡 Important distinction: A server is not confirmed safe merely because administrators do not actively use SNMP monitoring. The installed package and current notification settings must be checked directly.

📨 Why This Vulnerability Matters

Mail servers are high-value infrastructure. They process untrusted internet traffic, store sensitive communications and frequently connect to identity systems, internal applications and administrative services.

The documented execution context is the zimbra account rather than unrestricted root access. Administrators should not treat this as a reliable security boundary.

Command execution under an application account may still allow an attacker to access application data, alter accessible files, interrupt email services or establish a starting point for additional activity.

✅ What Administrators Should Do Now

1. Inventory every Zimbra deployment. Identify installations running releases earlier than 10.1.20.
2. Inspect the SNMP configuration. Confirm whether zimbra-snmp is installed and whether notifications are enabled.
3. Prepare a verified backup. Confirm that required mailbox data and configuration can be recovered before the upgrade.
4. Install the security update. Move affected servers to Zimbra Collaboration 10.1.20 or a later supported release.
5. Review exposed systems. Examine SMTP, application, process and operating-system logs for unexpected activity.
6. Check for persistence. Investigate unexplained files, child processes, scheduled tasks, account changes and outbound connections.
7. Preserve evidence when necessary. If suspicious activity is found, follow the incident-response process before rebuilding the server.

🚨 Patching is not incident recovery: Installing version 10.1.20 closes the documented vulnerability, but it does not remove changes made during an earlier compromise.

❌ Mistakes to Avoid

• Checking only the version number. Previously exposed servers may require forensic review even after they are updated.
• Assuming SNMP is absent. Optional packages and inherited configurations can remain after monitoring systems are retired.
• Waiting for a public exploit. CISA has already confirmed exploitation in the wild.
• Treating normal email delivery as proof of safety. A compromised server may continue operating without obvious disruption.
• Rebuilding immediately after detecting anomalies. An unplanned rebuild can destroy evidence needed to determine what happened.

📌 What Remains Unknown

Available public advisories do not establish the scale of exploitation, identify the operators or provide a complete public set of indicators of compromise.

These gaps limit attribution, but they do not reduce the remediation priority for systems matching the affected configuration.

The operational conclusion is clear: inventory Zimbra servers, verify their SNMP configuration, update affected installations to 10.1.20 or later, and investigate exposed systems for evidence of prior command execution.

🔗 Official References

• Zimbra Collaboration Security Vulnerability Advisories
• CISA Known Exploited Vulnerabilities Catalog
• NIST National Vulnerability Database: CVE-2026-73570
• Canadian Centre for Cyber Security Advisory AV26-816