The active exploitation of CVE-2026-73570 in Zimbra Collaboration Suite is more serious than a conventional web-server compromise because attackers are using the vulnerability not only to execute commands and deploy web shells, but also to harvest the authentication material that underpins the entire Zimbra environment. Microsoft says the flaw is an unauthenticated operating-system command injection vulnerability affecting Zimbra installations prior to version 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. A specially crafted SMTP request can inject attacker-controlled input into Zimbra’s SNMP notification processing and execute operating-system commands as the zimbra service account without requiring authentication or user interaction. Zimbra released version 10.1.20 on July 20, 2026, while the vulnerability was publicly disclosed on August 13. Microsoft observed probing and exploitation activity during the interval between the patch becoming available and public disclosure.

That timing is important because it means defenders cannot treat this as a vulnerability that became dangerous only after a CVE and technical details appeared. Microsoft observed reconnaissance against the vulnerable execution path from late July, including out-of-band callbacks through DNS, HTTP, ICMP and public interaction services. Attackers used commands such as curl, wget, ping, nslookup and id to determine whether command injection succeeded before committing to heavier exploitation. This pattern shows deliberate validation of targets rather than indiscriminate payload deployment: first prove code execution, then decide whether the server is worth deeper compromise.

Once exploitation succeeded, attackers used the Zimbra service account to establish multiple access mechanisms. Microsoft observed JSP web shells written into Jetty and mailbox application directories, reverse shells, downloaded shell scripts, cron and systemd persistence, and memory-backed execution using memfd_create. In several environments, actors deployed more than one web shell across different mailbox nodes so that loss of one implant would not remove access to the entire Zimbra deployment. Some attackers temporarily changed directory permissions to make web locations writable, deployed the shell, and then restored the original permissions, reducing the chance that a simple permissions check would reveal what had happened.

The attack chain can therefore be summarized as: crafted SMTP request → SNMP notification command injection → execution as Zimbra service account → web shell or reverse shell → environment discovery → credential and authentication-secret collection → persistent access → mailbox staging and attempted exfiltration. The significant point is that exploitation begins through ordinary SMTP exposure. The victim does not need to click a link, open a message, or authenticate to the server. If the vulnerable SNMP configuration is present, the mail server itself becomes the execution target.

The attackers then mapped the Zimbra environment using legitimate administrative utilities such as zmprov, identifying mailbox servers, MTA nodes and other components. That illustrates why post-compromise activity can blend so easily with legitimate administration. The same tools an administrator uses to understand a Zimbra cluster are useful to an attacker trying to determine where sensitive data and authentication services reside. Once a threat actor owns the application account, the distinction between administration and intrusion increasingly becomes one of context rather than command names.

The most serious part of Microsoft’s findings is the systematic targeting of Zimbra’s centralized authentication secrets. Attackers used zmlocalconfig -s to retrieve credentials associated with LDAP, MySQL, Postfix, Amavis and replication services, then performed authenticated LDAP searches for attributes including zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret. These are substantially more valuable than ordinary mailbox passwords because they can affect authentication across the wider platform.

The zimbraAuthTokenKey is particularly sensitive because Zimbra uses it to sign user authentication tokens. If an attacker obtains this key material, they may be able to generate valid session tokens for arbitrary accounts without possessing those users’ passwords. Likewise, possession of a zimbraPreAuthKey can allow construction of pre-authenticated login URLs for accounts associated with the relevant domain. This means compromise of one exposed Zimbra server can potentially move beyond operating-system access into authentication-system compromise, where the attacker no longer needs to steal every mailbox password individually.

That distinction should change incident response. A defender who finds and deletes the web shell has not necessarily removed the attacker’s access. If signing keys, pre-authentication keys, LDAP credentials or other service secrets were harvested before containment, the attacker may still possess valid mechanisms for re-entering the environment or impersonating users. Microsoft therefore recommends rotation of Zimbra pre-authentication keys and review of authentication secrets after confirmed exploitation. In practical terms, CVE-2026-73570 should be treated as a credential-compromise incident as well as a server-compromise incident.

