Zimbra CVE-2026-73570: SNMP flaw exploited before disclosure

A vulnerability in Zimbra Collaboration Suite (ZCS), CVE-2026-73570, was exploited before it was made public. It lets an unauthenticated attacker run operating system commands by sending crafted content to the mail server’s SMTP service. Microsoft Threat Intelligence has described the intrusions that followed: web shells, privilege escalation, credential harvesting and mailbox archives staged for removal. The fix has been available since version 10.1.20.

What happened

Zimbra released version 10.1.20 on 20 July, but the vulnerability was only disclosed on 13 August. In between, from 28 July to 7 August, Microsoft observed two different scanning tools probing the Internet for the very component later used in the attacks.

The attackers first checked that the exploit worked: they made vulnerable servers contact infrastructure under their control, using HTTP and DNS requests, ICMP pings and other out-of-band checks. This confirmed command execution without yet compromising the server. Then they moved on to installing payloads.

According to Microsoft, the activity hit organisations in several regions and industries, with both automated stages and hands-on-keyboard operations on compromised servers. The attacks have not been attributed to a specific group.

Shadowserver, as reported by Ars Technica, counted 274 compromised ZCS instances. Zimbra servers visible on the Internet numbered about 19,000 in the week after the patch and about 10,000 at the end of September.

Technical details

• CVE: CVE-2026-73570, unauthenticated command injection. CERTuy (Uruguay) gives a CVSS score of 8.9, while Ars Technica and The Register describe it as critical.
• Affected versions: Zimbra Collaboration Suite earlier than 10.1.20.
• Required conditions: the optional zimbra-snmp package must be installed and SNMP notifications enabled. CERTuy is more precise: the snmp_notify parameter enabled and the swatchdog service running.
• Vector: network, via SMTP. The request content reaches SNMP notification processing without being sanitised, and the injected shell commands run with the privileges of the zimbra service account.
• Initial privileges: those of the zimbra user, not root. That is still enough to read the platform’s configuration, data and mailboxes.

The observed attack chain

Microsoft, in the account reported by The Register and Ars Technica, describes these stages:

1. Reconnaissance and validation: scans and out-of-band callbacks to confirm command execution.
2. Access and persistence: JSP web shells, reverse shells, persistent remote-access tools and in-memory execution. In some cases, permissions on public directories were changed to drop web shells and then restored, to make the intrusion less visible.
3. Escalation: on at least one machine the attackers gained root and set themselves up to run commands with the highest privileges without a password.
4. Lateral movement: they looked for other mail servers and used existing SSH trust relationships between Zimbra systems.
5. Collection: Zimbra credentials and authentication secrets. One tool was purpose-built to extract service account credentials and mailbox information from Zimbra’s databases.
6. Attempted exfiltration: recent mailbox backups were compressed into an archive and sent towards Azure Blob Storage with AzCopy. Microsoft could not confirm whether the transfer succeeded.

CERTuy adds that, according to the reports it analysed, cryptomining software also appeared on some compromised servers. It warns against stopping the investigation at the miner, as other persistence mechanisms may be present.

MITRE ATT&CK (our mapping of the behaviours described): T1595 Active Scanning, T1190 Exploit Public-Facing Application, T1059.004 Unix Shell, T1505.003 Web Shell, T1222.002 Linux File and Directory Permissions Modification, T1021.004 SSH, T1114.001 Local Email Collection, T1560 Archive Collected Data, T1567.002 Exfiltration to Cloud Storage, T1496 Resource Hijacking.

Impact for European and Italian companies

A mail server holds communications, attachments and credentials. Whoever controls it can read correspondence, steal identities and prepare further attacks from the inside. Updating closes the flaw but does not remove web shells, SSH keys or other persistence installed earlier. Every server that stayed exposed and vulnerable after 28 July should therefore be checked.

For NIS2 entities, a mail server compromise can be a significant incident to be notified to the national CSIRT, which in Italy is CSIRT Italia at the ACN. If the mailboxes contain personal data, as they almost always do, a GDPR breach notification to the data protection authority must also be assessed. In healthcare, where emails may contain health data, access to mailboxes and their backups weighs even more.

What to do now

1. Inventory: find every Zimbra installation, including those run by providers, and check its version.
2. Update to Zimbra Collaboration 10.1.20 or later. Unsupported versions should be migrated to a supported branch.
3. If you cannot update right away: disable SNMP notifications (snmp_notify) or remove the zimbra-snmp package if you do not need them. Consider taking servers you can neither update nor mitigate off the Internet. These are temporary measures.
4. Check the configuration: presence of zimbra-snmp, value of snmp_notify, swatchdog status, and how long the server was exposed in a vulnerable state.
5. Look for signs of exploitation, as CERTuy advises:
   • in /var/log/zimbra.log, lines Service status change: … changed from stopped to running (or from running to stopped) containing commands, special characters or shell substitutions;
   • files created or modified by the zimbra user in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, /tmp/, /var/tmp/ and /dev/shm/;
   • zimbra user processes with abnormal CPU usage, use of curl or wget, processes started from temporary folders;
   • new or modified scheduled tasks, services, startup scripts and SSH keys, including sudo permissions;
   • unusual outbound connections, to mining pools or cloud storage services such as Azure Blob;
   • unrecognised access to mailboxes and admin accounts.
6. If you find indicators: preserve logs and evidence before deleting files or stopping processes, isolate the server and handle it as an incident. Rotate service account and user credentials, and check the servers reachable over SSH from the compromised one. The absence of suspicious log lines is not enough to rule out exploitation, especially if logs have been rotated.

How ARXDOME helps

ARX Expose shows which services your company exposes on the Internet, which products are recognised on them and which have known vulnerabilities: an unpatched, reachable Zimbra server shows up among the findings. On Linux servers, the ARX Sentry agent collects logs, processes, ports and file changes in chosen folders, such as Zimbra’s web application folders. ARX Shield lists open vulnerabilities by machine and by package and lets you isolate a suspicious machine from the network. With ARX Trace, analysts can run collections and searches across several servers.

Last updated: 9 October 2026