CISA Warns of Active Exploitation in Zimbra Collaboration Suite
CISA Warns of Active Exploitation in Zimbra Collaboration Suite
CISA has added CVE-2026-73570, an operating-system command injection flaw in Zimbra Collaboration Suite, to its Known Exploited Vulnerabilities catalog after evidence of active exploitation. The issue deserves fast attention from mail administrators because it sits in a high-value system, can be triggered remotely, and has a remediation deadline of August 24, 2026 for organizations following CISA's binding operational guidance.
The vulnerability affects Zimbra Collaboration versions before 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. NVD describes the bug as a remote code execution condition caused by improper sanitization of untrusted input during SNMP notification processing. An unauthenticated attacker can send crafted SMTP requests that may execute operating-system commands as the zimbra user.
This is not just a scoring exercise. CISA's SSVC data marks exploitation as active, and CERT Polska has warned of an ongoing campaign targeting vulnerable Zimbra deployments. The practical priority is straightforward: identify exposed Zimbra servers, verify whether the vulnerable SNMP notification path is enabled, upgrade to 10.1.20 or later, and review logs for compromise indicators.
What changed
Zimbra's own security advisory lists a fix for a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled. The fix release is 10.1.20.
CISA added the flaw to KEV on August 21, 2026, with a due date of August 24, 2026. KEV entries are reserved for vulnerabilities with evidence of exploitation, which makes this a near-term operational item rather than a theoretical backlog ticket.
NVD's record adds the deployment detail that matters most: Zimbra Collaboration before 10.1.20 is affected when zimbra-snmp is installed and SNMP notifications are enabled. The attack vector is network-based, requires no privileges, and does not require user interaction, although the CVSS entry currently lists attack complexity as high.
Why mail servers make this worse
Mail infrastructure is rarely a quiet asset. It is internet-facing, trusted by users, tied to identity workflows, and rich with sensitive business communication. Once attackers gain execution as an application user, the next questions are usually about persistence, mailbox access, lateral movement, and whether credentials or message data were exposed.
That does not mean every Zimbra deployment is vulnerable in the same way. The vulnerable path depends on the optional SNMP package and notification configuration. But that condition should not become an excuse to wait. Administrators need to verify the actual state of their servers, not rely on assumptions about default settings or old build notes.
This is also a good reminder that command injection in infrastructure software often creates asymmetric risk. The vulnerable feature may be narrow, but the asset can be central. A mail platform compromise can quickly become an incident that spans security, legal, compliance, and executive communication.
Immediate triage
Start with inventory. Find Zimbra Collaboration servers, confirm their version, and identify systems below 10.1.20. Then check whether zimbra-snmp is installed and whether SNMP trap notifications are enabled through snmp_notify.
Patching should be the default outcome. Zimbra lists 10.1.20 as the fixed release, and CISA's KEV due date is tight. If a system cannot be upgraded immediately, reduce exposure around the vulnerable condition, disable unnecessary SNMP notification functionality where operationally possible, and treat the host as needing heightened monitoring until the upgrade is complete.
CERT Polska recommends reviewing /var/log/zimbra.log for suspicious service status changes that include unexpected payload-like values. It also recommends checking for files created by the zimbra user during the last 30 days in paths such as /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/.
Those checks should be paired with normal incident-response hygiene: preserve relevant logs, review recent mail-server authentication activity, look for unusual child processes under Zimbra services, and confirm whether any web shells, scheduled tasks, or persistence mechanisms were dropped.
What defenders should prioritize today
For operations teams, the first goal is to separate affected systems from merely present systems. Zimbra before 10.1.20 plus the vulnerable SNMP notification setup should become the highest-priority lane.
For detection teams, the strongest signals are likely to come from a combination of mail logs, process execution telemetry, filesystem changes under Zimbra-controlled paths, and outbound connections from the mail server. A single log line may not prove compromise, but unusual service state changes, newly written files, and unexpected shell activity should be investigated together.
For leadership, the message is simple: this is an actively exploited flaw in a mail collaboration platform with a vendor fix available. The right question is not whether the CVSS score is dramatic enough; it is whether the organization has confirmed its Zimbra exposure and closed the vulnerable path before attackers do.
References
- CISA Known Exploited Vulnerabilities catalog entry for CVE-2026-73570
- NVD record for CVE-2026-73570
- Zimbra Security Advisories
- CERT Polska advisory 145/2026