How Attackers Used a Zimbra SNMP Flaw to Deploy Web Shells and Steal Mail Secrets

A patched-but-slow-to-update vulnerability in Zimbra's optional SNMP notification package gave attackers a path straight through the email server's front door — no credentials needed.

When Zimbra released version 10.1.20 on July 20, 2026, most administrators probably didn't move quickly. The patch notes mentioned an SNMP notification issue — not exactly the kind of thing that sets off alarm bells. The flaw only triggered when an optional monitoring package was installed and a non-default configuration was active. That combination of conditions turned out to be more common than anyone hoped.

Eight days after the patch shipped, attackers were already probing. Microsoft's threat intelligence team tracked the activity from July 28 through late August and documented what followed on compromised servers: JSP web shells across multiple application directories, a privilege-escalation technique that abused Zimbra's own service helpers to rewrite PAM configuration, extraction of every authentication secret the platform stores centrally, and in at least one case, an attempt to ship the entire mail store to Azure Blob storage.

CERT Polska reported active exploitation on August 17, 2026 [1]. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on August 21 and gave federal agencies three days to patch [2]. Microsoft published its full technical breakdown on September 30 [3]. By then the window for catching this early had long since closed for unpatched organizations.

What the Vulnerability Is

CVE-2026-73570 is an OS command injection flaw classified under CWE-78. It carries a CVSS 3.1 score of 8.9 (High), with the full vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L [2]. No authentication required. No user interaction. The attack complexity is rated High because the vulnerable configuration — the optional zimbra-snmp package installed with SNMP notifications enabled — has to be present.

The mechanism is subtle. When Zimbra's health monitoring system (swatchdog) detects a service state change, it passes service name values into a snmptrap shell invocation. If that service name contains shell metacharacters supplied by an attacker through a crafted SMTP request, and if the input isn't properly sanitized, those characters execute as operating system commands. The resulting execution runs as the zimbra service account — not root by default, but still broad enough to access the platform's configuration files, authentication secrets, and mailbox data [3].

The entry point matters here. The exploit reaches Zimbra through SMTP — the port that an internet-facing mail server has to have open to function. There's no obscure admin panel to hide, no management port to restrict. The attack surface is the mail server's core job.

What the Attackers Actually Did

Microsoft's telemetry covered activity between July 28 and late August, starting before the CVE was publicly disclosed on August 13. The early phase was reconnaissance: between July 28 and August 7, two distinct scanning tools probed the injection path using out-of-band callbacks to services like oast.fun and dnslog.pp.ua, using lightweight DNS, ICMP, and HTTP requests to confirm that commands would execute — without dropping any payload [3]. This kind of pre-disclosure probing, done before most administrators knew the flaw existed, is a pattern that recurs with Zimbra vulnerabilities specifically.

Once exploitation began in earnest, the attackers followed a structured playbook across multiple compromised hosts. Not every server exhibited every step, but the pattern across cases was consistent enough that Microsoft could map it cleanly to MITRE ATT&CK.

Getting In and Planting Web Shells

The initial SMTP request passed shell metacharacters into the snmptrap invocation through swatchdog. When the Zimbra health monitor triggered on a service state change, the injected command executed. Attackers used this initial access to drop JSP web shells into Zimbra's Jetty and mailboxd application directories — multiple copies, spread across directories for redundancy. In some cases they temporarily enabled write access to a public directory, dropped the shell, then restored the original permissions to reduce the visibility of the change during basic checks [3].

Web shells aside, the initial command execution also launched reverse shells using OpenSSL's s_client through a named FIFO pipe — an encrypted interactive connection back to attacker infrastructure with no additional tooling required beyond what ships with most Linux systems.

Privilege Escalation Through Zimbra's Own Helpers

Getting code execution as the zimbra service account is useful but not root. The privilege escalation technique Microsoft documented is worth understanding. The attackers targeted the interaction between Zimbra's zmmailboxdmgr, its writable log directory, and the sudo PAM configuration. By replacing a legitimate log file with a symlink pointing to /etc/pam.d/sudo and then invoking the privileged zmmailboxdmgr, the attacker caused the PAM configuration file to become owned by the zimbra account. From there, a pam_exec session hook triggered through the legitimate zmstat-fd helper created a NOPASSWD: ALL sudoers entry for zimbra. Temporary files were cleaned up; the sudoers entry remained [3].

