Microsoft Threat Intelligence published a detailed analysis of exploitation activity against CVE-2026-73570, an unauthenticated operating-system command injection flaw affecting internet-facing Zimbra Collaboration Suite servers when the optional zimbra-snmp package is installed and SNMP notifications are enabled.

The important part for defenders is not just that this is a mail-server bug. Microsoft described a full intrusion pattern: pre-disclosure probing, command execution through the SNMP notification path, JSP web shells, reverse shells, privilege escalation, credential and authentication-secret collection, lateral movement across Zimbra clusters, persistence, and attempted mailbox-data exfiltration.

Original source: Microsoft Security Blog: Unauthenticated command injection on internet-facing mail servers: tracking CVE-2026-73570.

What happened

CVE-2026-73570 sits in the Zimbra SNMP notification path. In vulnerable configurations, a crafted SMTP request can introduce attacker-controlled input into processing that eventually reaches a shell invocation. That gives an unauthenticated attacker command execution as the Zimbra service account without requiring a user to click anything.

Microsoft reported that Zimbra version 10.1.20, released on July 20, 2026, contains the relevant fix. Public disclosure followed on August 13, 2026. Microsoft telemetry showed activity targeting the same injection path in the window between remediation availability and public disclosure, which is exactly the kind of patch-gap period defenders should treat as high risk for exposed infrastructure.

Why this matters

Mail servers are high-value systems because they sit at the intersection of identity, sensitive communications, password resets, vendor conversations, legal records, invoices, and internal workflow. For SMBs and government contractors, a compromised mail platform can become both a data breach and a launchpad for follow-on fraud or partner compromise.

The observed behavior also shows why “we patched it” is not enough once exploitation is plausible. Microsoft described attackers collecting Zimbra service credentials, authentication keys, mailbox metadata, and other secrets. If those materials were accessed, rebuilding the server without rotating the right keys and reviewing persistence can leave the attacker with a second way back in.

Defensive takeaways

  • Patch Zimbra immediately. Upgrade exposed Zimbra Collaboration Suite instances to 10.1.20 or later.
  • Reduce exposure while validating patch status. If patching is delayed, remove the optional zimbra-snmp package where it is not required, disable SNMP notifications, and restrict SMTP/SNMP access paths as tightly as operations allow.
  • Hunt beyond malware names. Look for suspicious shell activity, permission changes, JSP files in Zimbra application paths, unexpected servlet artifacts, reverse shells, unusual curl/wget execution, memfd_create execution, and new or modified systemd services.
  • Review Zimbra cluster trust. Attackers can abuse existing Zimbra SSH identity and administrative trust relationships to move between mailbox and MTA nodes.
  • Rotate mail-platform secrets after suspected exposure. Focus on Zimbra pre-authentication keys, authentication-token material, LDAP/MySQL service credentials, and any secrets that would enable token creation or mailbox access.
  • Treat mailbox staging as breach-level activity. Archive creation, AzCopy/cloud-storage tooling, mailbox backup access, and unusual outbound transfers from mail servers should trigger containment and legal/privacy review.

Bulwark Black assessment

This is a classic edge-service incident pattern: an internet-facing application flaw becomes command execution, command execution becomes web shells and persistence, and persistence becomes identity and data access. The organizations that recover cleanly will be the ones that already know where their mail servers are, what optional packages are enabled, how service accounts are trusted across nodes, and which secrets must be rotated after compromise.

For small teams, the practical move is to build a short mail-server emergency checklist now: patch level, exposure path, optional components, EDR coverage, webroot review steps, service/unit review, outbound-transfer review, and a secret-rotation plan. Waiting until after a shell alert fires is when these incidents become messy.