Attackers Exploit Zimbra CVE-2026-73570 to Plant Web Shells & Steal Credentials

Threat actors have been exploiting a recently patched vulnerability in Zimbra Collaboration Suite (ZCS) to deploy web shells and harvest sensitive authentication secrets, researchers have found. The flaw—tracked as CVE-2026-73570 and assigned a CVSS score of 8.9—allows unauthenticated command injection on servers that have SNMP notifications enabled and the optional zimbra-snmp package installed. The attack enables remote code execution without user interaction. This vulnerability was fixed in Zimbra version 10.1.20, released in July 2026.

How the Attack Chain Works

Attackers trigger the flaw by sending a crafted SMTP request to exposed Zimbra servers. Once exploited, multiple malicious actions were observed: deploying JSP web shells and reverse shells; escalating privileges; installing remote access agents; and using memory-backed execution methods. The “zimbra” service account is abused to run these operations, including downloading and executing payloads via tools like wget or curl, setting up persistence via cron, systemd services, or memory aliasing (memfd_create).

In some cases, write permissions for public directories are temporarily altered to place web shells before permissions are restored, which helps evade basic detection. Threat actors have also modified configuration files to grant the “zimbra” account passwordless sudo access and created systemd services (for example, “zimlog.service”) to ensure persistence across boots.

Data Access, Movement & Exfiltration

The attackers went after centralized service credentials and authentication secrets—not individual mailbox passwords. Using Zimbra’s internal tools, they accessed secrets such as zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret. They also leveraged existing SSH identities on the server to move laterally within clusters.

Database tables affected include mailbox, out_of_office, mobile_devices, metadata, and all tables in the zimbra.* namespace. Artifacts like localconfig.xml, certificates, configuration files, and LDAP secrets are harvested, zipped, and staged for exfiltration. In one incident, a recent mailbox backup was compressed into /opt/zimbra/final.tar.gz and an Azure Blob SAS URL was used along with AzCopy to attempt transfer—though it’s unclear if that transfer completed successfully.

Timeline, Impact & Mitigations

Although the fix became available with the July 2026 patch, the exploitation appears to have taken place between July 20 (when version 10.1.20 was released) and August 13 (when the flaw was disclosed publicly). During that window, various probing and follow-through payload delivery events were detected across multiple industries and regions. Not every host suffered the full chain of abuse, though many saw web shell deployment or credential harvesting.

Poland’s CERT Polska first raised the alarm in August 2026. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) later added CVE-2026-73570 to its Known Exploited Vulnerabilities (KEV) list and urged federal agencies to apply the patch by August 24, 2026. Administrators have been advised to check Zimbra logs (e.g., /var/log/zimbra.log) for odd service restarts, look for new files in “webapps” or temporary directories, and search for persistence via cron, systemd, SSH keys, or shell init files.

If patching is not immediately feasible, recommended defenses include uninstalling the zimbra-snmp package, disabling SNMP notifications, and limiting SNMP and SMTP access to trusted hosts. Rotating Zimbra secrets and thoroughly scanning for hidden web shells or unauthorized configuration changes are also crucial.

This vulnerability is a vivid example of how a single component—here SNMP support—can expose an otherwise robust system when misconfigured. It underscores the vital importance of applying patches quickly after a fix is released. Going forward, organizations should consider more rigorous internal testing of optional modules, tighter network segmentation, and better monitoring of service-account permissions. Failure to do so doesn’t just risk mailbox leaks—it risks full environment compromise.