Zimbra Collaboration Suite: CVE-2026-73570 Unauthenticated SNMP Command Injection / RCE

CVE-2026-73570 is an unauthenticated OS command injection (CWE-78) in the SNMP notification path of Zimbra Collaboration Suite (ZCS), CVSS 3.1 8.9 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L). On servers where the optional zimbra-snmp package is installed and SNMP notifications are enabled (the swatchdog service that processes them runs by default once the package is present), a single crafted SMTP request, an email, reaches the service-state-to-snmptrap code path and executes arbitrary operating-system commands as the zimbra service account. No authentication and no user interaction are required.

Microsoft Threat Intelligence confirmed active in-the-wild exploitation that began before public disclosure: two distinct out-of-band scanning tools probed the injection path between July 28 and August 7, 2026, after the July 20 fix shipped but before the August 13 public disclosure. CERT Polska's August 17 advisory was the first public confirmation of an active campaign, CISA added the CVE to its Known Exploited Vulnerabilities catalog on August 21 with an August 24 federal remediation deadline, and Shadowserver tracked compromises climbing from roughly 155 internet-facing instances on August 20 to 270 or more by August 22–25, against a population of more than 12,000 reachable ZCS servers and over 8,200 still running vulnerable versions.

Post-exploitation activity converges on a narrow set of durable patterns regardless of which operator capitalizes on access: JSP web shells redundantly deployed into Jetty and mailboxd webroots across cluster nodes, a privilege-escalation chain that abuses legitimate Zimbra service helpers (zmmailboxdmgr, zmstat-fd) together with a writable log path and pam_exec to grant the zimbra account passwordless root sudo, a disguised systemd unit named zimlog.service for boot persistence, and systematic harvesting of Zimbra's own authentication secrets, zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret, rather than individual mailbox passwords. Microsoft observed more than one distinct post-exploitation toolset across different compromised environments, including a separate cryptomining operator, which is consistent with multiple actors opportunistically capitalizing on the same disclosed flaw rather than one coordinated campaign.

The highest-value defensive angle is behavioral rather than signature-based: hunt the swatchdog-to-shell execution boundary itself, the PAM/sudoers manipulation sequence, and the webroot-write-then-restore-permissions pattern. These survive infrastructure rotation and catch compromises that do not match any previously published hash or domain. Atomic indicators are available from one primary investigation (Microsoft) and are shipped here as detect-only hunting leads, not as blocking rules, pending independent corroboration.

Defender priority: patch every internet-facing Zimbra server to 10.1.20 or later now. If a server carrying zimbra-snmp with SNMP notifications enabled was reachable from the Internet at any point between July 20 (fix available) and your actual patch date, treat it as compromised until proven otherwise, not merely "now patched": rotate zimbraPreAuthKey and every Zimbra service-account credential, and hunt for the persistence mechanisms in Sections 7 to 9 before closing the ticket.

Decision log

• Every atomic indicator in this pack (IPs, domains, hashes) traces to exactly one original investigation, Microsoft's. Downstream outlets repeat the same values rather than independently corroborating them. Per pipeline policy, single-sourced indicators ship action=detect only, never action=prevent, regardless of how many outlets re-publish them.
• Attribution is explicitly UNKNOWN for this campaign per NVD, Gridinsoft, SecurityWeek, The Hacker News, and the Cloud Security Alliance note. No actor or campaign name is coined anywhere in this pack.
• The Cloud Security Alliance note's url slug references a separate, unrelated nation-state incident. That note explicitly states: "No security vendor, government agency, or research organization has published attribution linking a specific threat actor or nation to the CVE-2026-73570 exploitation wave." The joint CISA/NSA/FBI advisory on Russian-linked LAUNDRY BEAR / Void Blizzard activity against Zimbra concerns a different vulnerability, CVE-2025-66376 (a zero-click stored XSS, patched November 2025). That campaign's indicators, tooling (a tool the advisory calls "Ulej"), and attribution are intentionally excluded from this pack to avoid conflating two unrelated Zimbra incidents.
• Historical Zimbra targeting by Winter Vivern, APT29, and APT28 (cited by SecurityAffairs and SecurityWeek) is background context on the platform's general threat profile only. No source attributes the current SNMP command-injection campaign to any of these actors.

Hunt hypotheses (ordered by fidelity)

