zimbra account under a specific but potentially common configuration.
CISA’s catalog notice establishes active exploitation, but it leaves out the operational details administrators need to decide whether their own mail server was exposed. Zimbra’s security advisory identifies the affected component as SNMP monitoring when notifications are enabled; CERT Polska adds the crucial condition that exploitation affects instances with snmp_notify enabled and the swatchdog service running, which it describes as enabled by default. That makes configuration review as important as version inventory.
The flaw was fixed in Zimbra 10.1.20, according to Zimbra. CERT Polska reported an active exploitation campaign on August 17, four days before CISA added the CVE to KEV. The gap is a useful reminder that waiting for a KEV listing is not a detection strategy: a vendor fix and a national CERT warning can arrive before the U.S. government catalog entry that forces the issue onto many federal patch queues.
The vulnerable path is narrower than “every Zimbra server” — but still serious
CVE-2026-73570 is not a webmail phishing bug or an authenticated admin-console issue. Zimbra describes it as a command-injection vulnerability in its SNMP monitoring component when SNMP notifications are enabled. CERT Polska says an unauthenticated attacker can use the weakness to run arbitrary operating-system shell commands with the permissions of the zimbra user.
That distinction changes the triage process. Organizations should not assume every Zimbra installation is exploitable merely because it is below version 10.1.20; the available technical reporting ties exposure to snmp_notify and swatchdog. Conversely, an organization should not downgrade the risk simply because it does not intentionally use SNMP monitoring. Configuration left behind by an old monitoring deployment, a template, an appliance migration, or a managed-service installation may be enough to expose the path.
The zimbra account is also a consequential foothold. It normally has access to Zimbra’s application files, mail-store functions, logs, service controls, and configuration material needed to operate the collaboration server. The public advisories do not establish that attackers gain root-level control directly through this CVE, and administrators should not overstate that point. But arbitrary command execution in the service context can still support web-shell deployment, mailbox and credential theft, message manipulation, persistence, and follow-on privilege escalation.
Zimbra’s advisory does not yet publish a CVSS score for CVE-2026-73570, and it does not provide a comprehensive affected-version range. Those omissions mean defenders should base their patch decision on the vendor’s fixed release and CISA’s exploitation finding, rather than wait for a severity number that may arrive after attackers have already moved on.
Patch first, then determine whether the server was already used
The practical risk is not limited to an unpatched server at the moment an administrator reads the alert. CERT Polska says it is aware of an ongoing campaign and provides concrete hunting guidance that CISA’s short KEV announcement does not include.
Administrators should preserve relevant evidence before aggressive cleanup, especially if the server is business-critical or holds regulated communications. Review /var/log/zimbra.log for unusual Service status change events in which unexpected command content appears between the service-status text and the state transition. CERT Polska specifically calls out entries resembling a service being changed from stopped to running, or from running to stopped, with a malicious payload inserted into the event.
The advisory also recommends reviewing files created by the zimbra user during the preceding 30 days in these locations:
/opt/zimbra/jetty/webapps/should be checked for unfamiliar web application content, JSP files, altered deployment artifacts, and recently changed application directories./opt/zimbra/jetty_base/webapps/should be reviewed alongside the primary Jetty webapps location, since it can be used to stage application-level persistence./tmp/should be examined for suspicious scripts, downloaders, archive files, cron-related artifacts, and executables associated with thezimbraaccount.
These checks are starting points, not proof of compromise or a complete forensic procedure. A clean result in those three directories does not establish that a server was never exploited, particularly if logs have rolled over or an intruder used a remote command channel without leaving a durable web shell. Still, the specificity is valuable: it tells administrators where active investigation should begin rather than reducing the response to “apply updates.”
For servers with suspicious activity, isolate the host from unnecessary inbound access, retain logs and relevant file-system evidence, rotate Zimbra administrator credentials and any secrets accessible from the host, and review identity-provider, SMTP relay, backup, and management-system credentials that may have been reachable from the compromised account. Rebuilding from a known-good image may be safer than attempting to remove attacker changes from an internet-facing mail server whose integrity is uncertain.
Version 10.1.20 is the remediation floor
Zimbra’s own security-advisory page lists CVE-2026-73570 as fixed in release 10.1.20. Its separate open-source change record dates the 10.1.20 release to July 20, meaning a patch was available before CERT Polska’s August 17 exploitation warning and CISA’s August 21 KEV addition.
For supported deployments, the clean response is to update to 10.1.20 or a newer supported release, validate that the upgraded packages are active, and restart services according to Zimbra’s documented maintenance procedure. A package download alone is not sufficient evidence that the vulnerable service is no longer running.
Older Zimbra environments deserve extra care. Zimbra notes that its advisory table references supported versions, while unsupported releases can share the same weaknesses. An administrator running a legacy branch should not interpret the absence of an explicitly listed patch for that branch as evidence of safety. If a supported upgrade is not immediately possible, disabling the affected notification configuration and restricting network reachability may reduce exposure, but neither is a substitute for installing a version that contains the fix.
The reporting reviewed for this article does not establish whether the vulnerable SNMP path is reachable from the public internet by default, nor does it name the attack group or provide indicators that attribute the current campaign. Those are material unknowns. They do not lessen the response priority, because CISA’s KEV addition is based on evidence that the flaw is being exploited in the wild.
CISA’s new federal directive makes exposure classification part of the response
CISA added this vulnerability under the KEV process while federal civilian agencies are transitioning to Binding Operational Directive 26-04, issued on June 10. The directive replaced the earlier broad KEV remediation approach with a model that weighs whether an asset is publicly exposed, whether the CVE is in KEV, whether exploitation can be automated, and whether compromise grants partial or total control.
The federal directive applies to Federal Civilian Executive Branch agencies, not private companies or state and local governments. But its operating model is relevant to any organization that runs its own collaboration stack: asset exposure and post-compromise impact now determine how fast a patch has to move through the change process.
For CVE-2026-73570, a Zimbra server reachable from the internet deserves the highest attention. It is now a KEV item, and CERT Polska’s description of unauthenticated shell-command execution establishes a path an external attacker can use without first stealing a mailbox credential. Whether a particular deployment meets every condition for the directive’s most accelerated treatment depends on the agency’s assessment and CISA’s catalog data, but the operational conclusion is straightforward: do not place this in a normal monthly maintenance window.
CISA’s BOD 26-04 also requires agencies to check for compromise before patching in designated higher-risk cases. That expectation reflects a hard lesson from exploited perimeter bugs: once an attacker has created persistence, patching removes the initial entry point but does not evict the intruder. Private-sector Zimbra operators should apply the same principle.
Zimbra operators should inventory the configuration, not only the CVE
The fastest useful response is to identify every Zimbra host, record its installed version, determine whether SNMP notifications are enabled, and establish whether swatchdog is running. That inventory should include disaster-recovery systems, standby mail nodes, test environments, and old servers retained for archive or migration work. Those systems are often omitted from normal monitoring yet remain accessible through routes that production teams no longer track closely.
Zimbra administrators should also verify external exposure at the network layer. Review public DNS, reverse proxies, firewall rules, load balancers, cloud security groups, VPN exceptions, and administrative subnets. A system that is nominally “internal” but reachable through a broad management network or an exposed reverse-proxy path should be assessed as a realistic attack target.
CVE-2026-73570 is a patch-and-hunt event. Version 10.1.20 closes the identified SNMP command-injection flaw, while the CERT Polska guidance provides a concrete basis for checking whether an attacker already used it. With active exploitation confirmed by CISA, any Zimbra server below that release should be treated as an urgent remediation target, and any exposed server with the relevant configuration should be investigated as a potential incident rather than merely another overdue update.