Key Summary
- Microsoft’s security research team analyzed that attackers exploiting the Zimbra vulnerability (CVE-2026-73570) planted JSP webshells across multiple paths in the mail servers of several organizations, and exfiltrated authentication secrets in bulk, including service account credentials, LDAP pre-authentication keys, authentication token keys, and 2FA secrets.
- This flaw leads to an RCE (Remote Code Execution) that can execute operating system commands without authentication on servers where SNMP notifications are enabled and the optional zimbra-snmp package is installed, and is classified as ‘High’ severity on the CVSS scale.
- The attack stages unfolded as follows: ①July 28 – August 7: pre-verification of command execution capability using two different scanners ②command execution with the Zimbra service account and multi-deployment of JSP webshells ③modification of sudo configuration to gain unrestricted administrator privileges ④registration of zimlog.service to maintain persistence after reboot ⑤lateral movement within the cluster using pre-existing SSH keys ⑥installation of Zimclient2 to obtain a SOCKS5 proxy and interactive shell ⑦exporting mailbox tables and attempts to exfiltrate to Azure Blob Storage.
Through a case where a single authentication bypass spread not to a single mailbox but to the entire server secrets store and the cluster, this article examines how plaintext storage of authentication secrets and an SNMP-dependent design expand the attack surface, and presents a three-pillar response procedure: patching, secret rotation, and residual webshell inspection.
Table of Contents
- Key Summary
- How the Zimbra Vulnerability CVE-2026-73570 Works
- 7-Stage Attack Timeline
- Four Key Compromise Indicators
- Tools and Exfiltration Attempts: Zimclient2 and AzCopy
- Comparison with Other Mail Solution Vulnerabilities
- Practical Application Points
- What to Do Right Now
- Security Advisory Timing and Responsible Agencies
- Frequently Asked Questions
- Source Reference
From July 28 to August 7, Microsoft’s security research team repeatedly detected the same pattern of compromise indicators in Zimbra Collaboration mail servers across multiple organizations. The target was not individual mailboxes but the servers themselves. Attackers who passed through the Zimbra vulnerability CVE-2026-73570 harvested service account credentials, LDAP pre-authentication keys, and 2FA secrets in a single sweep, and moved laterally to other nodes within the cluster.
How the Zimbra Vulnerability CVE-2026-73570 Works
This Zimbra vulnerability leads to an RCE that can execute operating system commands without authentication on Zimbra servers where SNMP notifications are enabled and the optional zimbra-snmp package is installed. The CVSS rating is ‘High’. A path that was blocked before the SNMP setting was turned on becomes a direct line to the operating system shell the moment that option is activated. What stands out to practitioners is that this flaw is not a ‘single line of bad code’ but a ‘combination created by operational options and packages’. In other words, a dangerous path can be opened simply by default installation habits.
7-Stage Attack Timeline
The flow organized by Microsoft consists of 7 major stages.
- July 28 – August 7: Pre-verification of command execution capability using two different scanners
- Command execution with Zimbra service account privileges, simultaneous deployment of JSP webshells across multiple paths
- Modification of sudo configuration to gain unrestricted administrator privileges
- Registration of zimlog.service to maintain persistence after reboot
- Lateral movement within the cluster using pre-existing SSH keys
- Installation of Zimclient2 to obtain a SOCKS5 proxy and interactive shell
- Exporting mailbox tables and attempts to exfiltrate to Azure Blob Storage
The key point of this attack via the Zimbra vulnerability is that it is not a simple intrusion but a ‘live off the land’ pattern, in which once inside, privileges and keys are gathered sequentially from within the system.
Four Key Compromise Indicators
The indicators worth paying attention to are the methods of privilege escalation and persistence. The sudo configuration change is an indicator that dismantled Zimbra’s operational account privilege model itself, and the zimlog.service registration is an indicator that created a new service-level auto-re-execution path. The fact that pre-existing SSH keys were reused to access other nodes within the cluster clearly demonstrates that patching a single machine is not enough to end the entire compromise.
Microsoft analyzed that after exfiltrating the service secrets and authentication secrets Zimbra had centralized, the attackers extracted related keys via LDAP lookups. Individual mailbox passwords were not directly targeted. In some cases, indicators were also detected in which write permissions to public directories were temporarily relaxed to plant webshells and then restored, bypassing basic permission checks.
Tools and Exfiltration Attempts: Zimclient2 and AzCopy
Zimclient2 provided both a SOCKS5 proxy and an interactive shell, giving attackers a foothold to move more aggressively within the internal network. They gathered keys by querying MySQL and LDAP directly, and there were also attempts to transfer mailbox backups to Azure Blob Storage via AzCopy. However, Microsoft stated that no evidence was confirmed as to whether the Azure Blob transfer was actually completed. The author believes it is premature to judge whether the exfiltration attempt was stopped or whether evidence simply was not left behind.
Comparison with Other Mail Solution Vulnerabilities
This Zimbra vulnerability is not an isolated, one-off incident. According to BleepingComputer, a zero-day attack on Fortinet FortiMail via CVE-2026-104286 (CVSS 9.8, combining path traversal and NULL byte) was also confirmed in the wild. Vulnerabilities are being continuously exposed in the mail and collaboration space.
| Item | Zimbra CVE-2026-73570 | FortiMail CVE-2026-104286 |
|---|---|---|
| Attack Surface | SNMP / zimbra-snmp option | Webmail management path |
| CVSS | High | 9.8 (Critical) |
| Exploitation Form | Authentication bypass RCE | Path traversal + NULL byte |
| In-the-Wild Disclosure | August, Polish CERT | Reported as zero-day |
| Main Risk | Bulk exfiltration of the server secrets store | Administrator privilege takeover and command execution |
Practical Application Points
- As confirmed in this Zimbra vulnerability case, the SNMP-dependent option alone becomes an attack path simply by being ‘enabled’. Disabling it by default must be cemented as an operational policy.
- Indicators of privilege escalation appear in sudo configuration changes. Integrity monitoring of /etc/sudoers and related files is required.
- zimlog.service, a clue to persistence, is an indicator of ‘custom service registration’. Non-standard systemd units should be audited periodically.
- Even if mail body passwords are not directly targeted, once LDAP keys and 2FA secrets are leaked, the possibility of secondary compromise persists.
What to Do Right Now
- Immediately update to Zimbra 10.1.20 or later, which includes the patch for the Zimbra vulnerability, and isolate any lower-version systems from the network.
- Remove the zimbra-snmp package, disable the SNMP notification option, and reboot.
- Restrict SNMP and SMTP access to trusted hosts and internal management ranges only, and re-review firewall rules.
- Rotate in full the LDAP pre-authentication keys, authentication token keys, and 2FA secrets held by Zimbra, and reissue user passwords together.
- Conduct a thorough inspection of /opt/zimbra, web roots, and temporary directories for JSP webshells and non-standard systemd units.
Security Advisory Timing and Responsible Agencies
Zimbra distributed a patch with the July 10.1.20 release, and Polish CERT first publicly disclosed in-the-wild exploitation in August. The U.S. CISA directed federal agencies to take action by August 24. Looking at the time gap between the attack exposure and patch distribution for this Zimbra vulnerability, the ability to immediately query the Zimbra version from an internal asset inventory is what determines response speed.
Frequently Asked Questions
What type of flaw is the Zimbra vulnerability CVE-2026-73570?
It is an RCE flaw that allows unauthenticated operating system command execution in environments where SNMP notifications are enabled and the zimbra-snmp package is installed. It is classified as ‘High’ severity on the CVSS scale.
Are individual mailbox user passwords also directly leaked?
In this campaign, individual mailbox passwords were not directly targeted. Instead, service account credentials, LDAP pre-authentication keys, authentication token keys, and 2FA secrets were exfiltrated in bulk, and additional related keys were extracted via LDAP lookups.
Is applying the patch alone enough to be safe?
No. Attackers can leave traces across the cluster through zimlog.service registration and SSH key reuse. After patching, authentication secret rotation, residual webshell inspection, and a full cluster audit must be performed together.
How is this different from FortiMail CVE-2026-104286?
The FortiMail case is a web path flaw (CVSS 9.8) combining path traversal and NULL byte, whereas this Zimbra vulnerability is an authentication bypass RCE dependent on the SNMP option. The attack surface and trigger are different, but they share the common pattern of vulnerabilities being continuously exposed in the mail and collaboration space.
Source Reference
This article was written after reviewing the following original source: Boan News — Targeted the server, not the mailbox… Zimbra vulnerability exploitation attack drains authentication secrets
Expert Commentary (AI)
Information Security Expert
An RCE opened by a combination of an optional package and an operational option exposes the structural vulnerability of the overall mail server secrets management architecture
The technically notable aspect of CVE-2026-73570 is not the code defect itself but the fact that operator choices, such as enabling the SNMP option and installing the zimbra-snmp package, create the attack surface. This is a pervasive problem in collaboration software where the assumption that ‘a default install is inherently safe’ does not hold, and it is evidence that threat modeling for the command handling paths of optional packages was insufficient. The fact that the attack collected service account credentials, LDAP keys, and 2FA seeds in bulk shows that Zimbra’s design of concentrating the secrets store in a near-plaintext form maximizes damage in the event of compromise. The success of lateral movement based on sudo configuration changes and SSH key reuse reveals the vulnerability of operational practices that delegate excessive local privileges to mail server accounts, and without full secret rotation and a full cluster audit after the patch is applied, re-compromise is virtually assured. A point of concern is that while CVSS classified the flaw as High, an unauthenticated RCE that leads to bulk theft of an organization’s entire authentication assets may cause the risk rating to underrepresent the actual damage potential.
Cloud and Email Infrastructure Operations Expert
The three-pillar response of patching, secret rotation, and residual webshell inspection is valid, but the cluster structure and sniffable credential storage issues still amount to post-incident response rather than root-cause elimination
The core of the infrastructure risk this campaign demonstrates is that compromise of a single node spreads across the entire cluster. Mail and collaboration servers are positioned in internal networks such that SSH keys and sudo configurations tend to be managed as cluster-common, and this case empirically demonstrated that this common trust model acts as a lateral movement channel for attackers. The response procedures of disabling zimbra-snmp, rotating all LDAP 2FA seeds and token keys, and auditing non-standard systemd units are operationally feasible, but the fact that the egress firewall failed to block AzCopy-style legitimate tool transfers despite the Azure Storage exfiltration attempt exposes a blind spot in outbound controls. In addition, the fact that mailbox tables could be exported in MySQL form locally means the storage structure itself is a layout vulnerable to bulk exfiltration, requiring the introduction of storage-layer encryption and table-level access control. From an organizational perspective, the fact that the ability to immediately query the Zimbra version inventory determines response speed reconfirms that asset management remains the most realistic defensive bottleneck.
Critical Analyst
The composition of bulk secret exfiltration, Azure exfiltration attempts, and pre-validation by scanners suggests the possibility of organized intelligence collection or supply chain preemption rather than mere criminal profit
However, looking beneath the surface, this campaign deviates from the economic crime pattern in several places. Individual mailbox passwords were not targeted, and only service secrets and LDAP keys were collected like an SUV, which reads more like the handiwork of a party that understands the internal authentication architecture itself rather than a typical criminal. The choice of Azure Blob Storage as the exfiltration channel is also interesting, in that the choice of a path that is easy to disguise as normal cloud traffic and slip past egress filters suggests a tactical sophistication that implies a background organization. What we should have paid attention to earlier is the patience of repeated scanning and staged deployment over the 10 days from July 28 to August 7. This is an APT-style operational pattern aimed at minimizing infection evidence while maintaining persistent access, and Microsoft’s statement that evidence of completion of the blob transfer was not confirmed should be read in practice as ‘we do not know whether it has already left’. Finally, we must ask ourselves — the time gap between Polish CERT’s first disclosure and the CISA federal agency deadline, and the fact that the attack start date of July 28 precedes the patch distribution date, who benefits from this timing structure?
Hidden Scenarios
- The fact that the initial attack discovery date (July 28) precedes the official patch release suggests that information about this flaw may have been circulated to specific parties from the zero-day stage, and email collaboration server secrets are more suited to nation-state intelligence purposes than criminal profit.
- The AzCopy + Azure Blob combination may be intermediary infrastructure disguised as a normal storage provider, and the statement of unconfirmed evidence of completion of the blob transfer makes it difficult to rule out the possibility that actual exfiltration succeeded but the evidence was already erased.
- The fact that multiple organizations were compromised in the same pattern consecutively over 10 days requires the premise that the common infrastructure vulnerability of multiple targets is known, so the possibility of information leakage somewhere in the supply chain or patch distribution channel cannot be excluded.
Leave a Reply