Zimbra Bug Exploited for Mailbox Theft

A patched command-injection bug in Zimbra Collaboration Suite has already been put to work by intruders. Microsoft's Security Research team says it tracked CVE-2026-73570, an unauthenticated operating system command injection flaw rated 8.9 on the CVSS scale, from initial probing through mailbox collection and an attempted cloud-storage exfiltration.

The finding matters because the affected component, an optional package called zimbra-snmp, sits on internet-facing mail servers that frequently hold the keys to an organization's entire identity stack. Microsoft reported that the activity unfolded between Zimbra's July 2026 patch and the public disclosure of the vulnerability in August 2026.

Inside the SNMP Notification Path

CVE-2026-73570 becomes exploitable when Simple Network Management Protocol notifications are turned on and the optional zimbra-snmp package is installed, according to Microsoft's account. Under those conditions, the flaw can be triggered by a specially crafted SMTP request against an exposed Zimbra server, meaning email traffic alone can reach the vulnerable code path without authentication or any user interaction.

Successful exploitation leads to remote code execution on the mail server. Zimbra addressed the issue in July 2026 with the release of version 10.1.20, but the timeline Microsoft laid out shows that the window between the fix and public disclosure was not quiet.

Microsoft said its telemetry captured the activity "during the interval" between July 20, 2026, when Zimbra version 10.1.20 was released, and August 13, 2026, when the flaw was publicly disclosed. Between July 28 and August 7, 2026, researchers observed two separate out-of-band scanning tools probing the injection path to confirm command execution without delivering any follow-on payload.

What the Intruders Left Behind

The probing did not stay theoretical for long. Microsoft said attackers used the initial access to run commands as the "zimbra" service account and deploy several JSP web shells across Jetty and mailboxd application paths, a redundancy tactic meant to survive cleanup of any single backdoor.

From there, the activity included downloading and executing payloads through wget or curl and establishing interactive reverse shells. Microsoft also described alternative execution chains using cron, systemd and memfd_create to keep code running either on a schedule or entirely from memory.

Stealth was part of the plan. In some cases, attackers temporarily enabled write access to a public directory to drop a web shell and then restored the original permissions, a move Microsoft said limited how visible the change would be during routine permission checks.

"Following successful exploitation, observed activity included deployment of JSP web shells and reverse shells, privilege escalation, persistent remote-access tooling, and memory-backed execution," the tech giant said. "Threat actors also accessed email and collected authentication and mailbox data, with archive creation and subsequent transfer activity observed."

Microsoft said it observed affected organizations in more than one region and industry, though not every host showed every stage of the attack chain. The company stated that it does not currently know who is behind the attacks.

From Mail Server to Identity Store

The most consequential steps came after the intruders had a foothold. According to Microsoft's write-up, they mapped the Zimbra deployment with zmprov to identify mailbox and MTA nodes, checked for the presence of the Zimbra SSH identity, and then used a privilege-escalation technique that granted the "zimbra" service account unrestricted, passwordless sudo access by modifying the "/etc/pam.d/sudo" configuration file.

A second persistence mechanism came in the form of a systemd service named "zimlog.service", which establishes execution at system boot. Rather than attacking individual mailbox passwords one by one, the intruders targeted Zimbra's centralized service and authentication secrets using the "zmlocalconfig -s" command.

The recovered credentials were then used for authenticated LDAP queries to pull high-value attributes including zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret. Those are the kinds of secrets that can be used to mint authentication tokens or undermine two-factor protections across a Zimbra deployment.

Microsoft also described lateral movement built on Zimbra's own SSH identity at "/opt/zimbra/.ssh/zimbra_identity," with rsync used to push JSP web shells and helper scripts between trusted nodes in the cluster. Command execution, payload retrieval and exfiltration of command output ran over an OpenSSL-encrypted reverse shell pointed at attacker-controlled infrastructure.

A Purpose-Built Toolset

In at least one campaign, Microsoft said, attackers used a lightweight shell downloader to fetch the Zimdown2 Go binary, which then acted as an installer for the Zimclient2 remote-access agent. Zimclient2 offers interactive shell access, bidirectional file operations and SOCKS5 proxying, features that make it useful both for hands-on-keyboard work and for pivoting deeper into a network through a compromised mail server.

Persistence tied to that payload appeared in several forms. Microsoft listed systemd services, OpenRC, cron, shell startup files, SSH authorized keys and local account creation.

Separately, the activity involved Zimbra-specific payloads. One Go-based executable attempts to extract Zimbra service-account credentials from "/opt/zimbra/conf/localconfig.xml" and use those values to build MySQL and LDAP connection strings to the Zimbra MySQL instance, then export the contents of several database tables.

