Microsoft Tracks Active Zimbra CVE-2026-73570 Exploitation: Web Shells, Root Escalation, Stolen Secrets

Microsoft Catches Threat Actors Actively Exploiting Zimbra CVE-2026-73570

Microsoft Threat Intelligence has published a detailed account of active, in-the-wild exploitation of CVE-2026-73570 (CVSS 8.9), the unauthenticated OS command injection flaw in Zimbra Collaboration Suite (ZCS) that CosmicBytez Labs first covered when it was disclosed on August 22, 2026. The new research, published September 30, 2026, shows the vulnerability was weaponized well before that public disclosure — and that successful exploitation has repeatedly escalated into root-level compromise, cluster-wide lateral movement, and theft of Zimbra's centralized authentication secrets, not just a single mailbox breach.

Unlike the original disclosure, which focused on the vulnerability mechanics, this is a threat-activity story: who is exploiting the flaw, what tooling they are using, and what they are doing once inside a compromised mail server.

Campaign Snapshot

How Attackers Are Weaponizing CVE-2026-73570

Reconnaissance Started Before Public Disclosure

Microsoft observed scanning activity against the SNMP injection point more than two weeks before CVE-2026-73570 was publicly disclosed. Between July 28 and August 7, 2026, two distinct scanning tools probed vulnerable servers, using public out-of-band interaction services — including oast.fun, oast.online, dnslog.pp.ua, and requestrepo.com — to confirm that injected commands actually executed before any payload was dropped. This pattern indicates attackers either discovered the patch-gap independently or reverse-engineered the fix in Zimbra 10.1.20 before Zimbra's own advisory went public.

Initial Access and Web Shell Deployment

Exploitation itself follows the documented flaw: a specially crafted SMTP request introduces shell metacharacters into Zimbra's swatchdog-to-snmptrap execution chain, which runs with the privileges of the zimbra service account — no credentials or user interaction required. From that foothold, attackers used curl and wget (with fallback mechanisms if one tool was unavailable) to pull down second-stage payloads.

Persistence centered on JSP web shells written into Zimbra's Jetty and mailboxd application directories. Rather than dropping a single shell, operators staged payloads from base64- and gzip-encoded fragments, assembled them on disk, and then deleted the staging files to reduce forensic traces. Shells were deliberately replicated across peer mailbox nodes so that detecting and removing one copy would not cut off access.

Additional persistence mechanisms observed include:

• A disguised systemd service (zimlog.service) installed to blend in with legitimate Zimbra units, with timestamps altered to match existing services
• Cron entries, including @reboot triggers, for recurring execution
• memfd_create-backed, memory-only execution to avoid writing some payloads to disk at all
• Reverse shells and detached background processes for ongoing interactive access

Privilege Escalation via PAM Abuse

The most notable technical detail in Microsoft's writeup is a privilege-escalation chain that turns zimbra-user access into full root control by abusing Zimbra's own helper processes:

1. Attackers identified a writable Zimbra log file (tied to the mailbox-manager helper) and replaced it with a symbolic link to /etc/pam.d/sudo.
2. A trusted Zimbra component then wrote log content through that link, effectively making the PAM sudo configuration attacker-controlled.
3. Attackers inserted a pam_exec hook that runs a malicious script as root whenever sudo authentication occurs.
4. That hook added a passwordless (NOPASSWD: ALL) sudoers entry for the zimbra account, granting unrestricted root access without ever needing a password.
5. In several cases, the original log file and PAM configuration were restored afterward to reduce the chance of detection during routine file-integrity checks.

Lateral Movement Across Clusters

Zimbra multi-node deployments commonly trust each other through a shared SSH key (stored at /opt/zimbra/.ssh/zimbra_identity) used for legitimate inter-node replication. Attackers reused that same trust relationship, connecting non-interactively between cluster nodes and using rsync to copy web shells, scripts, and payload fragments — then deleting the source files on the origin host after a successful transfer. In this way, a single internet-facing Zimbra server with the vulnerable SNMP package became a pivot point into an entire mail cluster.

In at least one observed intrusion, attackers deployed a Go-based remote access agent offering interactive shell access, file transfer, and SOCKS5 proxying — giving operators a general-purpose foothold independent of the original web shells.

Credential and Mailbox Secret Harvesting

Credential theft was a central objective of the campaign, and attackers went well beyond individual mailbox passwords. Using root access obtained through the PAM chain, operators ran zmlocalconfig -s to dump Zimbra's centralized service credentials for LDAP, MySQL, Postfix, Amavis, and replication components, and pulled service-account passwords directly from /opt/zimbra/conf/localconfig.xml.

With recovered LDAP access, attackers specifically queried for:

