Attackers Were Probing a Zimbra Mail Server Flaw Eight Days After Its Patch, Microsoft Says

Microsoft says it saw attackers probing a flaw in the Zimbra Collaboration Suite mail server from July 28, eight days after Zimbra shipped the fix and 16 days before the flaw’s CVE record was published. In a report dated September 30, Microsoft Threat Intelligence describes what followed: crafted emails that led to web shells, root access, stolen service credentials and, on one server, an attempt to send mailbox backups to Azure storage.

The flaw is CVE-2026-73570, an unauthenticated command injection in Zimbra’s SNMP notification handling. Exploitation was already known: CISA added it to its Known Exploited Vulnerabilities catalog on August 21, and Help Net Security reported that the Shadowserver Foundation had counted at least 274 compromised servers by August 24. What Microsoft’s report adds is when the attacking began and what the intruders did once inside. SecurityWeek and The Register covered it on October 1. Microsoft saw affected organizations “in more than one region and industry” and, according to The Register, has not attributed the activity to a particular group.

The bug, and how the dates line up

According to the CVE record, a crafted SMTP request can make a Zimbra server running a version before 10.1.20 execute arbitrary operating system commands as the zimbra user, with no login and no user interaction, but only when the optional zimbra-snmp package is installed and SNMP notifications are enabled. The record rates it 8.9 (High) under CVSS 3.1 and classifies it as CWE-78, OS command injection. CERT Polska, whose notice is in Polish, adds that the instance must also be running the swatchdog service, which is on by default, with SNMP traps switched on through the snmp_notify parameter.

Microsoft calls August 13 the date of public disclosure. Zimbra’s own release post for 10.1.20, though, calls the update the permanent fix for a vulnerability “disclosed in our security advisory on 26th June 2026,” and Help Net Security reports that administrators could apply a temporary mitigation until the fix arrived. Zimbra’s public advisories page lists the SNMP fix only under 10.1.20, so we could not check the text of the June advisory. Whether the probing came before disclosure therefore depends on which date you count. It began after the permanent fix existed either way, which makes the eight-day figure the safer way to put it.

What Microsoft saw after the probes

Microsoft’s attack-chain diagram is a composite, and it cautions that “no single host necessarily exhibited every stage.” The activity ranged from automated payload delivery to hands-on-keyboard work on compromised mail servers. In outline:

• Probing (July 28 to August 7). Two out-of-band scanning tools sent lightweight probes that called back to unique subdomains on public interaction services, including oast[.]fun, oast[.]online, dnslog[.]pp[.]ua and requestrepo[.]com, to confirm that commands ran without delivering a payload. The HTTP requests carried a ZB73570 User-Agent.
• Initial access. A crafted SMTP request carrying shell metacharacters reaches Zimbra’s SNMP notification processing. When a service-state change triggers health monitoring, swatchdog places the attacker-controlled value into an snmptrap shell invocation. Attackers then wrote JSP web shells into publicly served directories, in some cases opening write access to a directory and restoring the permissions afterward, with extra copies on peer mailbox nodes.
• Root access. On one server the attacker abused sudo-authorized Zimbra helper programs and a writable log directory to make the sudo PAM configuration file editable by the zimbra account, added a hook that created a NOPASSWD: ALL sudoers entry for that account, then restored the original PAM file and kept the sudoers entry.
• Persistence. A systemd service named zimlog.service was installed in /etc/systemd/system/ with timestamps altered to match rsync.service and sshd.service. Other chains used cron, systemd or memfd_create for recurring or memory-backed execution, and in one campaign a Go installer called zimdown2 fetched a remote-access agent, zimclient2, that gave attackers an interactive shell, file transfer and SOCKS5 proxying.
• Credential theft. The actor ran zmlocalconfig -s to read service credentials for LDAP, MySQL, Postfix, Amavis and replication, then made authenticated LDAP queries for zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret. In one case a Go binary whose embedded module path was zimbra-exfil/client-dump read localconfig.xml and exported the full contents of the mailbox, mailbox_metadata, mobile_devices and out_of_office tables.
• Lateral movement. Attackers reused Zimbra’s own SSH identity at /opt/zimbra/.ssh/zimbra_identity, connecting non-interactively with host-key verification disabled, and used rsync to copy web shells and payload fragments to peer nodes.
• Exfiltration attempt. On one server the actor archived recent mailbox backups into /opt/zimbra/final.tar.gz, downloaded AzCopy and ran it against an operator-supplied Azure Blob SAS URL. Microsoft says “available evidence does not confirm that the transfer completed successfully.”

