Attackers are exploiting a now-patched vulnerability in Zimbra Collaboration Suite (ZCS) to deploy web shells and gain access to mailbox data, according to the Microsoft Security Research team.
The flaw, tracked as CVE-2026-73570 (CVSS score: 8.9), is an unauthenticated operating system command injection that can lead to remote code execution. The server is exposed when SNMP notifications are enabled and the optional zimbra-snmp package is installed. An attacker only needs to send a specially crafted SMTP request — in other words, an email — to an internet-facing Zimbra server. No authentication or user interaction is required. Zimbra fixed the issue in July 2026 with version 10.1.20.
According to Microsoft, successful exploitation was followed by the deployment of JSP web shells and reverse shells, privilege escalation, persistent remote-access tooling and in-memory execution. The attackers also read email, collected authentication and mailbox data, created archives and then attempted to move them off the server.
Microsoft saw affected organizations in more than one region and industry, although not every compromised host showed every stage of the attack chain. Who is behind the campaign remains unknown.
Timeline
Active exploitation of CVE-2026-73570 was first reported by the Polish Computer Emergency Response Team (CERT Polska) in August 2026. The agency advised administrators to review /var/log/zimbra.log for suspicious Zimbra service restarts and to look for new files in temporary directories and in Zimbra’s webapps directories.
Later that month, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) catalog and ordered federal agencies to apply the fix by August 24, 2026.
Microsoft’s telemetry places the activity in the window between July 20, 2026, when Zimbra 10.1.20 was released, and August 13, 2026, when the vulnerability was publicly disclosed — the attackers were already working the flaw while most administrators had no idea it existed.
Between July 28 and August 7, two separate scanning tools were probing the injection path out of band. They confirmed that command execution worked without delivering any follow-on payload, which is typical reconnaissance before a wider campaign.
What the attackers did after getting in
The initial foothold gave the attackers command execution as the zimbra service account. From there they deployed several JSP web shells across the Jetty and mailboxd application paths, so that removing one would not cut off access. They also downloaded and ran payloads directly with wget or curl and opened interactive reverse shells.
Other execution chains relied on cron, systemd or memfd_create to keep code running on a schedule or purely in memory. In some cases, the attackers temporarily made a public directory writable, dropped a web shell into it and then restored the original permissions — a basic permissions check would show nothing unusual.
Microsoft documented the following follow-up steps:
- Environment discovery. The zmprov utility was used to map the Zimbra deployment and identify mailbox and MTA nodes.
- Checking for the Zimbra SSH identity, most likely to prepare for moving between Zimbra hosts.
- Privilege escalation. The attackers modified /etc/pam.d/sudo to give the zimbra service account unrestricted sudo access with no password.
- Second persistence mechanism. A systemd service named zimlog.service was created to run at every boot.
- Going after central secrets. Instead of targeting individual mailbox passwords, the attackers ran zmlocalconfig -s on the server to pull Zimbra’s service and authentication secrets. The recovered credentials were then used for authenticated LDAP queries to retrieve high-value attributes such as zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret.
- Lateral movement. Zimbra’s own SSH identity at /opt/zimbra/.ssh/zimbra_identity was used to reach other trusted nodes in the cluster, and rsync was used to copy web shells and helper scripts between them.
- Encrypted control channel. An OpenSSL-encrypted reverse shell to attacker infrastructure handled command execution, payload delivery and the transfer of command output.
Of all these steps, the theft of zimbraPreAuthKey and zimbraAuthTokenKey is the most serious. With those keys, an attacker can generate valid sessions for any account on the server without knowing a single password — resetting user passwords does nothing against that.
Zimdown2 and Zimclient2
In at least one campaign, the attackers used a lightweight shell downloader to fetch Zimdown2, a Go binary that installs a remote-access agent called Zimclient2. The agent provides an interactive shell, two-way file transfer and SOCKS5 proxying.
Zimclient2 supports WebSocket, TLS and raw TCP transports. That gives the operators resilient access and the ability to use a compromised Zimbra server as a pivot into the internal network. Microsoft found a long list of persistence mechanisms tied to this payload: systemd services, OpenRC, cron, shell startup files, SSH authorized keys and newly created local accounts.
Tooling built specifically for Zimbra
The attackers also deployed payloads written specifically for Zimbra. One of them, a Go executable, tries to pull the service-account credentials out of /opt/zimbra/conf/localconfig.xml. It then uses them to build MySQL and LDAP connection strings to Zimbra’s own database and exports the contents of the following tables:
- mailbox
- mailbox_metadata
- mobile_devices
- out_of_office
- all tables in the zimbra.* namespace
The implant also collects credentials, certificates, LDAP secrets, mail rules and configuration files. Everything it gathers is compressed into a ZIP archive and staged for transfer to a remote server.
On one compromised server, Microsoft says, the attackers packed recent mailbox backup content into /opt/zimbra/final.tar.gz. They then downloaded Microsoft’s AzCopy utility from its official short link (aka[.]ms/downloadazcopy-v10-linux) and pointed it at an Azure Blob Storage SAS URL they controlled: wsweb03[.]blob[.]core[.]windows[.]net/log/windows.log. Using legitimate cloud storage tooling helps the traffic blend in with normal activity. Microsoft notes that the available evidence does not confirm the transfer actually completed.
What to do now
Microsoft’s main recommendation is to install the update immediately. If patching is not possible right away:
- uninstall the zimbra-snmp package;
- disable SNMP notifications;
- restrict SNMP and SMTP access to trusted hosts only.
Patching alone is not enough if the server was reachable from the internet with SNMP enabled before July 20. The exploitation window opened before the fix was public, so any such server should be treated as potentially compromised. We recommend checking it for the following:
- Web shells. Look for JSP files in the Jetty and mailboxd webapps directories that do not belong to a stock installation. Remember that the attackers deliberately planted several copies, so finding one is not the end of the search.
- Persistence. Review systemd units (zimlog.service in particular), OpenRC scripts, crontabs for all users, shell startup files, ~/.ssh/authorized_keys and recently created local accounts.
- sudo configuration. Compare /etc/pam.d/sudo against a known-good copy and check what sudo rights the zimbra account actually has.
- Logs and temporary directories. Follow CERT Polska’s advice: look for unexplained service restarts in /var/log/zimbra.log and new files in /tmp and similar locations.
- Signs of data collection. Look for unexpected archives such as /opt/zimbra/final.tar.gz, the AzCopy binary, and outbound connections to Azure Blob Storage that your organization cannot account for.
- Secret rotation. If there is any sign of compromise, rotating user passwords is not sufficient. Regenerate the preauth keys, the auth token key, the LDAP and MySQL service passwords, and the two-factor authentication secrets, then replace the Zimbra SSH identity used between cluster nodes.
A mail server holds some of the most sensitive data an organization has, and it is exposed to the internet by design. That combination makes it a favorite target. If you run Zimbra or other self-hosted mail infrastructure and are not sure whether your server was touched during the exposure window, our emergency hacked website repair team can carry out a forensic review, remove web shells and hidden persistence, and harden the server configuration through our security hardening service. For ongoing oversight of self-hosted mail and application servers, that is exactly what our server management covers, and if you need to verify the fix holds under real attack conditions, our penetration testing can confirm it.