CVE-2026-73570: Exploited Zimbra Command Injection Requires Patch and Persistence Hunt

According to Microsoft, CVE-2026-73570 is an unauthenticated OS command injection vulnerability in the Zimbra Collaboration Suite SNMP notification path. Exploitation can be triggered by a specially crafted email against internet-facing Zimbra servers when the optional zimbra-snmp package is installed and SNMP notifications are enabled, without requiring authentication or user interaction. In plain terms, an attacker sends a malicious message and the server runs the attacker's commands.

Zimbra isn't a Microsoft product, but plenty of mixed shops run it next to Windows endpoints, Entra ID and Defender. Microsoft's guidance also leans on Defender for Endpoint on Linux and Defender XDR hunting, so this lands on many Windows administrators' desks too.

What the bug does​

The weak spot is Zimbra's own health monitoring. Microsoft says a crafted SMTP request containing shell metacharacters can reach the SNMP notification code. When a service-state change triggers health monitoring, swatchdog incorporates the attacker-controlled value into a snmptrap shell invocation, enabling command execution. The monitoring tool meant to report trouble ends up running the attacker's input as part of a shell command.

Tenable's CVE entry, which matches the official description, lists the affected scope as Zimbra Collaboration (ZCS) before 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. Any commands run as the Zimbra user.

How serious is it? Windows Report calls it "critical," but the published score is a notch lower. The Hacker News lists it as CVE-2026-73570 (CVSS score: 8.9), and Hong Kong's HKCERT rated it High Risk. That difference shouldn't change your priorities. The flaw needs no login, is reachable over email, and is being exploited now.

Section summary:

• Affected: ZCS versions before 10.1.20 that have zimbra-snmp installed and SNMP notifications enabled
• Attack vector: a crafted SMTP message, with no login and no user interaction
• Result: operating system commands run as the zimbra service account
• Fix: ZCS 10.1.20 or later

The timeline​

The dates explain why this one hurt. Microsoft states that Zimbra version 10.1.20, released July 20, 2026, contains the relevant remediation. The CVE was publicly disclosed on August 13, 2026. Microsoft telemetry identified activity targeting the same injection path during the interval between those events.

Microsoft's report puts the first probing between July 28 and August 7, from two separate out-of-band scanning tools. So attackers were testing the flaw while most administrators still saw 10.1.20 as a routine release. One plausible explanation is that attackers compared the patched and unpatched code to find the bug, but Microsoft doesn't say how they learned of it.

The public response came quickly after that:

According to The Hacker News, active exploitation was first highlighted by the Polish Computer Emergency Response Team (CERT Polska) in August 2026. Dark Reading reported that on Aug. 21, CISA added CVE-2026-73570 to its KEV catalog and gave federal civilian executive branch agencies until the end of Aug. 24 to mitigate the flaw.

The reporting doesn't fully agree:

• Disclosure date: Dark Reading says Zimbra disclosed CVE-2026-73570 on June 26. That conflicts with Microsoft's August 13 date. Zimbra's own advisory, which we haven't reviewed, would settle it.
• Default settings: Dark Reading also says SNMP notifications are a configuration turned on by default in vulnerable versions. Microsoft and the CVE description stress that zimbra-snmp is an optional package. Don't rely on either claim. Check your own servers for the package and the notification setting.

What attackers did after getting in​

Microsoft's report combines activity seen across several confirmed compromises. It notes that no single server necessarily went through every stage, so read the list below as what attackers can do, not what happened on every exposed box.

More than one webshell. Attackers wrote JSP webshells into Jetty and mailboxd application directories and copied them to peer mailbox nodes. Cyberpress noted these shells provided HTTP-based command execution and were sometimes copied to other mailbox nodes in the same cluster. Microsoft also saw attackers briefly open write access on a public directory, drop a shell, then put the permissions back, so a quick permissions check might miss it.

Root through Zimbra's own tools. Microsoft documented a chain that abused Zimbra's sudo-authorized helpers. Attackers replaced the mailbox manager's writable log file with a symlink to /etc/pam.d/sudo. That gave the zimbra account ownership of the PAM file. They then added a pam_exec hook and triggered it through the zmstat-fd helper. The result was a NOPASSWD: ALL sudoers entry for zimbra. They then restored the original PAM file and kept the sudoers entry.

Hidden startup persistence. A separate method installed a systemd unit named zimlog.service in /etc/systemd/system/. The name sounds like part of Zimbra, but the unit sits outside Zimbra's directories. Its timestamps were altered to match services such as sshd.service, and it was set to start at boot.

Stealing the keys, not just passwords. This is where Windows Report's warning about "authentication keys and tokens" comes from. Attackers ran zmlocalconfig -s to get service credentials for LDAP, MySQL, Postfix and other components. They then used LDAP queries to pull zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret. Microsoft explains that the token key lets someone generate session tokens for any account without that account's password, and the pre-auth key can build pre-authenticated login URLs for any user. Changing user passwords won't revoke that kind of access.
Spreading through the cluster. Attackers reused Zimbra's existing SSH identity at /opt/zimbra/.ssh/zimbra_identity to reach trusted peer nodes, and used rsync to copy payloads and webshells between them.