Why the stolen secrets matter more than passwords

Microsoft says the actor targeted Zimbra’s “centralized service and authentication secrets rather than individual mailbox passwords.” Of the LDAP attributes it lists, zimbraAuthTokenKey “is the key material Zimbra uses to sign user session tokens across the platform; access to this value enables session token generation for arbitrary accounts without requiring account credentials,” and the pre-authentication key “allows construction of pre-authenticated login URLs for any user account.” A community-written article on Zimbra’s own wiki says much the same about that key, warning that it “can be used to generate valid auth tokens for any user in the given domain!”

That is why Microsoft’s advice goes beyond patching. It says to rotate Zimbra authentication secrets, including “all domain zimbraPreAuthKey values,” and to review systemd units for unexpected ownership, enablement or timestamp changes, “including units that resemble Zimbra or operating-system logging components.” Patching alone would not take back secrets an attacker has already copied.

A hunting window that is closing

Microsoft flags a limit on looking back. Defender XDR advanced hunting, it says, “retains 30 days of raw event data, which no longer covers the pre-disclosure reconnaissance and early exploitation described here.” For older activity it advises searching the second-stage infrastructure listed in its appendix in Microsoft Sentinel or archived logs, and pivoting every recovered indicator across the entire device fleet rather than only the hosts that raised an alert.

The same arithmetic applies to the checks CERT Polska published on August 17. They look in /var/log/zimbra.log for entries of the form Service status change: <malicious payload> changed from stopped to running, and the same line ending in from running to stopped, and for files the zimbra user created in the previous 30 days under /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ and /tmp/. Run today, a 30-day lookback starts on September 1, which is after the July probing Microsoft saw. A widened search is the safer route, with one caveat: file timestamps can be altered, as Microsoft saw with zimlog.service, so treat them as leads rather than proof.

Microsoft’s other warning concerns detection built on malware names. “Several of the most consequential outcomes in this campaign, including full mail-store staging for an exfiltration attempt, involved no malware family at all, only a plain interactive shell,” it says, and it asks defenders to treat reverse-shell alerts on internet-facing mail servers as priority incidents.

What admins can do now

• Upgrade every Zimbra instance to version 10.1.20 or later, which Microsoft says remediates CVE-2026-73570.
• If patching must wait, uninstall the optional zimbra-snmp package, disable SNMP notifications, and restrict SNMP and SMTP access to trusted hosts, as Microsoft advises.
• Inspect application and servlet work directories on every mailbox node for unexpected JSP files, generated *_jsp.java files or compiled servlet artifacts. Microsoft’s warning: “Do not assume that removing one known JSP eliminates access.”
• Rotate Zimbra authentication secrets and domain pre-authentication keys, and review systemd units for lookalike names.
• Run CERT Polska’s log and file checks with a window that reaches back past September 1.

Why it matters

The timeline is the story. The fix shipped on July 20 and the first probing Microsoft saw came eight days later. The CVE record (August 13), CERT Polska’s warning (August 17) and CISA’s catalog entry (August 21) all came afterward. A team that waited for a CVE number or a catalog listing before scheduling the upgrade was already behind, although Zimbra’s July 20 release post did rate the release “Severity: High” and “Deployment Risk: Low” and say “We strongly recommend upgrading to this version,” without naming a CVE.

This is the reverse of the NetScaler zero-days Citrix confirmed were exploited before a patch existed. Here a fix was available and the gap was in applying it, closer to the Elementor Pro flaw that was exploited the same day it was patched. Mail servers also sit at the network edge, where, as with the Cisco Secure Email Gateway flaw, a single crafted email can be the way in.

CISA’s catalog now lists 19 Zimbra Collaboration Suite entries, five of them added this year by our count from its raw KEV JSON feed: January 22, February 17, March 18, April 20 and August 21. SecurityWeek noted in August that Zimbra exploitation has frequently been linked to Russian and Chinese state-sponsored hackers as well as opportunistic cybercriminals. Microsoft’s report does not name a group, and who is behind this activity remains unknown.

Three things to watch: whether Microsoft or other responders attribute the activity, an updated count of compromised servers (the figure Shadowserver reported on August 24 was at least 274), and whether Zimbra publishes the details of its June 26 advisory.