MikhbarMIKHBAR
Cybersecurity

Zimbra Flaw Exploited In-The-Wild Before Public Notice

A high-severity command injection vulnerability in the Zimbra Collaboration Suite was actively targeted by malicious actors following the release of patches but prior to public disclosure.

Zimbra Flaw Exploited In-The-Wild Before Public Notice

Overview of the Zimbra Vulnerability

Hackers started exploiting a high-severity OS command injection vulnerability in the Zimbra Collaboration Suite shortly after patches were rolled out, according to a report published by [Microsoft says](https://www.microsoft.com/en-us/security/blog/2026/09/30/unauthenticated-command-injection-on-internet-facing-mail-servers-tracking-cve-2026-73570/). Tracked as CVE-2026-73570 with a CVSS score of 8.9, the flaw stems from improper sanitization of untrusted input during SNMP notification processing in ZCS versions prior to 10.1.20.

The vulnerability can be triggered if the zimbra-snmp package is installed and SNMP notifications are enabled. Under these specific conditions, an attacker can exploit the defect via specially crafted SMTP requests, allowing unauthenticated threat actors to achieve remote code execution with the privileges of the Zimbra user.

Patch Timeline and In-The-Wild Exploitation

Patches for CVE-2026-73570 were made available on July 20 in ZCS version 10.1.20, and the security flaw was subsequently disclosed to the public on August 13. However, malicious activity began prior to the public notification window [as exploited](https://www.securityweek.com/hackers-target-zimbra-servers-in-active-exploitation-campaign/). Poland’s CERT Polska flagged the defect as actively exploited and released indicators of compromise on August 17.

Between July 28 and August 7—after the fix became available but before public disclosure—Microsoft tracked two distinct out-of-band scanning tools probing the vulnerable injection point. This reconnaissance activity utilized execution paths later seen during actual exploitation, serving to validate command execution via lightweight probes without deploying payloads.

Attack Methodology and Post-Exploitation Activity

Following the reconnaissance phase, follow-up exploitation involved deploying JSP webshells to publicly accessible application directories. Threat actors executed content using wget or curl, launched background processes, and established interactive reverse shells to maintain unauthorized access.

Multiple JSP webshells were placed across Jetty and mailboxd application paths, along with duplicate copies on peer mailbox nodes. This configuration provided alternative access routes across diverse Zimbra setups, reducing reliance on a single webshell.

Privilege Escalation and Persistence Mechanisms

Once inside the environment, attackers mapped clusters, fingerprinted target systems, checked for the Zimbra SSH identity, and escalated their privileges to root using legitimate Zimbra tools. They also established a secondary persistence mechanism using a systemd service named zimlog.service.

The hackers targeted Zimbra centralized service and authentication secrets for credential exfiltration, leveraging login details for authenticated LDAP queries to extract high-value secrets. Furthermore, they used existing SSH identities to navigate to other nodes in the cluster and deployed a full remote-access agent offering interactive shell access, bidirectional file operations, and SOCKS5 proxying.

Recommended Mitigation Steps

Administrators and users of the Zimbra Collaboration Suite are advised to take immediate action to protect their networks. Recommended steps include updating instances to version 10.1.20 or later, uninstalling optional vulnerable packages, disabling vulnerable configurations, restricting SNMP and SMTP access, and comprehensively checking environments for signs of prior compromise.

Sources

  • SecurityWeekZimbra Vulnerability Exploited in the Wild Prior to Public Disclosure

Continue chronologically

Related entity coverage