Microsoft also analyzed a Zimbra-specific Go implant designed specifically for credential and mailbox collection. The malware reads /opt/zimbra/conf/localconfig.xml, extracts service-account passwords such as MySQL, LDAP, Postfix, Amavis and replication credentials, constructs authenticated database and LDAP connections, and collects mailbox-related tables, metadata, mobile-device information, out-of-office settings, SSL certificates, private keys and authentication material. The payload stages the collected information into a timestamped directory under /tmp, compresses it, and prepares it for transfer to attacker-controlled infrastructure.

This is an important evolution beyond generic post-exploitation tooling. The attacker is not merely dropping a common credential dumper on Linux and hoping useful secrets appear. The malware understands Zimbra’s internal architecture, knows where configuration data is stored, understands which LDAP attributes matter, and automatically retrieves material that provides maximum value for continued access. That indicates attackers have moved from simply exploiting Zimbra to operationalizing the platform itself as a target.

Microsoft also observed attackers attempting to collect mailbox backups directly. In one compromised environment, the actor archived mailbox data into /opt/zimbra/final.tar.gz and downloaded Microsoft’s legitimate AzCopy utility to attempt transfer of that archive into attacker-controlled Azure Blob Storage. Available evidence did not confirm that this particular transfer completed successfully, so it would be inaccurate to state that Microsoft proved all staged mail data was exfiltrated. What is confirmed is that the actor collected the data, staged it locally, obtained the transfer utility and initiated the exfiltration workflow.

The use of AzCopy is another example of legitimate cloud tooling being incorporated into intrusion operations. Security teams cannot simply block every Microsoft binary or every connection to Azure storage without breaking ordinary business activity. Detection increasingly needs to ask whether the behavior makes sense for the system involved. A Zimbra mail server suddenly creating a full mail-store archive and invoking AzCopy against an unfamiliar Azure Blob SAS URL is suspicious even though every individual component is legitimate.

The same principle applies to command-and-control. Microsoft observed reverse shells using standard Linux utilities and openssl s_client, giving attackers an encrypted interactive command channel without deploying an obvious custom remote-access client. Other campaigns deployed purpose-built agents, including a Go-based chain involving agent2.sh, zimdown2 and zimclient2. Attackers also used WebSockets, raw TCP fallbacks and even public blockchain infrastructure as dead-drop mechanisms. This variety matters because there is no single malware family or C2 domain defenders can block and consider the problem solved.

The exploitation activity also included attempts to gain greater privileges and establish durable persistence. Microsoft detected activity involving symbolic links into PAM configuration paths, systemd services disguised using names resembling legitimate operating-system components, and malware masquerading as processes such as systemd-resolved, _chronyd and .kworker_sys. In some cases, memory-backed ELF payloads were executed directly through /proc/self/fd, reducing filesystem artifacts available to investigators.

This is why responders should avoid focusing exclusively on /opt/zimbra. Once an attacker has gained command execution on the mail server, the entire Linux host becomes part of the investigation. Unexpected systemd units, cron entries, PAM changes, new SSH material, temporary files, processes running under misleading names and unexplained outbound connections all deserve review. A clean Zimbra application directory does not prove a clean operating system.

The vulnerability’s configuration dependency is also important. CVE-2026-73570 requires the optional zimbra-snmp package to be installed and SNMP notifications to be enabled. Organizations that do not use that functionality are not exposed through this exact attack path. Defenders should therefore avoid treating every Zimbra server on the Internet as automatically exploitable. However, organizations running vulnerable configurations should assume heightened risk because exploitation is confirmed, CISA has added the flaw to its Known Exploited Vulnerabilities catalog, and compromise numbers have already reached the hundreds.