A second persistence mechanism used a systemd service named zimlog.service — plausible enough to look like a Zimbra logging component. It was installed in /etc/systemd/system/, timestomped to match the modification dates of legitimate services like sshd.service, then enabled to run at boot.

Harvesting Authentication Secrets

What the attackers went after next is instructive. Rather than individually harvesting mailbox passwords, they used zmlocalconfig -s to expose the platform's centralized service credentials — LDAP, MySQL, Postfix, Amavis, and replication accounts. Those credentials then fed authenticated LDAP queries targeting zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret [3].

The zimbraAuthTokenKey is the signing key for all user session tokens across the platform. Possessing it means you can generate valid authentication tokens for any account on the system without knowing anyone's password. zimbraPreAuthKey allows construction of pre-authenticated login URLs for arbitrary users. These aren't ordinary credentials — they're the master keys to the entire Zimbra deployment.

Lateral Movement and Mailbox Exfiltration

Zimbra cluster deployments maintain SSH trust between nodes using a shared identity at /opt/zimbra/.ssh/zimbra_identity. The attackers used this to move from the initially compromised host to peer mailbox nodes, transferring web shells and helper scripts via rsync [3]. The design feature that makes multi-node Zimbra administration convenient became the lateral movement path.

In one campaign, a Go binary (identified internally as zimbra-exfil/client-dump) read /opt/zimbra/conf/localconfig.xml, extracted service account credentials, and used them to export the full contents of Zimbra's MySQL database — mailbox records, metadata, mobile device registrations, out-of-office rules. Collected files were compressed into a ZIP archive in a timestamped working directory under /tmp/zimbra_dump_YYYYMMDD_HHMMSS/.

On at least one compromised server, the attacker archived recent mailbox backup content as /opt/zimbra/final.tar.gz, downloaded AzCopy, and attempted to transfer the archive to an Azure Blob Storage container. Microsoft noted that available evidence does not confirm the transfer completed successfully [3].

The Remote-Access Agent

A separate campaign thread used a multi-stage payload chain. A shell downloader (agent2.sh) retrieved a Go binary called zimdown2, which then installed a full remote-access agent called zimclient2. The final agent provided interactive shell access, bidirectional file operations, and SOCKS5 proxying over WebSocket, TLS, or raw TCP — multiple transport fallbacks for resilience. Persistence mechanisms included systemd services, OpenRC scripts, cron entries, shell startup files, SSH authorized keys, and local account creation [3].

Who Was Exposed

The vulnerability affects Zimbra Collaboration Suite versions earlier than 10.1.20 when both conditions are present: the optional zimbra-snmp package is installed, and SNMP notifications are enabled. Organizations that never installed the SNMP monitoring package are not affected through this path.

Microsoft observed affected organizations across multiple regions and industries. The Shadowserver Foundation tracked compromised internet-facing Zimbra instances climbing from roughly 155 on August 20 to at least 274 by August 22, 2026, with more than 8,200 vulnerable servers still unpatched at that time [4].

Timeline

• June 26, 2026 — Zimbra published a security bulletin describing the SNMP flaw and a temporary mitigation.
• July 20, 2026 — ZCS 10.1.20 released with the permanent fix.
• July 28–August 7, 2026 — Pre-disclosure probing activity observed by Microsoft, targeting the injection path without deploying payloads.
• August 13, 2026 — CVE-2026-73570 publicly disclosed.
• August 17, 2026 — CERT Polska published its advisory confirming active exploitation in the wild.
• August 21, 2026 — CISA added CVE-2026-73570 to the KEV catalog.
• August 24, 2026 — Federal remediation deadline expired; Shadowserver reported 274 compromised instances.
• September 30, 2026 — Microsoft published detailed technical analysis of the full attack chain.

What to Do Now

If you're running Zimbra and haven't already patched: upgrade to 10.1.20 immediately. That's the permanent fix [3].

If patching isn't immediately possible, uninstall the zimbra-snmp package and disable SNMP notifications. This removes the vulnerable code path. Restrict SMTP and SNMP access to trusted hosts in the interim.