Remote-access tools and attempted data theft. In one campaign, a Go-based agent called zimclient2 provided an interactive shell, file transfer and SOCKS5 proxying. A Zimbra-specific Go payload read /opt/zimbra/conf/localconfig.xml and exported mailbox-related database tables. On one server, attackers packed mailbox-backup data into /opt/zimbra/final.tar.gz and ran Microsoft's own AzCopy tool to send it to Azure Blob storage. Microsoft says the evidence doesn't confirm that the transfer completed.

Section summary: These attackers planned to stay. They used several webshells, kept root access, added startup persistence, stole signing keys and moved across nodes. One cleanup step won't remove all of that.

Defender's detections, with caveats​

Microsoft says Defender caught malicious activity on every attack path it observed. A detector built specifically for the SNMP injection pattern flagged every confirmed exploitation event while running in evaluation mode. Defender Antivirus separately detected and quarantined payloads it names as Chopper, GodzillaWebShell, CoinMiner, Looptik, SuspGoLang and Dirtelti. Windows Report spelled that last one "Ditelti", but Microsoft's report uses "Dirtelti." Behavioral alerts also fired on suspicious permission changes, background execution, dropped-and-launched files, anonymous memfd_create execution and reverse shells.

Two caveats apply. This is Microsoft's own telemetry describing Microsoft's own products, which is normal for vendor threat reports. It also only covers servers where Defender for Endpoint on Linux was deployed and enabled. Microsoft itself warns against relying only on named-malware detections. Some of the most damaging steps, including staging the full mail store for theft, used no malware at all, just an interactive shell.

What Zimbra admins should do now​

Based on Microsoft's guidance and earlier CERT advice:

1. Patch. Upgrade every ZCS instance to 10.1.20 or later, including the server you'd forgotten about.
2. If you can't patch yet, remove the attack surface. Microsoft recommends uninstalling the optional zimbra-snmp package, disabling SNMP notifications, and limiting SNMP and SMTP access to trusted hosts. GBHackers adds that configuration changes should not replace upgrading to a fixed Zimbra release.
3. Assume earlier compromise until you've ruled it out. The fix closes the hole. It doesn't remove webshells, sudoers entries or systemd units planted before you patched. Any server that was internet-facing and below 10.1.20 needs a review.
4. Check the logs CERT Polska flagged. CERT Polska told admins to review the "/var/log/zimbra.log" file for suspicious Zimbra service restarts, and look for files created in temporary and Zimbra "webapps" directories.
5. Look for webshells on every mailbox node. Microsoft advises searching application and servlet-work directories for unexpected JSP files, generated *_jsp.java or compiled servlet files, and recent permission changes on public directories. Finding and removing one shell doesn't mean you've found them all.
6. Check persistence and privilege changes. Look at /etc/sudoers and its included files for a NOPASSWD entry for zimbra. Check /etc/pam.d/sudo for pam_exec hooks. Look for unfamiliar systemd units, especially ones with Zimbra-like or logging-style names.
7. Rotate secrets. Microsoft specifically recommends rotating all domain zimbraPreAuthKey values and Zimbra authentication secrets in general. Reviewing the service credentials exposed through localconfig.xml is also sensible.
8. Treat reverse-shell alerts as incidents. Microsoft says a confirmed reverse shell from an internet-facing mail server means attacker access even if nothing was quarantined.
9. Restrict the service account. Where it's practical, Microsoft suggests confining mail-server service accounts with namespace, seccomp or AppArmor controls. That limits the damage from the next command-injection bug.

Defender XDR hunting​

Microsoft published behavior-based advanced hunting queries for Linux Zimbra servers that use the public Device* tables. They cover:

• the swatchdog-to-snmptrap injection pattern
• suspicious JSP writes
• native shells launched from Java
• persistence and privilege-escalation artifacts
• DNS callbacks
• archive staging and AzCopy use

The pattern to look for is a legitimate snmptrap call followed by shell metacharacters and a wget or curl command, ending in a # that comments out the rest of the real arguments.

Microsoft notes that advanced hunting keeps only 30 days of raw data, which no longer reaches back to the July–August activity. For older events, you'll need Microsoft Sentinel or archived logs.

The bigger picture​

Mail servers make good targets because they hold sensitive messages, store authentication secrets and have to accept traffic from the internet. GBHackers put it this way: Zimbra servers often house sensitive communications, authentication material, and internal organizational data, making them attractive targets for espionage, ransomware, and financially motivated threat actors. Microsoft says victims were in more than one region and industry, so this doesn't look like a campaign aimed at one sector.

The timeline matters more than the specific bug. Dark Reading framed the case as an example of how the window for organizations to address newly disclosed vulnerabilities is shrinking. Here, the window started before the CVE was even public, so a "patch next month" policy for mail servers was too slow. Our view, based on general industry practice rather than Microsoft's report, is that an internet-facing mail server release that mentions security fixes should be treated as urgent even if no CVE has been published yet.

The bottom line for Zimbra admins:

• Get to 10.1.20 or later.
• Remove zimbra-snmp if you don't use it.
• Rotate pre-auth and token keys.
• Check every node for a second or third webshell.

Patching closes the hole, but it won't remove anything attackers left behind.