Fix released (Zimbra 10.1.20): July 20, 2026 (Source: Microsoft Security (September 30, 2026))
A mail server is more than a place where messages sit. It also holds the keys that decide who is who inside an organisation. Microsoft Threat Intelligence has published a report on CVE-2026-73570, a flaw in the Zimbra Collaboration Suite. It shows what happens when an intruder goes after those keys instead of individual inboxes.
What Microsoft found
Microsoft's threat team followed real attacks that used CVE-2026-73570. The bug lets an outsider run commands on a Zimbra server. No password is needed. No one has to click anything. A specially crafted email is enough.
Not every Zimbra server is exposed. Two conditions must both hold. An optional add-on called zimbra-snmp must be installed. Its SNMP alerts must also be switched on.
Microsoft saw affected organisations in more than one region and industry. It did not give a count of victims.
How the flaw works
Command injection means a system treats text from an outsider as an instruction. Here, a crafted SMTP message carries shell characters into Zimbra's alert handling. SMTP is the standard protocol for sending email. SNMP is a standard way for servers to send monitoring alerts.
Zimbra runs a background health monitor called swatchdog. When a service changes state, swatchdog builds a snmptrap command to send an alert. The attacker's text ends up inside that command, so the server runs it. The command runs as the zimbra service account. Zimbra version 10.1.20 contains the fix.
The gap between fix and disclosure
Between the fix and the public disclosure, Microsoft saw two separate scanning tools probe the vulnerable spot. Microsoft first saw this probing on July 28. The probes sent callbacks to public interaction services. HTTP requests carried a User-Agent string containing ZB73570. The aim was to confirm that commands ran, without delivering a payload.
The report does not say how the operators found the injection point. This is one incident, not a trend. It does show one case where a vendor's fix and a public CVE were 24 days apart. Microsoft's telemetry recorded activity against the same path in that period.
What intruders did with the access
Microsoft's activity diagram combines behaviours seen across several confirmed compromises. Not every host showed every stage. The privilege escalation described below was confirmed on one server.
In observed cases, attackers left JSP web shells. These are small web pages that give remote control of a server. In the escalation case, the attacker then took steps to gain root, the highest level of access.
The attacker replaced a Zimbra log file with a symlink, a pointer, to the PAM configuration that governs sudo sessions. That let them modify it. They added a hook that ran as root. The hook created an unrestricted sudo entry for the zimbra account. They then restored the original PAM content but kept the new entry.
Attackers also installed a service named zimlog.service. The name looked like part of Zimbra. Its timestamps were changed to match rsync.service and sshd.service. Using Zimbra's own SSH identity, they copied tools and web shells to peer mail nodes.
The real target was the keys
The attackers ran a command, zmlocalconfig -s, that exposed credentials for LDAP, MySQL, Postfix, Amavis and replication. LDAP is the directory that stores account data. The attackers then queried that directory for three items: zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret.
Microsoft explains what these keys do. The auth token key signs user session tokens. With it, an attacker can create sessions for any account without its credentials. The pre-authentication key can build login links for any user.
This shows why a mail server breach is also an identity problem. Resetting user passwords may not cancel stolen signing keys. That conclusion is ours, not a finding in Microsoft's report.
On one server, the actor archived mailbox backups and tried to send them to Azure Blob storage using AzCopy. Microsoft says the evidence does not confirm the transfer finished.
Questions to put to your team
First, is every Zimbra server on 10.1.20 or later? Second, was zimbra-snmp ever installed, and are SNMP notifications on? Servers without both fall outside the conditions Microsoft describes.
Third, for servers that ran unpatched, has anyone checked for the behaviours Microsoft observed? These include unexpected sudo entries for the zimbra account, a zimlog.service file, and JSP files in public web folders. Fourth, would an incident here trigger rotation of the auth and pre-authentication keys, not just passwords?
Finally, how quickly does your team apply new vendor releases? In this case, a fix existed 24 days before the CVE was publicly disclosed. A patch on a mail server closes the entry point. It does not remove what an intruder already placed inside.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Microsoft Security.
