A mail server compromised through CVE-2026-73570 can become a route into the rest of a Zimbra cluster. In a September 30 investigation, Microsoft describes intruders using the mail-triggered SNMP command-injection flaw to plant JSP web shells, gain root access, collect shared authentication keys and move to peer mailbox nodes. The immediate question for teams running internet-facing Zimbra is therefore wider than whether the exposed node has been patched: who or what could still authenticate across the cluster?
The flaw affects Zimbra Collaboration installations before 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled, according to the NVD record. Microsoft observed affected organizations in multiple regions and industries, but describes a composite of separate compromises: “no single host necessarily exhibited every stage.” Investigate post-entry artifacts on each affected host.
Mail input reached service monitoring
A crafted SMTP request supplies untrusted data to Zimbra’s SNMP notification processing. When a service-state change invokes health monitoring, swatchdog carries that data into a snmptrap shell invocation. The resulting commands run as the zimbra service account. This is an unauthenticated mail-input path; an intruder needs an internet-reachable server with the optional package and notifications turned on, rather than a mailbox login or a clicked attachment.
Microsoft saw out-of-band execution probes between July 28 and August 7, after Zimbra’s July 20 fix and before the August 13 public disclosure. The researchers also saw later automated delivery and interactive work on compromised hosts. The generated swatchdog script and its descendant shell/process lineage offer a stronger starting point than an IP blocklist: inspect unexpected shell children of swatchdog and snmptrap, together with callback and file events on the same host. A Microsoft Defender tactical detector recognized every confirmed exploitation event in the investigated set while running in evaluation mode; that measurement describes Microsoft’s cases, not a guarantee for every deployment.
Zimbra’s advisory says it “Fixed a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled.” Its July 20 release notes identify 10.1.20 as the fixed release. Check the installed build on each exposed MTA or mailbox node, including nodes expected to update automatically.
Peer mailbox nodes inherited access
The initial zimbra account gave an attacker a way to inspect the deployment. In Microsoft’s cases, intruders used zmprov to enumerate mailbox and MTA nodes, then checked for the existing Zimbra SSH identity at /opt/zimbra/.ssh/zimbra_identity. They used that trusted identity to connect to peer nodes and moved staged material and JSP shells with rsync. A clean-looking first server says little about its peers if that identity has already carried access across the cluster.
On individual hosts, Microsoft found JSP shells in Jetty and mailboxd application paths, sometimes with extra copies on peer mailbox nodes. Some operators temporarily made a public directory writable, deployed a shell, and restored permissions. Inspect live Zimbra application directories and servlet work directories for unexpected .jsp files, generated *_jsp.java or compiled servlet files, and recent write or ownership events. Correlate web requests with those files and with peer-to-peer SSH/rsync activity; a present-day permission check alone can miss the brief writable interval.
Root persistence survived cleanup
In one observed escalation, attackers abused the writable mailbox-manager log path and Zimbra’s privileged helpers to change the effective ownership of /etc/pam.d/sudo. They installed a temporary pam_exec hook and ultimately left the zimbra account with passwordless root privileges in sudoers. Microsoft’s process evidence points to that mailbox-manager/PAM route on the investigated server, even though the attacker had other fallback paths. Look for /etc/sudoers.d/81_metric, changes to /etc/pam.d/sudo, unusual zmmailboxdmgr and zmstat-fd activity, and subsequent root operations by the service account.
The attacker also enabled zimlog.service from /etc/systemd/system/ as a boot-time access path and changed its timestamps to resemble older units. Other observed tooling used cron, startup files, SSH authorized keys and memory-backed execution; these are separate paths across the investigations. Compare unit files, owners, enablement and service creation events against known-good state, not only file modification times. Microsoft observed a plain interactive shell used for full-mail-store staging as well as malware-backed access. A negative malware scan cannot clear that activity.
Shared keys raised the stakes
The intruders queried zmlocalconfig -s for LDAP, MySQL, Postfix and other service credentials, and used authenticated LDAP queries to collect zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret. The preauthentication key can support login URLs for accounts; token-signing material can support session tokens. Investigate use of those keys across the Zimbra deployment and rotate exposed authentication material.
One Zimbra-specific implant read /opt/zimbra/conf/localconfig.xml and prepared exports of mailbox tables including mailbox, mailbox_metadata, mobile_devices and out_of_office. In another sequence, an operator archived the mail store at /opt/zimbra/final.tar.gz and invoked AzCopy toward an Azure Blob destination. Microsoft describes that cloud transfer as an attempt; treat archive and transfer-tool events as evidence to investigate, then use destination-side records to establish what actually left. A separate remote-access agent named zimclient2 could provide interactive shell, file operations and SOCKS5 proxying after installation.
For focused pivots, Microsoft’s reported attacker infrastructure includes transzimbra[.]linkpc[.]net, psk1zim[.]abrdns[.]com, tls[.]psk1zim[.]abrdns[.]com, 117[.]107[.]25[.]243:7071 and 45[.]32[.]30[.]235:8081. Its SHA-256 values for agent2.sh and zimdown2 are 6ab7de2509038edf580aef6229c1c3db17f4da8f2d7d940818faf617d1938244 and bf28f38122bf20d5fac969cc414daa6a890cdea872d389ca93d2092b6b7773cf. Use those values with host process, file and network lineage: the investigation describes several campaigns and shared public callback services, so one network match warrants triage rather than automatic attribution.
Verify the cluster after patching
Upgrade Zimbra Collaboration on exposed nodes to 10.1.20 or later. Where patching must wait, Microsoft advises uninstalling zimbra-snmp, disabling SNMP notifications and restricting SNMP and SMTP access to trusted hosts. Verify both the running version and the notification/package state on every relevant node; changing an access rule alone does not replace the vendor fix.
For a host with matching shell lineage or post-entry artifacts, preserve process, file, web and SSH logs; contain the node and examine its trusted mailbox peers. Review live JSP paths, /etc/systemd/system/zimlog.service, sudoers, /etc/pam.d/sudo, zmlocalconfig -s and LDAP secret-query activity. Rotate every domain zimbraPreAuthKey and review other exposed Zimbra authentication and service secrets using the vendor’s recovery procedure. Microsoft notes that Defender XDR advanced hunting retains 30 days of raw events: use archived telemetry for July and August activity before treating a recent quiet window as reassuring.
A useful recovery test is to compare each node’s installed release, SNMP-notification state, webroot files, systemd units, sudoers content and cluster SSH events with known-good records, and to confirm the affected preauthentication keys have been replaced. Patching stops this entry path; the host and identity checks address access an intruder may have established before the upgrade.