• mailbox
• mailbox_metadata
• mobile_devices
• out_of_office
• All tables in the zimbra.* namespace

The implant also collects and stages credential, certificate, LDAP secret, mail-rule and configuration artifacts, compressing the harvested files into a ZIP archive for transfer to a remote endpoint.

Archives, AzCopy and a Blob Target

On one compromised server, Microsoft said, the actor archived recent mailbox-backup content into /opt/zimbra/final.tar.gz. The attacker then downloaded AzCopy from hxxps://aka[.]ms/downloadazcopy-v10-linux and invoked it with an operator-supplied Azure Blob SAS URL targeting wsweb03[.]blob[.]core[.]windows[.]net/log/windows.log.

Microsoft characterized the sequence as mailbox-data collection followed by local archive staging and an exfiltration attempt using cloud-storage tooling, adding that the available evidence does not confirm the transfer completed successfully.

The use of a legitimate Microsoft utility and a cloud storage endpoint is notable in itself: it means the final step of the chain can look like ordinary administration traffic unless egress to blob storage is being watched.

The Patch Timeline and Federal Deadline

Zimbra shipped the fix for CVE-2026-73570 in July 2026 with version 10.1.20. Active exploitation was first highlighted by the Polish Computer Emergency Response Team (CERT Polska) in August 2026, which urged users to review the "/var/log/zimbra.log" file for suspicious Zimbra service restarts and to look for files created in temporary and Zimbra "webapps" directories.

Later that month, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, mandating that federal agencies apply fixes by August 24, 2026. That KEV listing is a signal that exploitation was not confined to a single target, though Microsoft's report does not attribute the activity to a named group.

What the timeline makes clear is that the period between the July 20 patch release and the August 13 public disclosure was not a quiet one. Scanners were already testing the injection path in late July and early August, and the full intrusion chain, from web shell deployment through LDAP secret theft and archive staging, was observed on at least some hosts during that same stretch.

What Defenders Are Advised to Do

The most direct mitigation is to apply the updates. Microsoft advises organizations to patch immediately, and if patching is not an option, it recommends uninstalling the zimbra-snmp package, disabling SNMP notifications, and restricting SNMP and SMTP access to trusted hosts only.

Beyond the patch, the guidance includes rotating Zimbra authentication secrets and scanning the server for redundant web shell persistence. The reasoning behind those steps is visible in Microsoft's findings: because the intruders harvested zimbraPreAuthKey and zimbraAuthTokenKey rather than individual passwords, credentials that were valid before the patch may remain useful to an attacker who already copied them.

The redundant web shells across Jetty and mailboxd paths, the "zimlog.service" systemd unit, the cron and memfd_create execution chains, and the OpenRC, shell startup and SSH authorized-keys persistence all point to a single conclusion for anyone cleaning up an affected host: removing one file is unlikely to be enough.

The file-permission trick Microsoft described, temporarily opening a public directory and restoring it afterwards, also means that a snapshot comparison of directory permissions may show nothing out of place.

Why This Matters Beyond One Mail Server

For most organizations, a mail server is not just a mail server. It holds credentials, authentication material, mail rules and mobile-device records, and it often sits close enough to identity infrastructure that a single compromise can be used to mint tokens or reach other systems. Microsoft's account shows attackers treating Zimbra exactly that way, going after centralized authentication secrets instead of individual mailboxes.

That approach suggests that patching alone may not fully close the door for organizations that were already exposed. If key material such as zimbraAuthTokenKey or zimbraPreAuthKey left the building before the fix went in, rotating those secrets after patching is the only way to make the copied values useless, and Microsoft's guidance explicitly calls for that rotation.

The exfiltration attempt through AzCopy and an Azure Blob SAS URL is a second reason this story extends past the mail server itself. Legitimate cloud tooling and legitimate storage endpoints give an attacker a plausible-looking exit path, which means defenders may need to watch outbound transfers from mail infrastructure the same way they watch the inbound command paths.

Microsoft's finding that the same flaw was exploited across more than one region and industry also indicates this is not a narrowly targeted operation, even though the company says it does not yet know who is responsible. For administrators who have not yet confirmed their Zimbra version or the status of the zimbra-snmp package, the practical takeaway is that the exposure window is defined by configuration, not just by patch level. Until the package is removed or patched, and until any borrowed secrets are rotated, an internet-facing Zimbra box remains an attractive first stop for anyone looking to move quietly from email into the rest of the environment.