Zimbra Security Breach: No Password Required for Hackers
No Password Needed as Hackers Break Into Zimbra Servers Cyber attackers are leveraging a critical security flaw in Zimbra Collaboration Suite (ZCS) to infiltrate servers, deploy web shells and reverse shells, establish persistent access, and attempt to extract sensitive authentication data.
How Are Attackers Exploiting the Vulnerability?
The breach targets CVE-2026-73570, a high-severity unauthenticated operating system command-injection vulnerability with a CVSS score of 8.9. This flaw allows remote code execution under specific conditions when SNMP notifications are enabled and the optional “zimbra-snmp” package is installed. Attackers exploit the vulnerability by sending malicious SMTP requests, bypassing user interaction requirements. Zimbra addressed the issue in July 2026 with version 10.1.20. Despite the patch, ongoing attacks persist against unpatched systems. Security researchers identified affected organizations across multiple regions and industries, though not all compromised servers exhibited every stage of the attack. The attackers’ identities remain undisclosed. Exploitation activity was first detected in August, prompting the U.S. cybersecurity agency to include the vulnerability in its Known Exploited Vulnerabilities catalog. A remediation deadline of August 24, 2026, was set for federal agencies. Telemetry indicates attack activity occurred between July 20 and August 13.
How Do Attackers Sustain Access?
Between July 28 and August 7, two scanning tools were used to test the Zimbra command-injection path. These tools verified exploitability before deploying additional payloads. Attackers then executed commands under the “zimbra” service account to install multiple JSP web shells across Jetty and mailboxd application directories. Redundant web shells were deployed to ensure continued access even if one file was detected and removed. Attackers utilized “wget” and “curl” to download supplementary tools. They also employed “zmprov” to map the Zimbra environment, identifying mailbox and mail-transfer nodes. By accessing Zimbra’s SSH identity, they facilitated lateral movement within the server cluster. A privilege-escalation tactic involved modifying “/etc/pam.d/sudo” to grant the “zimbra” account unrestricted, passwordless sudo access. Additionally, a systemd service named “zimlog.service” was created to maintain persistence across system reboots.
What Authentication Secrets Are Being Targeted?
The primary goal of the attack is to extract Zimbra’s centralized authentication secrets. Instead of focusing on individual mailbox passwords, attackers used “zmlocalconfig -s” to retrieve server-level credentials. These secrets enabled authenticated LDAP queries to access high-value attributes such as “zimbraPreAuthKey,” “zimbraAuthTokenKey,” and “zimbraTwoFactorAuthSecret.” Attackers also leveraged Zimbra’s existing SSH identity to move between trusted servers and transfer web shells and scripts. Encrypted reverse shells were deployed to connect compromised systems to attacker-controlled infrastructure, allowing command execution, payload retrieval, and data collection.
What Data Is Being Attempted for Exfiltration?
In one campaign, attackers deployed the Zimclient2 remote-access tool via a Go-based payload called Zimdown2. This tool provides interactive shell access, bidirectional file operations, and SOCKS5 proxy capabilities. Other persistence methods included systemd services, OpenRC, cron jobs, SSH authorized keys, and local account creation. A Zimbra-specific payload was used to extract service-account credentials from “localconfig.xml.” These credentials were used to establish MySQL and LDAP connections, targeting data from tables like “mailbox,” “mailbox_metadata,” “mobile_devices,” and “out_of_office.” Additional files containing configuration, certificates, credentials, LDAP secrets, and mail rules were also collected and compressed for potential exfiltration. On one compromised server, recent mailbox backups were archived in “/opt/zimbra/final.tar.gz,” with an attempt to transfer the data using cloud-storage tools. However, no evidence confirms the transfer was completed.
What Immediate Actions Should Zimbra Administrators Take?
Organizations are urged to update Zimbra to version 10.1.20 or a later secure release immediately. If patching is not feasible, administrators should remove the “zimbra-snmp” package, disable SNMP notifications, and restrict SNMP and SMTP access to trusted hosts. Authentication secrets must be rotated, and servers should be thoroughly scanned for hidden web shells, persistence mechanisms, and other indicators of compromise.
The420 Takeaway
Applying the security update is essential, but organizations operating vulnerable Zimbra servers should not assume patching alone resolves prior compromises. Administrators must investigate for web shells and persistence mechanisms, review suspicious activity, and rotate credentials that may have been exposed.
About Author
English