Microsoft’s write-up of CVE-2026-73570 puts attacker activity against Zimbra mail servers in the weeks between a vendor fix and its public disclosure. Zimbra shipped the fix in version 10.1.20 on July 20, 2026. Microsoft telemetry shows two scanning tools probing the vulnerable code path from July 28 to August 7. The flaw became public on August 13.
What Microsoft observed
CVE-2026-73570 is an unauthenticated operating system command injection in the SNMP notification path of Zimbra Collaboration Suite. According to Microsoft Security Research, a specially crafted email sent to an internet-facing server can trigger it with no login and no user action. Two conditions have to hold: the optional zimbra-snmp package is installed, and SNMP notifications are enabled. Code runs with the privileges of the zimbra service account.
Microsoft separates the activity into phases. First came probing, using lightweight checks that confirmed commands would run without delivering a payload. After that, Microsoft observed exploitation that included web shells, reverse shells, privilege escalation, persistent remote-access tooling and memory-backed execution. Affected organizations sat in more than one region and industry, and the activity mixed automated payload delivery with hands-on-keyboard work on compromised mail servers.
Media Partner
The sequence matters for defenders deciding where to look. Microsoft says the probes used out-of-band callbacks to confirm execution, which means a server can show no payload at all and still have been tested. The report also says not every host showed every stage of the attack chain, so a clean-looking host is not evidence that nothing touched it.
What the attackers went after
The more instructive part of the report is the target list. Microsoft says the actors went after Zimbra’s central service and authentication secrets rather than individual mailbox passwords. Using recovered service credentials, they queried the directory for the pre-authentication key, the token-signing key and the two-factor secret. Microsoft explains that the token-signing key lets an attacker generate session tokens for arbitrary accounts without knowing any account password.
In the same set of intrusions, Microsoft saw attackers copy web shells to peer mailbox nodes, reuse the cluster’s own trust relationships to move between hosts, and disguise a persistence service as a logging component. In one case the actor staged recent mailbox-backup content and attempted a transfer to cloud storage. Microsoft says the available evidence does not confirm that the transfer completed. Several of the most consequential steps used no malware family at all, only an interactive shell, so antivirus detections alone would not have flagged them.
Why the gap between fix and disclosure matters
Zimbra’s fix existed for 24 days before the flaw was public. Microsoft’s probing window opened eight days after release and closed with 16 days still to go before disclosure. Microsoft does not say how the operators found the vulnerable path, and this piece does not guess. The timeline alone carries the planning lesson, and it is our reading rather than Microsoft’s: a fix reaching customers is the moment the exposure clock starts, whether or not an advisory exists yet.
The pattern is familiar to anyone who has followed edge-device incidents here. CyberTech’s earlier reporting on a Citrix flaw patched weeks after it was exploited covered the opposite order of events, exploitation first and fix later. The Zimbra timeline shows the fix arriving first and attackers still getting a head start on the organizations that waited for the advisory. Our analysis of CISA’s patch deadlines outrunning adoption described the same pressure from the other side: deadlines keyed to a listing date start counting after the work that mattered.
Microsoft’s account also gives teams a way to size the problem. The affected organizations spanned more than one region and industry, so exposure did not depend on sector. It depended on one build of one internet-facing service with one optional package turned on. An asset inventory that records installed packages and enabled features, not only product names, answers the question in minutes.
What it means for the security leader
Mail servers sit on the public internet, hold the whole organization’s correspondence and, in Zimbra’s case, store the keys that sign sessions. A compromise there reaches identity as well as email. Three planning consequences follow.
First, patch intake for internet-facing mail and collaboration servers should start from the vendor’s release date. If the team’s clock starts at the advisory, CVE publication or a government exploited-vulnerabilities listing, the first days of exposure are unmanaged. Second, a patch does not undo what already happened. Any server that ran a vulnerable build while exposed needs a compromise assessment, and Microsoft notes that its own advanced hunting retains 30 days of raw event data, which no longer reaches the pre-disclosure activity it describes. Third, secrets on a mail server are an incident-response scope item. Rotating them is part of recovery, not an extra.
What to do now
Microsoft’s guidance for Zimbra Collaboration Suite operators, in the order it gives it:
- Upgrade every instance to version 10.1.20 or later, which remediates the flaw.
- Where patching has to wait, uninstall the optional zimbra-snmp package, disable SNMP notifications, and restrict SNMP and SMTP access to trusted hosts only.
- Treat reverse-shell alerts on internet-facing mail servers as priority incidents. A confirmed reverse-shell connection means attacker access even when no payload was quarantined.
- Rotate all domain pre-authentication keys, review system services for unexpected ownership, enablement or timestamp changes, and inspect every mailbox node for unexpected JSP files. Removing one known web shell does not prove access is gone.
- Where feasible, confine the mail-stack service accounts with namespace, seccomp or AppArmor controls.
- Search beyond the 30-day hunting window by checking archived logs and Microsoft Sentinel for the second-stage infrastructure listed in the report’s appendix.
Teams that cannot show which Zimbra build they ran between July 20 and August 13 should assume the exposure window applied to them and scope accordingly. The vendor fix is the first step; the review of what ran before it is the second.
