The Zimbra flaw arrives as an email, and what it takes is the pair of keys that make passwords beside the point

Microsoft published its analysis of attacks against Zimbra Collaboration on 30 September 2026, tracking exploitation of CVE-2026-73570. Zimbra fixed the flaw in version 10.1.20, released on 20 July, and the identifier became public on 13 August. The attacks are now.

The vulnerability is an unauthenticated command injection, and the delivery mechanism is the thing a mail server cannot refuse: a message.

An optional package, and then no authentication at all

The vulnerable path only exists where the optional zimbra-snmp package is installed and SNMP notifications are switched on. That is a real precondition, and it is also the kind of thing nobody remembers choosing — monitoring was set up once, years ago, by somebody who has since moved on.

Where it is present, a specially crafted email carrying shell metacharacters reaches the notification processing path, and the commands run with the privileges of the zimbra service account. There is no login, no attachment to open and no user to blame. The server is doing its job, which is to accept mail from strangers.

What the intruders do next

Microsoft's list of observed activity is a tour of a mail server's soft parts.

JSP web shells are dropped across the Jetty and mailboxd directories, more than one of them, so that removing the obvious one leaves the others. Reverse shells follow for interactive access, and root is reached through manipulation of PAM and sudo. Persistence is installed as systemd units with names chosen to read as infrastructure: zimlog.service, chronyd-helper.service.

Then the collection. Mailbox data and email are gathered, archived and moved out, with exfiltration attempted through AzCopy to Azure Blob Storage — a Microsoft-signed utility talking to a Microsoft cloud endpoint, which is a far easier flow to permit than an unknown binary posting to an unknown host.

Microsoft says affected organisations span more than one region and more than one industry, and offers no attribution.

The two keys are the real loss

The part that outlives the incident is the theft of zimbraPreAuthKey and zimbraAuthTokenKey.

The preauth key is what lets a trusted system construct a link that logs a user straight into their mailbox without presenting a password. The auth token key signs the session tokens the platform issues. An attacker holding both can mint a valid session for any mailbox on the server, at any time, without touching a password or a second factor.

So the usual incident checklist does the wrong thing. Patch to 10.1.20 and the injection is closed; force a password reset across the organisation and the users are inconvenienced; and the intruder still mints tokens, because neither action changes the key that signs them. Rotation of those two secrets is the step that ends the access, and it is the step most likely to be missed.

The window was handed over in advance

Three dates make the exposure window, and all three are public.

The fix shipped on 20 July. The identifier was published on 13 August, which tells anyone reading the advisory which component changed and therefore what used to be reachable. Exploitation is being reported at the end of September.

That is six weeks between a public CVE and the attacks Microsoft is describing, on a product whose whole purpose is to sit on the internet and accept connections from anybody. The organisations being hit are not the ones that failed to patch within hours of disclosure; they are the ones that did not patch within six weeks of a fix that was already in a release.

It also means the precondition did the opposite of protecting anyone. A flaw that only works where an optional package is installed reads as low priority on a patch board, which is exactly how a server stays unpatched long enough to be found.

What a defender can actually see

The useful detections here are in the middle of the chain rather than at the start.

The inbound message looks like mail, because it is mail. But the processing path leaves traces: the notification chain spawning a shell, processes whose parent is the mail stack rather than a shell session, and the zimbra account running commands it has no business running.

After that, everything the intruders install is observable if anyone is looking: new systemd units, modified PAM and sudo configuration, JSP files appearing under directories whose contents should only change when the software is upgraded, and a transfer utility making outbound connections to cloud storage that nobody provisioned.

What to do

• Upgrade internet-facing Zimbra to 10.1.20 or later. The fix has been available since July.
• If you cannot upgrade today, remove the zimbra-snmp package or disable SNMP notifications, and restrict SMTP and SNMP reachability to systems you trust.
• Rotate zimbraPreAuthKey and zimbraAuthTokenKey on any server that was exposed, and treat sessions issued before the rotation as untrusted.
• Hunt for more than one web shell. Microsoft describes redundant JSP files across mailbox nodes, so a single deletion proves nothing.
• Review systemd units and PAM and sudo configuration for additions, and look for AzCopy or similar transfer tooling where nobody installed it.

What is not established

• Who is running the campaign. Microsoft publishes no attribution.
• How many organisations have been compromised, beyond the statement that several regions and industries are affected.
• How long exploitation ran before it was observed, given the fix has existed since July.
• How many exposed servers still carry the optional SNMP package, which is the population at risk.