Microsoft Threat Intelligence observed exploitation of CVE-2026-73570 in the SNMP notification path within Zimbra Collaboration Suite. The vulnerability allows unauthenticated remote system command execution without user interaction when the optional zimbra-snmp package is installed and SNMP notifications are enabled on an Internet-exposed Zimbra server.
According to Microsoft, exploitation begins with a specially crafted SMTP message, in which an attacker-controlled value can reach SNMP notification processing and then be inserted into a shell invocation associated with service-status monitoring. As a result, the attacker can execute commands with the privileges of the zimbra service account.
Exploitation Began Before Public Disclosure
Zimbra issued a fix in version 10.1.20 on July 20, 2026, while the vulnerability was publicly disclosed on August 13. Between July 28 and August 7, Microsoft observed out-of-band scanning and testing tools checking for command execution through the same path, before the vulnerability was publicly disclosed.
The tests used HTTP requests, DNS and ICMP queries, and commands such as curl, wget, ping, nslookup, and id to demonstrate command execution and external access to the server, without always needing to download a full payload.
From Command Execution to Server Takeover
After initial access, the attackers planted JSP-format backdoors in Zimbra application paths, created reverse shell sessions, and performed background operations. Microsoft also observed the use of cron, systemd, and memfd_create to maintain execution or run a payload from memory.
In one attack chain, components permitted to use sudo and a path associated with PAM were exploited to elevate the privileges of the zimbra account to root. The attackers also installed a systemd service named zimlog.service, a name that mimics a legitimate Zimbra component, to run the payload at system startup.
The activity did not stop at the first server. The SSH identity present in Zimbra and the rsync program were used to transfer files and backdoors to other nodes within the mail cluster, expanding the scope of access and reducing reliance on a single point of compromise.
Targeting Authentication and Email Data
The attackers collected values from local Zimbra settings, including credentials for LDAP, MySQL, Postfix, Amavis, and replication services. They also targeted keys such as zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret.
Microsoft’s analysis indicates that some tools attempted to read mail databases, device data, and out-of-office settings, in addition to certificates, private keys, and Postfix configuration files. In one incident, recent backups of mailboxes were collected into an archive, after which AzCopy was used in an attempt to transfer them to Azure Blob storage. The available evidence does not confirm that the transfer was completed.
What Should Operators Do?
The primary recommendation is to upgrade all Zimbra servers to version 10.1.20 or later. If immediate patching is not possible, Microsoft recommends removing the optional zimbra-snmp package, disabling SNMP notifications, and restricting access to SNMP and SMTP to trusted hosts only.
Alerts involving reverse shells on Internet-facing mail servers should also be treated as high-priority incidents, and teams should not limit their searches to known malware names; some of the most serious findings involved the use of an ordinary interactive shell without a specific malware family. Response actions include rotating Zimbra secrets and authentication keys, inspecting systemd services and PAM and sudo configurations, and searching all mail-cluster nodes for unexpected JSP files and generated servlet artifacts.
This investigation shows that the practical risk is not limited to executing a single command. A single vulnerability in an exposed mail server can become a launch point for collecting secrets, planting persistent access mechanisms, moving within the cluster, and attempting to extract email data. Conversely, indicators such as creating an archive or running a cloud-transfer tool alone do not prove that data theft succeeded; linking process, file, and network logs is required to determine what actually occurred.