Shadowserver reported 267 compromised Zimbra instances as of August 24, down slightly from a peak of 274. Those figures represent systems Shadowserver could identify externally and should not be interpreted as a complete count of every compromised deployment. They nevertheless show that exploitation progressed beyond isolated targeting into meaningful real-world abuse.

Organizations should therefore update immediately to Zimbra 10.1.20 or later. Where patching cannot occur immediately, Microsoft recommends uninstalling the optional zimbra-snmp package or disabling SNMP notifications and restricting SMTP and SNMP access to trusted systems where operationally feasible. These are compensating controls, not substitutes for eventually applying the vendor fix.

For already exposed environments, the response needs to go substantially further than patching. Administrators should inspect /var/log/zimbra.log for unusual service restarts and command activity, examine /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, /tmp/ and related application directories for recently created JSP files or scripts, review systemd and cron persistence, hunt for reverse shells and unexpected processes, validate authentication activity, and search for archives or staged mailbox data. CERT Polska specifically recommended examining Zimbra application and temporary directories after observing active exploitation in August.

Credential rotation is equally important. If compromise is confirmed, organizations should assume Zimbra service credentials, LDAP credentials, pre-authentication keys, authentication-token signing material and other secrets readable by the Zimbra service account may have been collected. Rotating only the administrator password is inadequate when the attacker may have obtained cryptographic material capable of impersonating other users.

Mailbox users should also be considered in the breach assessment because attackers accessed and staged mailbox data. Even where logs do not prove complete exfiltration, organizations may need to determine which messages, attachments and backup repositories were reachable during the compromise period. Email systems routinely contain contracts, password-reset links, internal conversations, invoices, credentials, VPN instructions, customer records and years of sensitive business correspondence. Compromise of the mail infrastructure can therefore become an intelligence breach affecting far more than the server itself.

The broader cybersecurity lesson from CVE-2026-73570 is that Internet-facing mail servers combine three assets attackers value enormously: externally reachable code, identity infrastructure and concentrated sensitive data. An authentication bypass or command-injection flaw in such a system does not merely expose one Linux machine. It potentially gives the attacker the communications archive and authentication machinery of an entire organization.

The incident also demonstrates why defenders should separate the concepts of patching and recovery. Patching version 10.1.20 closes the original SNMP command-injection path. It does not remove web shells deployed yesterday, invalidate authentication keys copied last week, rotate LDAP credentials, delete remote-access agents, undo PAM changes or prove mailbox archives were not stolen.

The appropriate response sequence is therefore:

identify vulnerable Zimbra systems → patch or disable the vulnerable SNMP functionality → preserve forensic evidence → search for web shells and reverse shells → inspect persistence and privilege escalation → rotate Zimbra and directory-service secrets → invalidate authentication material → investigate mailbox access and staged archives → validate every node in clustered deployments

That final point matters because Microsoft observed attackers deploying redundant web shells across peer mailbox nodes. Cleaning one server while leaving another compromised simply gives the attacker a slightly inconvenient route back into the environment.

CVE-2026-73570 is therefore not merely another remote-code-execution bug in a mail server. The real danger lies in what comes next. Once attackers obtain execution as the Zimbra account, the platform itself provides a roadmap to mailbox data, service passwords, LDAP credentials and the cryptographic secrets used to establish trust across user sessions.

The first exploit gives them command execution.

The Zimbra authentication secrets can give them something considerably more valuable:

the ability to make future access look legitimate.

Threat actors have weaponized a now-patched security flaw in Zimbra Collaboration Suite (ZCS) to deploy web shells and access mailbox data, according to findings from the Microsoft Security Research team. The attack exploits CVE-2026-73570 (CVSS score: 8.9), an unauthenticated operating system command injection flaw that can lead to remote code execution when Simple Network Management Protocol

Source: Attackers Exploit Zimbra Flaw to Deploy Web Shells and Harvest Authentication Secrets via The Hacker News — published 30 Sep 2026.