1. H1 (high): The swatchdog-to-snmptrap command injection boundary itself is visible as a shell process spawned from a Zimbra service-monitoring process ancestry, carrying SNMP MIB syntax plus shell metacharacters in its command line.
2. H2 (high): Web shell deployment leaves a process-level trail: webroot permission changes under the zimbra account followed by decode/write operations targeting Jetty or mailboxd webapps paths, then permission restoration.
3. H3 (high): Attacker tooling is retrieved and executed via curl/wget piped directly to a shell, or downloaded then chmod+executed, as a child of the Zimbra Java process tree.
4. H4 (high): Interactive reverse shells use a named pipe plus openssl s_client, or a background /bin/sh -i, spawned from Java/jspawnhelper ancestry.
5. H5 (high): Fileless / memory-backed execution via memfd_create and /proc/self/fd/ appears in process ancestry tied to the injection path.
6. H6 (high): Privilege escalation leaves a durable artifact trail: a symlink into /etc/pam.d/, a pam_exec hook, invocation of zmstat-fd outside normal monitoring cadence, and a new /etc/sudoers.d/ entry granting the zimbra account passwordless sudo.
7. H7 (high): A systemd unit resembling Zimbra logging or another core OS service, but installed from /tmp or owned by the zimbra account, appears outside the normal package-management install path.
8. H8 (medium-high): Cron persistence (@reboot, * * * * *) relaunches a staged binary from a world-writable or Zimbra-owned path.
9. H9 (high): Credential harvesting runs zmlocalconfig -s followed by an authenticated ldapsearch targeting zimbraPreAuthKey, zimbraAuthTokenKey, or zimbraTwoFactorAuthSecret outside a scheduled administrative task.
10. H10 (medium): Lateral movement uses Zimbra's own pre-existing SSH identity (/opt/zimbra/.ssh/zimbra_identity) with host-key checking disabled, paired with rsync transfers between mailbox nodes.
11. H11 (medium): Pre-exploitation validation and ongoing recon chain curl/wget/ping/nslookup/id in rapid succession from the zimbra account, often to out-of-band collaborator domains.
12. H12 (high): Collection stages a full mail-store archive (tar zcvf) under a disguised name in a public webroot or backup path, sometimes followed by azcopy invocation to cloud blob storage.

Attack chain

Every indicator below traces to a single primary investigation (Microsoft Security Blog, Sept 30 2026); downstream outlets repeat the identical values rather than independently corroborating them. Confidence is therefore capped at medium and action is capped at detect (alert/hunt), never prevent, per pipeline policy requiring two independent sources before a block action ships. Expiry assumes typical C2 infrastructure volatility.

Behavioral indicators (not atomic, confidence high: primary detection surface)

• Service-state string fed into a snmptrap invocation containing shell metacharacters (;, &, |, backticks, $(...))
• Systemd unit named zimlog.service (or any unit masquerading as Zimbra/OS logging: chronyd-helper.service, syslog_init.service) owned by the zimbra account
• A symlink placed at /etc/pam.d/sudo or a file under /etc/pam.d/ owned by zimbra
• A sudoers fragment under /etc/sudoers.d/ (observed as 81_metric) granting zimbra NOPASSWD:ALL
• Named pipe at /tmp/s feeding an interactive shell into openssl s_client
• Masquerade filenames: .kworker_sys, .lpe_core, _chronyd, a mail archive saved with a .ico extension

Non-CQL checks that work even without EDR coverage on a given node. Run these first on any Zimbra host that was ever reachable from the Internet with zimbra-snmp installed.

1. CERT Polska log signature (translated from advisory 145/2026)

grep -E "Service status change: .* changed from (stopped to running|running to stopped)" /var/log/zimbra.log

A legitimate service transition names the service; an injected payload appears in place of (or appended to) the service name. Treat any non-standard service-name token here as a confirmed exploitation attempt, not a false positive to tune away.

2. Web-shell / staged-file sweep (CERT Polska + Hive Security)

find /opt/zimbra/jetty/webapps      /opt/zimbra/jetty_base/webapps      /opt/zimbra/mailboxd/webapps      /tmp      -user zimbra -mtime -30 -ls

Record path, owner, timestamps, and hash of every result before deleting anything; do not clean up before evidence is preserved.

3. Version and exposure check (Falcon Internet Blog / Gridinsoft)

su - zimbra -c "zmcontrol -v"                         # expect 10.1.20 or later
rpm -qa | grep zimbra-snmp                             # RHEL/CentOS
dpkg -l | grep zimbra-snmp                              # Ubuntu/Debian
su - zimbra -c "zmswatchctl status"

