Zimbra Flaw CVE-2026-73570 Exploited in the Wild, With at Least 274 Compromised Instances Counted by Shadowserver

Attackers are exploiting CVE-2026-73570, an unauthenticated command injection flaw in Zimbra Collaboration Suite, to run shell commands on mail servers with one crafted SMTP request (the protocol that moves email between servers), which is to say an email. CERT Polska confirmed active exploitation in Alert 145/2026 on Aug. 17, 2026, 28 days after Zimbra released a fix, and published detection guidance.

The Shadowserver Foundation counted at least 274 compromised Zimbra instances as of Aug. 24, 2026, per BetaNews. That is about 2.3% of more than 12,100 exposed servers, with exposure concentrated in Asia (4,492) and Europe (4,382). Shadowserver’s data does not distinguish patched servers or honeypots, so treat the figure as a rough gauge.

How one email becomes a foothold

The flaw lets a remote attacker run commands as the zimbra user without logging in. A server becomes exposed only when three conditions line up: the add-on zimbra-snmp package is present, the snmp_notify setting turns on SNMP alerts, and the swatchdog monitoring service is running. Swatchdog is reportedly on by default.

Those prerequisites are why CVSS rates attack complexity high, and the score is 8.9, which is high severity. Some outlets call the flaw critical, but the scored rating is lower than that label implies. The commands do not run as root, but the zimbra account still reaches Zimbra files, mail services, configuration and Jetty directories.

What Microsoft saw after the scanning

Microsoft reported that between July 28 and Aug. 7, 2026, two scanning tools probed for the injection path to confirm command execution without delivering payloads. According to Microsoft, real exploitation followed, and victims span several regions and industries.

Microsoft’s list of what intruders did next is long. It observed JSP web shells (scripts that give a remote operator a backdoor), shells calling back to attacker machines, privilege escalation, tooling to keep access, and code run from memory. It also saw mailbox and credential collection, with the haul bundled into archives and moved out.

Per Microsoft, attackers pulled Zimbra service secrets with zmlocalconfig and ran LDAP queries for attributes such as zimbraPreAuthKey and zimbraTwoFactorAuthSecret. They used the Zimbra SSH identity to move between cluster nodes, added passwordless sudo for the zimbra account and installed a systemd service named zimlog.service.

In one case, an actor staged mailbox backup content in an archive and tried to send it to Azure Blob storage with AzCopy. Microsoft said it could not confirm the transfer completed.

What operators should verify now

Zimbra released ZCS 10.1.20 on July 20, 2026; every earlier version is affected. CISA added the flaw to its Known Exploited Vulnerabilities catalog on Aug. 21 with a federal remediation deadline of Aug. 24.

To check exposure, operators can look for the zimbra-snmp package, confirm the version with zmcontrol -v, check snmp_notify in zmlocalconfig, and read swatchdog status in zmcontrol status.

To hunt for compromise, CERT Polska points administrators first to the Zimbra system log, where service status entries that keep flipping between stopped and running are a warning sign. It also says to review anything the zimbra user created over the past month in the Jetty web application folders under the Zimbra install and in the temporary directory.

Patching does not remove an attacker who is already present. For suspected compromise, sources recommend preserving logs, isolating the host, rotating credentials and starting incident response. Microsoft also advised rotating Zimbra authentication secrets.

Where patching must wait, the listed mitigations are disabling SNMP notifications or uninstalling zimbra-snmp, and restricting SNMP and SMTP access to trusted hosts.

Why it matters: the gap between patch and alarm

Microsoft’s account makes the stakes plain: intruders went after mailbox contents, credentials and the secrets behind Zimbra’s two-factor setup, which is the material that lets them keep coming back. The fix existed July 20, and CERT Polska’s confirmation of exploitation arrived 28 days later. For operators, that gap is the whole story, because a patch applied late protects against the next attacker, not the last one.

The vendor’s own timeline is murky, because the sources disagree. BetaNews reports that Zimbra first disclosed the flaw on June 26, 2026, with a temporary mitigation. The Hacker News gives Aug. 13, 2026 as the date of public disclosure.

Ars Technica reports that Synacor did not disclose it for more than three weeks after the July 20 patch.

That matters beyond bookkeeping. A patch with no loud advisory behind it gives defenders little reason to treat a point release as urgent, and scanning began within eight days of the fix, by Microsoft’s dates. No one has attributed the current campaign.

Watch for updated Shadowserver counts, any attribution from Microsoft or CERT Polska, and a plain account from Zimbra and Synacor of when customers were first told.