Patching alone isn't enough for servers that were already exposed. CERT Polska's original advisory pointed defenders to /var/log/zimbra.log for suspicious service restart entries and to Zimbra's web application directories for unexpected files created by the zimbra user [5]. Based on Microsoft's detailed breakdown, the hunt list should also include:

• Unexpected JSP files in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and mailboxd/webapps/ directories across all cluster nodes — not just the primary
• Systemd service files in /etc/systemd/system/ installed outside Zimbra's application directories, particularly any with names that blend in (zimlog.service, chronyd-helper.service, syslog_init.service)
• Modifications to /etc/pam.d/sudo or new entries in /etc/sudoers.d/
• Recent invocations of zmlocalconfig -s and ldapsearch queries against Zimbra LDAP attributes
• Archive files staged under /opt/zimbra/ or /tmp/zimbra_dump_*/

Rotate all Zimbra authentication secrets — zimbraPreAuthKey, zimbraAuthTokenKey, zimbraTwoFactorAuthSecret, and LDAP/MySQL service account passwords — regardless of whether you find evidence of compromise. If these were accessible to attackers, rotating them is the only way to invalidate any material they may have collected.

Microsoft also recommends treating reverse-shell alerts on internet-facing mail servers as priority incidents, and not relying solely on named-malware detections. Several of the most consequential outcomes in documented compromises — including full mail store staging for an exfiltration attempt — involved no malware family, just an interactive shell [3].

Why Mail Servers Are Worth This Effort

Zimbra keeps getting targeted, and the attack here makes the reason obvious. A self-hosted mail server holds not just email content but credentials, authentication tokens that can generate sessions for any account on the platform, SSH keys that link cluster nodes, and LDAP secrets that expose the entire directory. The zimbra service account has intentionally broad read access to all of it. When attackers land on an email server, they're not just reading messages — they're collecting the material needed to impersonate users, authenticate to connected systems, and move laterally without the usual friction of credential theft.

The pre-disclosure probing timeline is also worth noting as a pattern. Attackers scanned this flaw eight days after the patch and nine days before the CVE was public. Organizations that were watching for a public exploit or CVE announcement as their trigger to patch were already behind. For Zimbra specifically, which has been exploited through multiple vulnerabilities over the past several years, the default posture should probably be treat available patches as urgent rather than waiting for confirmation of exploitation — by the time that confirmation arrives, it's been arrived at by counting compromised servers.

What Remains Uncertain

The identity of the threat actors behind these campaigns hasn't been established. Microsoft explicitly noted that multiple actors with different toolsets appear to be involved — the zimclient2 campaign and the direct web shell campaigns show different tooling and infrastructure. No group has been publicly attributed [3].

Whether exfiltration attempts succeeded is also unconfirmed in the specific cases Microsoft examined. The AzCopy transfer on one server was initiated but available evidence doesn't confirm it completed. Other instances may have different outcomes that weren't captured in Microsoft's telemetry.

Scope of overall compromise across the broader Zimbra population is also unknown beyond Shadowserver's count of internet-facing instances showing signs of exploitation. On-premises Zimbra deployments not visible to external scanning wouldn't be captured in those numbers.

Sources & References

1. CERT Polska / SecurityAffairs — Poland's CERT confirms active exploitation of CVE-2026-73570, August 21, 2026.
   https://securityaffairs.com/?p=197610
2. NVD / CISA KEV — CVE-2026-73570 entry with CVSS 3.1 score, vector, CWE, and KEV listing details.
   https://cvemon.intruder.io/cves/CVE-2026-73570
3. Microsoft Security Blog — Unauthenticated command injection on internet-facing mail servers: tracking CVE-2026-73570, September 30, 2026.
   https://www.microsoft.com/en-us/security/blog/2026/09/30/unauthenticated-command-injection-on-internet-facing-mail-servers-tracking-cve-2026-73570/
4. SecurityAffairs / Shadowserver — CISA adds CVE-2026-73570 to KEV; 274 Zimbra servers compromised, August 22, 2026.
   https://securityaffairs.com/?p=197693
5. The Hacker News — Attackers Exploit Zimbra SNMP Flaw, covering CERT Polska advisory and initial exploitation details, August 2026.
   https://thehackernews.com/2026/08/attackers-exploit-zimbra-snmp-flaw-for.html