Critical Zimbra CVE-2026-73570: Attackers Hack Mail Servers with a Single Email

Zimbra Collaboration Suite is a popular enterprise email platform used by universities, government bodies, providers, and businesses worldwide, including in Ukraine. In late September 2026, the Microsoft Security Research team published a detailed breakdown of a campaign in which attackers actively exploit a critical vulnerability — CVE-2026-73570. Its key feature: the attack needs neither credentials nor any user interaction — it's enough to send the server a single specially crafted email.

According to the Shadowserver Foundation, at least 274 compromised Zimbra installations have been recorded on the internet, with over 8,200 servers still unpatched. The vulnerability has already been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, which means confirmed active in-the-wild exploitation. Let's break down how the attack works, who's at risk, and what administrators should do.

What this vulnerability is

CVE-2026-73570 is an unauthenticated OS command injection in Zimbra's SNMP notification mechanism. The CVSS 3.1 score is 8.9 (High): the attack runs over the network, without authentication, with low exploitation complexity and high impact on confidentiality, integrity, and availability.

An important nuance: the vulnerability doesn't fire in every installation, but only when two conditions are met at once:

1. the optional zimbra-snmp package is installed;
2. SNMP notifications are enabled.

This is a non-standard configuration used for infrastructure monitoring. In practice, however, it's far more common than one might expect — which is exactly why exploitation reached this scale. The vulnerability is closed in Zimbra 10.1.20.

Why Zimbra is a constant target

This is far from the first serious Zimbra vulnerability, and it's no accident that this platform is attacked again and again. A self-hosted mail server is a hub of an organization's most valuable data: business correspondence, employee accounts, and password-reset tokens for other services. Hacking email often means access to everything else.

Just recently the platform suffered several high-profile attacks. In late 2025, the zero-click-class vulnerability CVE-2025-66376 (stored XSS in the classic web interface) was fixed, exploited by state-sponsored cyber-espionage groups. The general picture is typical: administrators who keep mail "on their own hardware" often postpone updates — and such deferred patches become ready entry points for attackers.

This story repeats because optional modules like zimbra-snmp are installed "just in case" for monitoring, then forgotten. As a result, a seemingly inactive feature turns into an open door.

How the attack works (technical breakdown)

The exploitation chain looks like this. The attacker sends a specially crafted SMTP request containing shell metacharacters to an internet-facing Zimbra server. Due to insufficient input sanitization, this dangerous content reaches the SNMP notification handler.

When a service's state changes on the server and health monitoring fires, the swatchdog process substitutes the attacker-controlled value into the snmptrap shell call. As a result, commands execute as the zimbra service account — no password, no login, and no action from the user.

In other words, the very monitoring tool that was supposed to report problems instead runs the attacker's code. This is a classic example of how a secondary function (SNMP notifications) becomes an entry point into a system that has been running for years without raising suspicion.

Who's at risk and the campaign's scale

At risk is any organization running an internet-facing Zimbra server older than 10.1.20, with zimbra-snmp installed and notifications enabled. Zimbra is often chosen by educational institutions, government bodies, media, and mid-sized businesses — those who want "their own email" instead of cloud services.

The Shadowserver Foundation, which scans the internet, recorded growth in compromised installations from about 155 (August 20) to at least 274 (August 22), and this level held without noticeable decline. The number of still-unpatched, potentially vulnerable servers was estimated at over 8,200.

On August 21, 2026, CISA added the vulnerability to the KEV catalog with a remediation deadline of August 24 for US federal agencies. This confirms we're dealing not with a theoretical threat but with real, ongoing attacks on mail infrastructure. Poland's CERT Polska was the first to flag the campaign. At the time of Microsoft's publication, the specific group behind the attacks had not been officially attributed.

What attackers do after the breach

Having gained command execution, the attackers move from automated payload delivery to "manual" work on the server. Microsoft researchers recorded the following arsenal:

• Web shells. Attackers deployed JSP web shells in several application paths at once — Jetty and mailboxd — for redundancy. In some cases they temporarily opened write access to a public directory, placed the shell, and restored permissions, so a basic permission check noticed nothing.
• Privilege escalation. By modifying /etc/pam.d/sudo, the zimbra account was granted unlimited passwordless sudo (NOPASSWD: ALL).
• Persistence. They created a systemd unit named zimlog.service (outwardly resembling a legitimate one), cron jobs, and executed code in memory via memfd_create.
• Lateral movement. They used the existing Zimbra SSH key at /opt/zimbra/.ssh/zimbra_identity and rsync to spread tools to other cluster nodes.
• Secret theft. Instead of brute-forcing individual mailboxes, attackers took centralized secrets via zmlocalconfig -s: zimbraPreAuthKey, zimbraAuthTokenKey, zimbraTwoFactorAuthSecret. This allowed authenticated mail reading and bypassing two-factor authentication.
• Persistent remote access. In at least one campaign, a loader was used that installs the Go binary Zimclient2 — a remote-access agent with an interactive shell, two-way file operations, and a SOCKS5 proxy (WebSocket, TLS, and "raw" TCP support).

Collected data (mail, account and session materials) was packed into an archive and exfiltrated to external infrastructure. So the consequence of the breach is not just loss of server access but a potential leak of corporate correspondence.

Timeline: patch, reconnaissance, disclosure

The timeline of this story is telling:

• July 20, 2026 — Zimbra releases a fix in version 10.1.20.
• July 28 – August 7 — even before public disclosure, Microsoft records two separate scanning tools that "probe" the injection point and confirm command execution via out-of-band calls.
• August 13 — the vulnerability is publicly disclosed.
• August 21 — CISA adds CVE-2026-73570 to KEV.

This pattern — reconnaissance in the "window" between patch release and disclosure — is another reminder: updates must be installed immediately, without waiting for media coverage.

How to protect yourself

The main and non-negotiable recommendation is to update all Zimbra installations to version 10.1.20 or newer. If the update must be postponed, Microsoft advises temporarily reducing the attack surface:

1. Remove the optional zimbra-snmp package.
2. Disable SNMP notifications.
3. Restrict SNMP and SMTP access to trusted hosts only (firewall).

Also be sure to rotate Zimbra's authentication secrets — first of all zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret, since they may have been compromised before the update. Separately verify the server is current on another recent Zimbra vulnerability (CVE-2025-66376), closed in 10.1.13/10.0.18 — administrators often patch one hole and forget the other.

If mail credentials may have been affected, users should check whether their addresses and passwords appear in known leaks — this can be done via the free check on cyberpeople.tech.

Beyond the point patch, it's worth reviewing the mail-infrastructure architecture on the defense-in-depth principle. First, the mail server shouldn't be directly internet-facing if avoidable: a sensible approach is placing it behind a mail-filtering proxy or gateway. Second, network access to management services (SSH, admin panel, SNMP port) should be restricted to the internal network or VPN. Third, it's useful to regularly review the list of installed packages and disable what isn't actually used — this shrinks the future attack surface.

How to check if a server is already compromised

A patch closes the hole but doesn't remove what attackers may have left: web shells, sudoers entries, or systemd units. Any server that was internet-facing and ran below 10.1.20 should be considered potentially compromised and checked against this checklist:

• Review /var/log/zimbra.log for suspicious restarts of Zimbra services.
• Search for unexpected JSP files in application directories (Jetty webapps, mailboxd), in /tmp, and generated *_jsp.java or compiled servlets.
• Check /etc/sudoers and included files for a NOPASSWD entry for zimbra.
• Check /etc/pam.d/sudo for third-party hooks (pam_exec).
• Review systemd units for unknown services, especially names resembling Zimbra or "logging" (example — zimlog.service).

Remember: finding and removing one shell isn't enough — there are usually several, duplicated across cluster nodes.

What this means for ordinary users

Even if you don't administer a mail server, this vulnerability affects you too. If your employer, university, or mail provider runs Zimbra, a server breach means attackers could have gained access to others' — including your — correspondence and credentials. And since the attack requires no action from the user, no amount of caution protects against it: the solution lies entirely on the administrator's side.

What you can do: enable two-factor authentication on your mail account (it makes stolen secrets harder to use), watch for suspicious account sign-in notifications, and use unique passwords for work email so a compromised account doesn't drag other services down with it. This is basic hygiene that works even when the infrastructure around you turns out to be vulnerable.

Conclusion

CVE-2026-73570 is another reminder that an "unneeded" optional component can become the weakest link. A mail server holding corporate correspondence and credentials shouldn't be internet-facing without an urgent need, and every extra module (like zimbra-snmp) is additional attack surface.

For administrators, the algorithm is simple: update to 10.1.20+, remove or isolate SNMP, rotate authentication secrets, and check for web shells and persistence mechanisms. Because the main thing in such an attack isn't the breach itself but what remains in the system after the hole is patched.