• zimbraPreAuthKey — enables generation of pre-authenticated login URLs for arbitrary accounts without needing a password
• zimbraAuthTokenKey — enables forging signed session tokens for arbitrary accounts, effectively bypassing authentication entirely
• zimbraTwoFactorAuthSecret — undermines two-factor protections on affected accounts

Possession of either key lets an attacker impersonate any mailbox on the server going forward, independent of whether the original web shells are ever found and removed — which is why Microsoft and other researchers treat this as a full domain-level credential compromise rather than a single-server incident.

Data Staging and Exfiltration Attempts

Attackers also queried MySQL directly for mailbox, metadata, mobile-device, and out-of-office tables, and ran LDAP exports (slapcat) to capture directory contents. In at least one documented case, harvested data was archived on the compromised server (observed as /opt/zimbra/final.tar.gz) and an attempt was made to upload it to Azure Blob Storage using the legitimate AzCopy utility. Microsoft noted that available evidence does not confirm the transfer completed successfully in that instance, but the intent to exfiltrate bulk mailbox and credential data was clear.

Impact Assessment

Recommendations

For Zimbra Administrators

• Patch immediately to Zimbra 10.1.20 or later if not already done. This remains the single most effective mitigation.
• If patching must be delayed, uninstall the zimbra-snmp package or disable SNMP notifications entirely — the vulnerability cannot be triggered without them.
• Restrict SMTP and SNMP exposure to trusted hosts at the network perimeter rather than relying solely on the application layer.
• Treat any server that was internet-facing with zimbra-snmp enabled between July 20 and patch application as potentially compromised, not just vulnerable.

For Security Teams / Incident Responders

• Hunt for redundant JSP web shells across Jetty, mailboxd, and related webapp directories on every node in a Zimbra cluster — not just the externally reachable host.
• Audit systemd units and cron jobs for unfamiliar or timestomped entries such as zimlog.service, and review /etc/pam.d/sudo and the sudoers file for unauthorized pam_exec hooks or passwordless entries tied to the zimbra account.
• Check authorized_keys and SSH trust relationships between cluster nodes for unexpected reuse or additions.
• Rotate zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret, along with LDAP, MySQL, Postfix, Amavis, and replication credentials, on any server that was ever exposed — assume these were harvested even without direct proof.
• Review outbound traffic for unexpected use of AzCopy, rsync to unfamiliar hosts, or connections to out-of-band interaction domains such as oast.fun, oast.online, dnslog.pp.ua, or requestrepo.com.
• Retain and review logs beyond the typical 30-day window where possible — pre-disclosure reconnaissance in this campaign began weeks before the public advisory.

For End Users / Mailbox Owners on Affected Servers

• Assume historical mail on an affected server may have been read during the exposure window, even absent a specific notification.
• Watch for account activity that does not correspond to a normal login (forged session tokens generated via stolen key material will not necessarily trigger a password-based alert).
• Re-enroll two-factor authentication and change passwords once the organization confirms remediation, since underlying secrets — not just individual passwords — were targeted.

Key Takeaways

1. CVE-2026-73570 exploitation began before public disclosure. Microsoft observed reconnaissance starting July 28, 2026 — more than two weeks ahead of the August 13 advisory — indicating attackers found or reverse-engineered the flaw directly from the July 20 patch.
2. This is not a single-mailbox incident. A documented PAM/pam_exec abuse chain escalates zimbra-user access to unrestricted root, and shared inter-node SSH trust lets attackers pivot across an entire Zimbra cluster.
3. Centralized secrets, not just passwords, were the target. Theft of zimbraPreAuthKey and zimbraAuthTokenKey lets attackers impersonate any account without needing individual credentials, surviving routine password resets.
4. Attackers engineered for persistence and stealth. Redundant web shells, timestomped systemd units, staging-file cleanup, and restored PAM/log files were all used to survive detection and removal attempts.
5. Exposure remains widespread. Over 8,200 internet-facing, unpatched instances were still identified as of late August 2026, alongside 274 confirmed compromises.
6. No single actor has been attributed. Microsoft describes a mix of automated and hands-on-keyboard activity across multiple regions and industries, consistent with more than one group exploiting the same flaw independently.

Sources

• The Hacker News — Attackers Exploit Zimbra Flaw to Deploy Web Shells and Harvest Authentication Secrets
• Microsoft Security Blog — Unauthenticated command injection on internet-facing mail servers: tracking CVE-2026-73570
• GBHackers — Zimbra Vulnerability Exploited to Gain Root Access and Steal Mailbox Authentication Secrets

Related Reading

• CVE-2026-73570: Zimbra ZCS OS Command Injection via SMTP