An exploited Zimbra flaw needs a version check

What has changed

CISA added CVE-2026-73570 to its Known Exploited Vulnerabilities catalogue on 21 August, saying the decision was based on evidence of active exploitation. CISA describes an unauthenticated attacker sending specially crafted SMTP requests that may execute operating-system commands as the Zimbra user. It does not say that every Zimbra deployment has been compromised, and the cited sources do not attribute the activity to a named actor or ransomware campaign.

Zimbra's 10.1.20 release documents a command-injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled. The vendor calls 10.1.20 the permanent fix and strongly recommends upgrading. This is distinct from the browser-rendered email issue covered here in July: it concerns server-side mail infrastructure rather than a user viewing crafted content in the Classic Web Client.

What administrators can verify

The vendor sources identify 10.1.20 as the fixed Zimbra Daffodil release and state that the vulnerable SNMP monitoring path depends on SNMP notifications being enabled. They do not provide a complete table of every affected older branch. Zimbra's security guidance notes that only supported versions are referenced and that older unsupported versions often share vulnerabilities, so an old installation should not be assumed safe simply because it is absent from the current release page.

CISA's federal deadline of 24 August applies to US civilian agencies, not UK businesses. Its inclusion is still useful evidence for prioritisation because KEV listing confirms exploitation. UK teams should set their own operational deadline according to exposure, service criticality and the time needed to preserve evidence and update safely.

What defenders should do

Inventory production, standby and supplier-operated Zimbra servers. Record the complete release and patch level, whether SNMP notifications are enabled, who owns the service and whether SMTP or administration interfaces are reachable from untrusted networks. Check the installed version locally through an authorised administrative route; a banner or external scan is not enough to settle patch state.

For supported 10.1 deployments below 10.1.20, plan the vendor-supported update to 10.1.20 or a later supported release. For other or unsupported branches, obtain branch-specific guidance from Zimbra rather than assuming that a 10.1 package applies. Back up configuration and relevant evidence, test mail flow, monitoring, authentication and integrations after maintenance, and retain useful mail, proxy, system and administrative logs for proportionate review.

Restricting management access and unnecessary service exposure remains sensible defence in depth, but neither action should be presented as the vendor fix. If logs show unexplained service-user commands, configuration changes or access around the vulnerable service, use the organisation's incident process and preserve evidence before making broad changes.

• Locate every on-premises, hosted and standby Zimbra instance.
• Capture the exact release, patch level and SNMP notification state.
• Move affected supported systems to the appropriate fixed release.
• Test mail flow, monitoring, authentication and integrations afterwards.
• Preserve and review relevant evidence where exposure or anomalies justify it.

The Beekeeper view

Mail infrastructure is both a business-critical service and an internet-facing parser of untrusted input. That combination makes an exploited command-injection flaw an operational priority, but urgency should not erase precision: teams still need the actual installed build, relevant configuration and supported update route.

The durable control is an asset record that connects each mail server to its owner, patch branch, monitoring configuration, maintenance route and evidence sources. Then a KEV addition becomes a short decision backed by facts, not an archaeological dig through somebody else's inherited server.