4. PAM / sudoers integrity check

ls -la /etc/pam.d/sudo
stat /etc/pam.d/sudo
grep -r "pam_exec" /etc/pam.d/
ls -la /etc/sudoers.d/
grep -ril "zimbra" /etc/sudoers.d/ 2>/dev/null

A sudo PAM file not owned by root, a pam_exec line you did not add, or any /etc/sudoers.d/ fragment naming the zimbra account is a confirmed privilege-escalation indicator.

5. Systemd unit audit

systemctl list-unit-files --type=service | grep -Ev "^(UNIT|$)"
for u in $(systemctl list-unit-files --type=service --no-legend | awk '{print $1}'); do
  stat --format='%Y %U %n' "/etc/systemd/system/$u" 2>/dev/null
done | sort -n

Look for a unit file owned by zimbra, a unit whose modification time sits suspiciously close to unrelated core services (rsync.service, sshd.service, the timestomp pattern Microsoft observed), or any unit name that resembles Zimbra logging but was not installed by the Zimbra package manager.

6. LDAP secret-attribute access review

zmprov gaa | xargs -I{} echo {}   # cluster inventory baseline
grep -i "zimbraPreAuthKey\|zimbraAuthTokenKey\|zimbraTwoFactorAuthSecret" /opt/zimbra/log/ldap_audit.log 2>/dev/null

If LDAP audit logging is not enabled, enable it going forward; its absence is itself a coverage gap to note in Section 5.

Three queries are unambiguous and low-noise enough to promote from investigate-only hunts to Custom IOAs. Deploy each in audit/detect-only mode against the Zimbra host group for at least one full business cycle before switching to a prevent action.

The remaining seven queries (Q2–Q5, Q8–Q10) stay as investigate-only hunt queries: each carries a documented medium-or-higher FP source (webapps patch activity, backup automation, health-check scripts) that is better handled with a human reviewing hits than an automatic prevent action.

All CSV rows below are action=detect only. They trace to a single primary investigation (Microsoft); do not promote to prevent without independent corroboration.

type,value,action,severity,expiration,description,tags
ipv4,117.107.25.243,detect,high,2027-04-01,Zimbra CVE-2026-73570 dropper C2 serving de.sh,cve-2026-73570
ipv4,192.255.193.111,detect,medium,2027-04-01,Zimbra CVE-2026-73570 cryptominer C2 serving build_amd64,cve-2026-73570
ipv4,45.32.30.235,detect,high,2027-04-01,Zimbra CVE-2026-73570 reverse-shell C2 (ports 8080/8081),cve-2026-73570
ipv4,193.42.40.135,detect,high,2027-04-01,Zimbra CVE-2026-73570 org-wide reverse-shell/recon wave C2,cve-2026-73570
ipv4,3.209.137.175,detect,medium,2027-04-01,Zimbra CVE-2026-73570 secondary/rotated C2,cve-2026-73570
domain,transzimbra.linkpc.net,detect,high,2027-04-01,Zimbra CVE-2026-73570 dropper C2 (agent.sh/agent2.sh/zimdown2),cve-2026-73570
domain,psk1zim.abrdns.com,detect,high,2027-04-01,Zimbra CVE-2026-73570 zimclient2 WebSocket/TCP channel,cve-2026-73570
domain,tls.psk1zim.abrdns.com,detect,high,2027-04-01,Zimbra CVE-2026-73570 zimclient2 TLS channel,cve-2026-73570
domain,wslogzimbra.linkpc.net,detect,medium,2027-04-01,Zimbra CVE-2026-73570 zimdown2 installer status reporting,cve-2026-73570
domain,mexico-cashpay-test.s3.dualstack.mx-central-1.amazonaws.com,detect,medium,2027-04-01,Zimbra CVE-2026-73570 S3-hosted tarball dropper host,cve-2026-73570
sha256,dee5af1c0f76b45d28bafd6e60c07bb8e391d98addf81ef8f13d073acdb3c48a,detect,high,2027-04-01,Zimbra CVE-2026-73570 de.sh dropper script,cve-2026-73570
sha256,aea991f694911e321b0ab97534f2ad0291c392c0a43dabff664c563618bd036d,detect,medium,2027-04-01,Zimbra CVE-2026-73570 build_amd64 cryptominer,cve-2026-73570
sha256,6ab7de2509038edf580aef6229c1c3db17f4da8f2d7d940818faf617d1938244,detect,high,2027-04-01,Zimbra CVE-2026-73570 agent2.sh second-stage downloader,cve-2026-73570
sha256,bf28f38122bf20d5fac969cc414daa6a890cdea872d389ca93d2092b6b7773cf,detect,high,2027-04-01,Zimbra CVE-2026-73570 zimdown2 Go installer,cve-2026-73570
sha256,b594a42b8f1c6f090327bb9a3361c2d3515537fb7ac8da6b9061b9a3f330e159,detect,high,2027-04-01,Zimbra CVE-2026-73570 zimclient2 remote-access agent,cve-2026-73570
sha256,65a7576c389326b6cdf9c993d0be6e5d50fed9655d1cdf2a3a50f2c21c8ec435,detect,medium,2027-04-01,Zimbra CVE-2026-73570 Looptik LPE hacktool,cve-2026-73570
sha256,22ef852f6ebc39ee71235b90648b4b200b385c47d25c79545986493f8c70db69,detect,medium,2027-04-01,Zimbra CVE-2026-73570 loader staged as systemd-resolved,cve-2026-73570
sha256,518fe65dd349180191d9b258ab24876aaed6613cd657d0b626d1fc24e03a22b6,detect,high,2027-04-01,Zimbra CVE-2026-73570 decoded in-memory stage 2 (Base-chain command agent),cve-2026-73570

