Microsoft details Zimbra attacks that steal mailbox authentication secrets
News
Published 1 Oct 2026
Updated 1 Oct 2026
8 min read
Summarize with
Microsoft has published new threat-research findings on compromises of internet-facing Zimbra Collaboration Suite servers through CVE-2026-73570. The vulnerability permits unauthenticated operating-system command injection through crafted SMTP or email input, but only when the optional zimbra-snmp package is installed and SNMP notifications are enabled. The research covers affected organizations in multiple regions and sectors. It does not describe an exploit against Microsoft 365.
The new information concerns the attack activity and its outcomes, not a newly discovered flaw. Zimbra released version 10.1.20 with the fix on July 20, 2026, and CVE-2026-73570 was disclosed on August 13. Microsoft observed probing between July 28 and August 7, before disclosure. Microsoft's threat research was published September 30, 2026 at 14:00 UTC.
What Microsoft found
Successful exploitation gave attackers command execution under the Zimbra service account. Across separate compromised hosts, Microsoft observed JSP webshells, reverse shells, privilege escalation, persistence, service credential collection, Zimbra authentication-key retrieval, cluster movement, and mailbox-data staging. The report combines behavior seen across multiple incidents, so no single server should be assumed to have experienced every step.
One compromised server had recent mailbox backups placed into a local archive, followed by an attempted Azure Blob transfer. Microsoft states that the available evidence does not confirm the transfer completed. That distinction matters: the evidence supports collection and an exfiltration attempt, not a claim of confirmed mass mailbox theft.
|
|
|
|---|---|---|
July 20 | 10.1.20 released | Fix available |
July 28-Aug. 7 | Probing observed | Pre-disclosure activity |
Aug. 13 | CVE disclosed | Public awareness |
Sept. 30 | Research published | Attack details released |
Key dates in the CVE-2026-73570 timeline
Why CVE-2026-73570 was exploitable
The vulnerable path sits in Zimbra's SNMP notification processing. Attacker-controlled input can reach a shell invocation when a service-state change triggers health monitoring. If the required optional package and notification setting are both present, the input can execute commands with the privileges of the zimbra account without a login or user action.
Exposure therefore depends on configuration as well as version. An internet-facing server that lacks the optional package or has SNMP notifications disabled does not meet the prerequisites described by Microsoft. It still needs normal vulnerability management and a configuration review, but operators should avoid treating every Zimbra installation as confirmed compromised.
Safe exposure checklisttext
Product: Zimbra Collaboration Suite Issue: CVE-2026-73570 Required package: zimbra-snmp Required setting: SNMP notifications enabled Fixed release: 10.1.20 or later Exposure: internet-facing SMTP path
The SMTP trigger also explains why perimeter email defenses alone are insufficient. The vulnerable server processes the crafted input before ordinary sender-authentication results can provide meaningful protection against operating-system command injection.
SPF, DKIM, and DMARC evaluate sending authorization, message signatures, and domain matching. They do not sanitize Zimbra's SNMP notification inputs, patch a server package, remove a webshell, or rotate stolen keys.
Flow from crafted SMTP input through SNMP notification processing to Zimbra account command execution.
Observed activity and confirmed limits
The observed post-exploitation activity was serious. Attackers placed JSP webshells in Zimbra application paths, opened interactive reverse shells, and used more than one persistence method. On some systems, they escalated privileges and installed systemd units with names designed to resemble normal logging components.
Other activity included mapping Zimbra cluster roles, using an existing Zimbra SSH identity to reach trusted peer nodes, collecting credentials used by internal services, and querying LDAP for high-value authentication attributes. These findings require host-by-host validation because the report describes multiple investigations, not one universal sequence.
Observed across incidents
- Access: Webshells and reverse shells appeared on compromised hosts.
- Persistence: Unexpected services and recurring access methods were found.
- Collection: Service secrets, auth keys, and mailbox data were staged.
- Movement: Trusted Zimbra cluster connections enabled access to peer nodes.
Not established by the report
- Every host: No host necessarily experienced every documented stage.
- Transfer success: The attempted Azure Blob transfer is not confirmed complete.
- Microsoft 365: The vulnerability affects the described Zimbra configuration.
- Universal exposure: The optional package and notification setting are prerequisites.
Why the stolen Zimbra keys matter
The attackers targeted centralized secrets rather than relying only on individual mailbox passwords. Microsoft observed retrieval of zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret. A preauthentication key can enable preauthenticated login URLs for accounts in the affected domain. An authentication-token key can support forged session tokens if an attacker retains the required context. Two-factor secrets can weaken the protection expected from affected second-factor configurations.
Service credentials associated with LDAP, MySQL, Postfix, Amavis, and replication were also collected in observed activity. Rotating only user passwords therefore leaves material risk. Incident response should identify which centralized secrets existed on each host, where they were trusted, and whether peer systems accepted the same credentials or keys.
Authentication success does not prove server integrity
Mail sent through compromised legitimate infrastructure can still pass SPF and carry a valid DKIM signature. DMARC can also pass when the relevant identifiers match. Those results show that the message used authorized infrastructure and matching identifiers. They do not prove that the mail server, signing key, mailbox session, or sending account remained under legitimate control.
What Zimbra operators should do now
Start by inventorying every internet-facing Zimbra node and confirming the installed version, the presence of zimbra-snmp, and the state of SNMP notifications. Upgrade affected systems to 10.1.20 or later. The fixed release has been available since July 20, so this is remediation of an existing exposure, not a new October deadline.
If patching must wait, Microsoft's guidance says to remove the optional zimbra-snmp package, disable SNMP notifications, and restrict SMTP and SNMP access to trusted hosts where operationally feasible. Access restriction needs careful testing because SMTP reachability is part of normal mail delivery. Do not apply a network control that silently stops required inbound mail.
- Scope exposure: List public Zimbra nodes, versions, packages, notification settings, and cluster trust paths.
- Patch or mitigate: Install 10.1.20 or later, or apply the temporary package, notification, and access controls.
- Preserve evidence: Retain older process, file, SMTP, SNMP, authentication, proxy, and network logs before routine rotation removes them.
- Hunt persistence: Review unexpected JSP files, compiled servlet artifacts, permission changes, cron entries, SSH keys, and systemd units.
- Check peer nodes: Investigate every trusted mailbox and MTA node rather than stopping at the first compromised server.
- Rotate secrets: Replace relevant Zimbra authentication keys and service credentials after containment, then invalidate exposed sessions where supported.
- Validate recovery: Confirm clean startup behavior, expected services, normal outbound destinations, and controlled mail flow before closing the incident.
Historical investigation matters even after an upgrade. The probing window predates public disclosure, and persistence can survive patching. A clean vulnerability scan or a current fixed version does not establish that the host was never compromised.
Secret rotation should follow containment and evidence preservation. Rotating too early can complicate scoping, while rotating before access is removed can give an attacker the replacement values. Coordinate the sequence across Zimbra nodes and dependent services.
Email authentication after containment
Once host containment and secret rotation are complete, check whether the incident changed sending behavior or domain reputation. A controlled email tester run can verify what a real recovered message presents for SPF, DKIM, and DMARC. A broader domain health check can identify damaged or unexpected DNS authentication records. These checks validate mail configuration, not server cleanliness.
Suped's product supports the post-containment workflow through DMARC monitoring for unexpected source or authentication changes and blocklist monitoring for reputation impact. It does not detect CVE-2026-73570 exploitation, perform host forensics, remove persistence, or replace Zimbra patching and secret rotation.
Interpret authentication results narrowly
A DMARC pass after recovery confirms identifier matching for that message. It does not clear the underlying server. Treat email-authentication telemetry as one part of recovery validation alongside host evidence, identity review, key rotation, and outbound-mail analysis.
What this means for mail security
Microsoft's findings show how a server-side flaw can turn legitimate mail infrastructure into a source of identity and reputation risk. The fixed version predates public disclosure, yet pre-disclosure probing still occurred. Operators need both timely patching and enough retained telemetry to investigate activity that becomes clear later.
The response boundary is equally important. SPF, DKIM, and DMARC remain necessary controls against domain spoofing, but they cannot cure command injection on a mail server. For potentially exposed Zimbra systems, the priority is version and configuration verification, historical investigation, persistence removal, coordinated secret rotation, and only then validation of mail authentication and sender reputation.
