The Identity Layer Breach
Harvested authentication secrets — specifically the zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret — have transformed the exploitation of CVE-2026-73570 from a localized email breach into a permanent, platform-wide identity compromise. By obtaining these keys, attackers can generate valid session tokens and pre-authenticated login URLs for any account, effectively bypassing traditional credential-based security and maintaining persistent access to the entire Zimbra environment.
The vulnerability, which carries a CVSS score of 8.9, is an unauthenticated OS command injection flaw within the SNMP notification path of Zimbra Collaboration Suite. It requires no user interaction or prior authentication. An attacker can trigger shell command execution as the zimbra service account by sending a crafted SMTP email, provided the optional zimbra-snmp package is installed and SNMP notifications are enabled. This flaw affects all versions prior to 10.1.20, which was released on July 20, 2026.
A Twenty-Day Exploitation Window
The exploitation timeline highlights a critical gap between patch availability and public awareness. Although the patch shipped on July 20, Microsoft observed out-of-band scanning tools probing the injection point between July 28 and August 7. Public disclosure did not arrive until August 13. By August 17, CERT Polska flagged active exploitation, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on August 21, setting a federal remediation deadline of August 24.
The Attack Chain
The operation was multi-staged. After initial access via the SNMP notification path, attackers conducted reconnaissance using specific User-Agents to fingerprint the environment. They deployed JSP web shells across Jetty and mailboxd paths with copies on peer nodes for redundancy, established reverse shells, and escalated privileges to root by abusing Zimbra’s legitimate sudo-authorized helpers and PAM configuration. Persistence came through a systemd service disguised as a logging component. Attackers then used the Zimbra SSH identity to move laterally across the cluster, deploying custom malware — the zimdown2 installer and zimclient2 remote-access agent — before staging data for exfiltration to Azure Blob storage.
What the Keys Actually Unlock
The most damaging phase involved the systematic harvesting of centralized service secrets. As Microsoft’s threat intelligence report states: “The actor targeted Zimbra’s centralized service and authentication secrets rather than individual mailbox passwords.”
By querying the LDAP directory, attackers retrieved the zimbraPreAuthKey, which allows construction of pre-authenticated login URLs for any user account. The zimbraAuthTokenKey is the signing key for user session tokens across the entire platform — possession of this key enables generation of valid session tokens for arbitrary accounts, granting attackers full access without ever needing a password. The zimbraTwoFactorAuthSecret completes the set, neutralizing any two-factor protections configured on the platform.
This is not a temporary foothold. These keys do not expire when passwords change. They represent the cryptographic root of trust for the entire Zimbra deployment.
The Trust-Through-Defaults Pattern
Zimbra’s open-source footprint means self-hosted instances often lag in patching, creating a persistent exploitation window. The vulnerability requires zimbra-snmp to be installed and SNMP notifications enabled — default-enabled services in many deployments. When default configurations are combined with high-privilege service accounts that hold the platform’s authentication signing keys, the exposure surface extends far beyond the initial injection point. This pattern has appeared repeatedly in recent enterprise software failures, including the DIVD Zammad breach, the OpenAI Misalignment Portal, and Langflow’s credential harvesting campaign.
The Agent Security Intersection
Modern email integrations increasingly connect to AI-driven systems for phishing detection, automated classification, summarization, and document parsing. Each integration point — whether through LLM APIs, OAuth tokens, or attachment processing pipelines — relies on the email platform’s authentication layer to establish trust. When that layer’s signing keys are compromised, agents that integrate with the email system inherit the exposure: a stolen zimbraAuthTokenKey could allow an attacker to forge authenticated sessions that appear legitimate to downstream agents, effectively turning the email platform into a trusted conduit for unauthorized agent operations.
What Organizations Should Do
Patch to ZCS 10.1.20 or later immediately. Where patching must wait, uninstall the zimbra-snmp package, disable SNMP notifications, and restrict SNMP and SMTP access to trusted hosts. Rotate all zimbraPreAuthKey values — this is the single most important post-compromise action, since these keys do not expire with password changes. Hunt for web shell persistence across all mailbox nodes, review systemd units for unexpected ownership or timestamps, and treat any reverse-shell alert on an internet-facing mail server as a priority incident. The compromise of these service keys represents a fundamental failure at the identity layer — one that password resets alone cannot remediate.