# Behavioral signatures (not atomic; these are the durable detections -- see Section 8 for full CQL)
snmptrap invocation immediately followed by shell metacharacters (; & | ` $()) in a service-state value
systemd unit named zimlog.service, chronyd-helper.service, or syslog_init.service owned by the zimbra account
symlink placed at /etc/pam.d/sudo, or any /etc/pam.d/ file owned by zimbra
/etc/sudoers.d/ fragment granting zimbra NOPASSWD:ALL (observed filename: 81_metric)
named pipe /tmp/s feeding an interactive shell into openssl s_client
masquerade filenames: .kworker_sys, .lpe_core, _chronyd, a mail-store archive saved with a .ico extension
webroot permission change (chmod/chown) under the zimbra account immediately followed by a .jsp write, then permission restoration

# Named malware / tooling observed (Microsoft Defender family names; not independently confirmed by a second vendor)
Chopper -- JSP web shell family
GodzillaWebShell -- JSP web shell family
CoinMiner -- generic cryptominer detection (build_amd64 payload)
Looptik -- LPE hacktool (GitHub-hosted toolkit staged as .lpe_core)
SuspGoLang -- generic Go-binary heuristic (covers zimdown2 / zimclient2 / zimbra-exfil family)
Dirtelti -- generic backdoor heuristic
zimdown2 -- Go installer; verifies the next stage via SHA-256 before execution
zimclient2 -- full remote-access agent: interactive shell, bidirectional file transfer, SOCKS5 proxy (WebSocket/TLS/raw TCP)
zimbra-exfil / client-dump -- Go implant reading /opt/zimbra/conf/localconfig.xml and exporting mailbox/LDAP secrets

# Patch / exposure audit one-liners
su - zimbra -c "zmcontrol -v"                    # must report 10.1.20 or later
rpm -qa | grep zimbra-snmp                        # RHEL/CentOS: is the optional package present?
dpkg -l | grep zimbra-snmp                        # Ubuntu/Debian equivalent
su - zimbra -c "zmswatchctl status"               # is the SNMP watchdog running?
# Temporary mitigation if patching must wait (CERT Polska):
su - zimbra -c "zmswatchctl stop"
# then set zimbraServiceEnabled snmp to FALSE via zmprov in LDAP

Playbook A: Emergency patch and exposure reduction

Step 1: Confirm current version and exposure
  su - zimbra -c "zmcontrol -v"
  rpm -qa | grep zimbra-snmp   # or: dpkg -l | grep zimbra-snmp
Prerequisites: root or sudo access to the Zimbra host; read-only, safe to run anytime.
Reboot required: No.
Rollback: None required (read-only check).

Step 2: Patch to ZCS 10.1.20 or later following Zimbra's documented upgrade procedure for your OS.
Prerequisites: Maintenance window; current full backup of /opt/zimbra and the LDAP/MySQL data directories; Zimbra support contract active if on a legacy branch requiring a supported upgrade path.
Reboot required: Yes, Zimbra services restart as part of the upgrade; a host reboot is not required but is commonly scheduled alongside it.
Rollback: Restore from the pre-upgrade backup and reinstall the prior ZCS package version per Zimbra's documented downgrade process. Downgrading does NOT remove any persistence an attacker planted while the host was vulnerable -- run Playbook B and C regardless of upgrade/rollback outcome.

Step 3: If patching must wait, disable the vulnerable path immediately.
  su - zimbra -c "zmswatchctl stop"
  zmprov mcf zimbraServiceEnabled snmp
  # then remove 'snmp' from the enabled service list via zmprov ms <server> -zimbraServiceEnabled snmp
Prerequisites: zimbra account shell access; confirm no internal tooling depends on SNMP traps from this host before disabling.
Reboot required: No; service restart only (zmcontrol restart recommended to apply cleanly).
Rollback: Re-enable with zmprov ms <server> +zimbraServiceEnabled snmp and zmswatchctl start, once patched to 10.1.20+.

Step 4: Restrict network exposure.
  # On the host firewall or upstream security group, block inbound TCP 7071 (admin console)
  # and UDP/TCP SNMP-related ports from all sources except a defined management CIDR.
Prerequisites: Identify and document the management CIDR before applying; confirm no legitimate remote admin workflow is broken.
Reboot required: No.
Rollback: Remove the added firewall/security-group rule to restore prior connectivity.

Playbook B: PAM/sudoers integrity lockdown and auditd watches

Step 1: Verify current PAM/sudoers integrity.
  stat /etc/pam.d/sudo
  ls -la /etc/sudoers.d/
  grep -r "pam_exec" /etc/pam.d/
Prerequisites: root access; read-only.
Reboot required: No.
Rollback: None required (read-only check).

Step 2: If a symlink or unexpected pam_exec hook is found, restore /etc/pam.d/sudo from a known-good package copy and remove the rogue /etc/sudoers.d/ fragment.
  rpm -V zimbra-core   # or the relevant package providing the PAM config, to compare against pristine
  rm /etc/sudoers.d/<rogue-fragment>
Prerequisites: Confirm the fragment is attacker-created, not a legitimate local policy, before removing; take a copy for evidence first.
Reboot required: No.
Rollback: If removal breaks an unrelated legitimate sudo policy, restore the fragment from the evidence copy and re-investigate.

Step 3: Add auditd watches for future tampering.
  auditctl -w /etc/pam.d/ -p wa -k zimbra_pam_watch
  auditctl -w /etc/sudoers.d/ -p wa -k zimbra_sudoers_watch
  auditctl -w /etc/systemd/system/ -p wa -k zimbra_systemd_watch
Prerequisites: auditd installed and running; confirm watch count does not exceed kernel audit rule limits.
Reboot required: No; rules persist across reboot only if also added to /etc/audit/rules.d/.
Rollback: auditctl -W /etc/pam.d/ -p wa -k zimbra_pam_watch (and equivalents) to remove the watch.

Playbook C: Credential rotation runbook

Step 1: Capture current secrets for comparison/evidence (do this BEFORE rotating).
  su - zimbra -c "zmlocalconfig -s" > /root/zimbra_localconfig_pre_rotation.evidence
Prerequisites: Secure storage for the evidence file; restrict access immediately (chmod 600, root-owned).
Reboot required: No.
Rollback: Not applicable (evidence capture only).

Step 2: Rotate zimbraPreAuthKey and zimbraAuthTokenKey.
  zmprov generateDomainPreAuthKey <domain>
  # Review Zimbra documentation for the authtoken-key rotation procedure for your version;
  # this invalidates all active user sessions domain-wide.
Prerequisites: Maintenance window; notify users that they will be signed out of active webmail sessions.
Reboot required: Yes, mailboxd restart required to pick up new key material.
Rollback: Restore the pre-rotation localconfig.xml from backup if rotation causes an outage; re-attempt rotation once the root cause is identified. Note: rolling back the key material re-exposes any attacker who captured the old key, so only roll back operationally, then re-rotate promptly.

Step 3: Rotate LDAP/MySQL/Postfix/Amavis/replication service credentials.
  # Follow Zimbra's documented zmlocalconfig credential-rotation procedure per service.
Prerequisites: Full service restart planned; backup of localconfig.xml before changes.
Reboot required: Yes, affected services restart.
Rollback: Restore localconfig.xml and the corresponding service account passwords from the pre-rotation backup.

Validation gate status is tracked in Section 11. Telemetry-coverage gaps (cluster-wide sensor deployment, DNS visibility for OOB callbacks) are the two items most likely to leave a real compromise undetected in this pack as currently scoped.