Zimbra Flaw Under Attack: Web Shells, Stolen Authentication Secrets and What to Do

Organisations that run their own mail on Zimbra have a serious warning to act on. According to findings shared by the Microsoft Security Research team, attackers are using CVE-2026-73570 in Zimbra Collaboration Suite to plant web shells and reach mailbox data and authentication secrets. The flaw was patched in July 2026, but servers that were never updated remain targets.

What is the flaw?

CVE-2026-73570 is an unauthenticated operating-system command injection rated 8.9 on the CVSS scale. Two conditions must be met: the optional zimbra-snmp component is installed and SNMP notifications are enabled.

What makes it dangerous is the trigger. The attacker does not need to log in or trick a user; sending a specially crafted SMTP request — in other words, an email — to an exposed Zimbra server is enough.

Timeline

• 20 July 2026: Zimbra released version 10.1.20, which fixes the flaw.
• 28 July – 7 August 2026: Two separate scanning tools probed servers only to confirm that commands could be executed, without dropping a payload.
• August 2026: Poland's incident response team, CERT Polska, reported active exploitation.
• 13 August 2026: The flaw was publicly disclosed. The attacks Microsoft documented fall between the patch release and this date.
• Late August 2026: The US agency CISA added the flaw to its catalogue of known exploited vulnerabilities and required federal agencies to patch by 24 August.

It is not known who is behind the attacks. Affected organisations span more than one region and industry.

What attackers do once inside

After initial access, commands run as the zimbra service account. The observed steps can be summarised as follows:

• Persistence: Several JSP web shells are placed in Jetty and mailboxd application paths so that removing one leaves the others. In some cases directory permissions were opened temporarily and then restored, which hides the change from a basic permission check. Cron, systemd (for example a service named zimlog.service) and memory-only payloads are also used.
• Privilege escalation: /etc/pam.d/sudo is modified to give the service account unrestricted, passwordless sudo.
• Secret harvesting: Rather than individual user passwords, the attackers go after Zimbra's central service and authentication secrets, then use them in LDAP queries to pull values such as the pre-auth key, the auth token key and two-factor secrets.
• Lateral movement: Zimbra's own SSH identity is used to reach other nodes in the cluster, with web shells copied over by rsync.
• Data collection: A tool written in Go reads database credentials from the configuration file and exports mailbox tables; it also gathers credential, certificate, LDAP secret and mail-rule files into a compressed archive.

On one server the attacker archived mailbox backups and attempted to send them out with a cloud storage tool. The available evidence does not confirm that the transfer completed.

How to tell if your server was affected

• You are at risk if your Zimbra version is older than 10.1.20 and the zimbra-snmp component is installed.
• Review /var/log/zimbra.log for Zimbra service restarts you cannot explain.
• Look for newly created, unfamiliar files (especially .jsp) in temporary directories and Zimbra's webapps directories.
• Check for changes to /etc/pam.d/sudo, unfamiliar systemd services, cron jobs, new local accounts and SSH authorised keys.

What to do

1. Update now. Move to Zimbra 10.1.20 or later.
2. If you cannot update, uninstall the zimbra-snmp component, disable SNMP notifications and restrict SNMP and SMTP access to hosts you trust.
3. Rotate secrets. If the server was exposed before patching, change Zimbra's authentication secrets; a patch does not invalidate a secret that was already stolen.
4. Scan for web shells. The attackers build in redundancy, so deleting a single file is not enough.

Do not forget your SSL certificate

This part is our own recommendation. Because the tooling used in these attacks collects certificate files, the private key of the SSL certificate on a mail server you suspect was compromised can no longer be treated as secret. Once the server is clean, generate a new private key and CSR, have the certificate reissued and have the old one revoked. If the same certificate (a wildcard, for example) is installed on other servers, replace it there too. Certificates bought from DATASSL can be reissued free of charge for the life of the certificate.

Source: Microsoft Security Research findings, as reported by The Hacker News on 30 September 2026 (original report).