← Back to Feed CACHED · 2026-10-08 01:13:37 · CACHE_KEY CVE-2026-73570
CVE-2026-73570 · CWE-78 · Disclosed 2026-08-13

Zimbra Collaboration Suite SNMP Notification OS Command Injection

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Someone is mailing bombs to your mailroom that the janitor's monitoring radio turns into skeleton keys for every lock in the building

CVE-2026-73570 is an unauthenticated OS command injection (CWE-78) in Zimbra Collaboration Suite's SNMP notification pathway. When the optional zimbra-snmp package is installed and SNMP notifications are enabled, Zimbra's swatchdog health-monitoring daemon passes attacker-controlled data from inbound SMTP requests directly into snmptrap shell invocations without sanitizing shell metacharacters. The result: any unauthenticated attacker who can send an email to the server can execute arbitrary OS commands as the zimbra service account. All ZCS versions prior to 10.1.20 are affected — including the 8.8.15 and 9.x branches — when zimbra-snmp is present. The patch shipped July 20, 2026; public disclosure followed August 13.

Zimbra rates this HIGH at 8.9 with AC:H to reflect the non-default prerequisite (the optional SNMP package). That friction is *real* — not every Zimbra instance runs zimbra-snmp. But the vendor score undersells the blast radius. 274 servers were confirmed compromised within two weeks of exploitation going public, out of ~12,000 internet-facing instances. Microsoft's September 30 analysis documents a fully weaponized post-exploitation chain — JSP web shells, privilege escalation to root via PAM/sudoers manipulation, exfiltration of zimbraAuthTokenKey and zimbraPreAuthKey (the signing keys that authenticate *every session* on the platform), LDAP secrets, and lateral movement across cluster nodes using Zimbra's built-in SSH identity. An attacker who lands this chain doesn't just own a mail server — they own every mailbox, every credential, and every federated trust the Zimbra deployment touches. The vendor's 8.9 would be fair for an unexploited vuln behind a non-default gate; with KEV listing, mass exploitation, and custom APT tooling in the wild, this is a CRITICAL.

"Actively exploited unauthenticated RCE in internet-facing Zimbra mail servers steals org-wide auth secrets"
02 · The Attack Path

6 steps from start to impact.

STEP 01

Send crafted SMTP email to target Zimbra server

The attacker delivers a specially crafted email via SMTP to the internet-facing Zimbra MTA. No authentication or user interaction is required — the attacker only needs the server to accept mail, which is the server's primary function. The payload embeds shell metacharacters in SMTP fields that will later reach the SNMP notification pipeline.
Conditions required:
  • Target Zimbra server accepts inbound SMTP (port 25/465/587)
  • zimbra-snmp package is installed
  • SNMP notifications are enabled
Where this breaks in practice:
  • zimbra-snmp is an optional, non-default package — not all deployments have it
  • SNMP notifications must be explicitly enabled
Detection/coverage: Microsoft Defender signature Exploit:Linux/SnmpTrapCmdInject.A. CERT Polska advises monitoring /var/log/zimbra.log for anomalous 'Service status change' entries. Nuclei template available.
STEP 02

Swatchdog processes tainted data into snmptrap invocation

Zimbra's swatchdog health-monitoring daemon reads log events and constructs snmptrap shell commands from Perl-generated scripts. The attacker-controlled SMTP data reaches this pipeline without proper sanitization. Shell metacharacters followed by download commands (e.g., wget|sh or curl|bash), terminated by trailing # comments, bypass argument sanitization and execute as the zimbra service account.
Conditions required:
  • swatchdog service is running (default when SNMP is configured)
Where this breaks in practice:
  • Commands execute as zimbra user, not root — limits immediate blast radius
Detection/coverage: Hunt for child processes of swatchdog or Perl executing wget, curl, bash, or sh. Look for DNS callbacks to OOB services (oast.fun, dnslog.pp.ua, requestrepo.com). User-Agent ZB73570 observed in pre-disclosure scanning.
STEP 03

Deploy JSP web shells and reverse shells

The attacker uses the initial command execution to download and deploy JSP web shells into Jetty and mailboxd application directories (/opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/). Payloads are staged as encoded, compressed fragments that are reconstructed locally to evade detection. Memory-backed execution via memfd_create provides fileless persistence. The dropper agent2.sh downloads zimdown2, which installs zimclient2 — a full remote-access agent supporting WebSocket, TLS, and raw TCP C2 channels.
Conditions required:
  • Outbound network access from Zimbra to attacker C2 infrastructure
Where this breaks in practice:
  • Egress filtering or proxy-only outbound access blocks payload download
  • EDR on the Zimbra host may flag JSP writes by shell processes
Detection/coverage: Microsoft signature Trojan:Linux/ShellDropper.AA. Monitor for JSP file creation by non-Java processes. File hashes: de.sh (dee5af1c…), zimdown2 (bf28f381…), zimclient2 (b594a42b…). C2 domains: transzimbra.linkpc.net, psk1zim.abrdns.com.
STEP 04

Escalate privileges to root

The attacker modifies /etc/pam.d/sudo to grant the zimbra account unrestricted, passwordless sudo access. Techniques include abusing Zimbra's sudo-authorized service helpers (zmmailboxdmgr), writable log directories, pam_exec, and zmstat-fd. The Looptik privilege-escalation toolkit (SHA-256: 65a7576c…) automates this process. After escalation, the attacker has full root access on the mail server.
Conditions required:
  • Initial code execution as zimbra user (step 2)
  • Zimbra sudo helpers exist on disk (default)
Where this breaks in practice:
  • Hardened systems with immutable PAM configs or audit-mode SELinux may block PAM modification
  • File integrity monitoring on /etc/pam.d/ would trigger alerts
Detection/coverage: Microsoft signature HackTool:Linux/ZimbraPLE.A. Monitor for modifications to /etc/pam.d/sudo and /etc/sudoers.d/. Alert on zimlog.service systemd unit creation with timestomping.
STEP 05

Harvest authentication secrets and mailbox data

With root access, the attacker extracts centralized Zimbra secrets: zmlocalconfig -s yields LDAP, MySQL, Postfix, and Amavis credentials. Authenticated LDAP queries pull zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret — the signing keys that authenticate every session on the platform. A custom Go binary (zimbra-exfil/client-dump) queries MySQL for all mailbox, mailbox_metadata, mobile_devices, and out_of_office records. Mailbox content is archived to /opt/zimbra/final.tar.gz and exfiltrated using AzCopy downloaded from Microsoft infrastructure.
Conditions required:
  • Root access on Zimbra server (step 4)
Where this breaks in practice:
  • DLP or network monitoring may detect large archive exfiltration
  • AzCopy download from Microsoft CDN is an anomalous event on a Linux mail server
Detection/coverage: Monitor for zmlocalconfig -s execution, bulk LDAP queries for auth key attributes, creation of large tar archives in /opt/zimbra/, and AzCopy binary presence on Linux hosts.
STEP 06

Lateral movement across Zimbra cluster nodes

The attacker leverages Zimbra's built-in SSH identity (/opt/zimbra/.ssh/zimbra_identity) to access other nodes in the cluster. zmprov is used for environment discovery — mapping all mailbox and MTA nodes. rsync transfers web shells and tooling between peer systems with non-interactive SSH and disabled host-key verification. Each additional node expands the attacker's access to additional mailbox stores and provides redundant persistence points.
Conditions required:
  • Multi-node Zimbra deployment
  • Zimbra SSH identity file exists (default in cluster deployments)
Where this breaks in practice:
  • Single-server deployments (common in SMB) have no lateral movement targets
  • Network segmentation between Zimbra nodes would disrupt rsync-based propagation
Detection/coverage: Monitor for SSH connections from zimbra user to peer nodes outside normal replication patterns. Alert on rsync of JSP files between Zimbra hosts.
03 · Compensating Control

1
CRITICAL 9.2→IGNORE 0.0
SEVERITY REDUCED
Remove or disable the zimbra-snmp package immediately — Run apt remove zimbra-snmp or yum remove zimbra-snmp on all Zimbra nodes to eliminate the vulnerable code path entirely. This is the single highest-impact mitigation because it removes the attack surface without requiring a full ZCS upgrade. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL. Verify removal with dpkg -l zimbra-snmp or rpm -q zimbra-snmp.
2
CRITICAL 9.2→MEDIUM 5.5
SEVERITY REDUCED
Block or filter crafted SMTP input at the MTA level — If removing zimbra-snmp is not immediately feasible, configure Postfix header/body checks or an upstream mail gateway to reject SMTP messages containing shell metacharacter sequences targeting the SNMP notification path. This is a partial mitigation — the exact injection patterns may evolve. Deploy within 3 days.
3
CRITICAL 9.2→HIGH 7.5
SEVERITY REDUCED
Restrict outbound network access from Zimbra servers — Configure host-based firewall rules or network ACLs to deny outbound connections from Zimbra to arbitrary internet hosts. Allow only required destinations (DNS, NTP, OS update repos, antispam feeds). This breaks the attacker's ability to download post-exploitation tooling (agent2.sh, zimdown2, zimclient2) and exfiltrate data via AzCopy. Deploy within 3 days.
4
CRITICAL 9.2→HIGH 8.0
SEVERITY REDUCED
Deploy file integrity monitoring on Zimbra webroots and PAM configs — Monitor /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, /etc/pam.d/, and /etc/sudoers.d/ for unauthorized file creation or modification. Alert on JSP file writes by non-Java processes. This does not prevent exploitation but enables rapid detection of post-exploitation activity. Deploy within 3 days.
5
CRITICAL 9.2→IGNORE 0.0
SEVERITY REDUCED
Upgrade to ZCS 10.1.20 or later — Apply the vendor patch to remediate the root cause. This is the definitive fix. Per the noisgate remediation SLA for CRITICAL, patch within 90 days — but given KEV status and active exploitation, treat as patch immediately, within hours. After patching, conduct compromise assessment: hunt for web shells, check for zimlog.service, audit PAM configs, rotate all Zimbra credentials and auth-token signing keys.
What doesn't work
  • WAF/reverse proxy in front of HTTPS — the attack vector is SMTP (port 25/465/587), not HTTP. A web application firewall protecting the Zimbra web UI does nothing to prevent the injection via email delivery.
  • Disabling the Zimbra web UI — the vulnerability is in the SNMP notification pipeline triggered by SMTP input, not the web interface. Taking down the web UI leaves the attack path intact.
  • Network-level rate limiting on SMTP — a single crafted email is sufficient for exploitation. Rate limiting does not prevent the attack; the attacker needs exactly one message delivered.
  • Zimbra two-factor authentication — 2FA protects user login sessions. This vulnerability requires no authentication at all; it exploits the mail processing pipeline before any authentication decision.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationConfirmed active. 274 servers compromised as of August 24, 2026 (Shadowserver Foundation). CERT Polska warned August 17. Microsoft published detailed analysis September 30 documenting multi-region, multi-industry targeting with custom malware. Pre-disclosure scanning observed July 28–August 7 using ZB73570 User-Agent.
CISA KEVListed 2026-08-21, due date 2026-08-24 (3-day remediation window for FCEB agencies). KEV entry
EPSS0.71663 — top ~3% of all CVEs by exploitation probability. This is an extraordinarily high EPSS score, reflecting observed exploitation activity and public PoC availability.
Proof-of-conceptMultiple public PoCs. GitHub repos: hainhc/CVE-2026-73570, jishino567/CVE-2026-73570 (Python SMTP injection PoC). Listed on Sploitus. Nuclei template available.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L — Network-reachable, no auth/interaction required, scope change (compromise extends beyond the vulnerable component). AC:H reflects the non-default zimbra-snmp prerequisite. Confidentiality and Integrity both HIGH due to full command execution.
Affected versionsAll ZCS versions prior to 10.1.20 with zimbra-snmp installed: includes 8.8.15.x, 9.x, and 10.0.x–10.1.19 branches. Fixed in 10.1.20 (released July 20, 2026). Backport status for 8.8.15 and 9.x branches not confirmed in public advisories — contact Synacor support.
Internet exposureShadowserver identified ~12,100 internet-facing Zimbra instances globally, of which 8,200+ remained unpatched as of late August. ~2.3% compromise rate within two weeks of exploitation going public. Zimbra SMTP listeners are internet-facing by design.
Threat actor toolingCustom malware ecosystem: Zimdown2 (Go installer), Zimclient2 (full RAT with WebSocket/TLS/TCP C2), agent2.sh (dropper), Looptik (privilege escalation toolkit). C2 domains: transzimbra.linkpc.net, psk1zim.abrdns.com. IPs: 45.32.30.235, 193.42.40.135, 3.209.137.175.
Disclosure timelineSynacor disclosed June 26, 2026. Patch released July 20. Pre-disclosure scanning July 28–Aug 7. Public disclosure August 13. CERT Polska active exploitation warning August 17. CISA KEV August 21. Microsoft report September 30.
Credited researchersMicrosoft Security Research team: Mahesh Mandava, Rajesh Kumar Natarajan. Initial exploitation reports from CERT Polska and Shadowserver Foundation.

Sources.

  1. Microsoft Security Blog — Tracking CVE-2026-73570
  2. The Hacker News — Attackers Deploy Web Shells via Zimbra Flaw
  3. CISA KEV Catalog Entry
  4. eSecurity Planet — 274 Zimbra Servers Compromised, 8,200 Unpatched
  5. Help Net Security — Unpatched Zimbra Servers Falling to CVE-2026-73570
  6. Penligent — Zimbra Unauthenticated Command Injection Explained
  7. Falcon Internet — Zimbra SNMP Flaw Under Active Attack
  8. CISA Alert — KEV Addition August 21, 2026
05 · The Call

Final Verdict
↑ UPGRADED to CRITICAL (9.2/10)

Why this verdict

  • Active mass exploitation with custom tooling. 274 confirmed compromises, pre-disclosure scanning (July 28, 29 days before public disclosure), and purpose-built malware (Zimclient2 RAT, Looptik privesc) demonstrate a sophisticated, operationalized attack campaign — not opportunistic scanning. This alone pushes above the vendor's HIGH baseline.
  • KEV-listed with 3-day FCEB deadline. CISA added this August 21 with a due date of August 24 — one of the shortest remediation windows issued. The USG considers this an emergency-tier threat.
  • EPSS 0.71663 confirms weaponization signal. Top ~3% of all CVEs. The model captures the PoC availability, exploitation activity, and attack surface exposure that the static CVSS vector cannot.
  • Role multiplier: Zimbra IS the production mail server. Nearly 100% of Zimbra deployments are production email infrastructure — this is not a library that *might* be deployed in a sensitive role. The demonstrated attack chain harvests zimbraAuthTokenKey and zimbraPreAuthKey (the keys that sign *every* session), LDAP credentials, and full mailbox data. Blast radius = organization-wide email access + credential theft + lateral movement to cluster nodes. This is mass data egress at identity-infrastructure scale. The component is canonically high-value: the bug is IN the mail server, and the outcome IS organization-wide compromise. Floor = CRITICAL.
  • Non-default config gate (AC:H) is real friction but overcome. The zimbra-snmp prerequisite means not all 12,100 exposed instances are vulnerable. However, 274 confirmed compromises (2.3%) and 8,200 unpatched instances demonstrate a sufficient vulnerable population. The friction justifies keeping the score below 10.0 but does not overcome the CRITICAL floor set by the role multiplier and active exploitation.
  • Vendor AC:H is already priced in. The vendor's 8.9 with AC:H appropriately captures the non-default prerequisite. The upgrade from 8.9 → 9.2 reflects the exploitation evidence, KEV listing, and demonstrated blast radius that post-date the vendor's initial scoring.

Why not higher?

A score above 9.2 would require either AC:L (all Zimbra instances vulnerable regardless of SNMP config) or direct root execution without privilege escalation. The zimbra-snmp prerequisite is a genuine gate that excludes a meaningful fraction of the installed base, and initial execution is as the zimbra service account, not root. The 9.2 captures the real-world severity with the friction discount already applied.

Why not lower?

Downgrading below CRITICAL would require either (a) evidence that the vulnerable population (zimbra-snmp installs) represents <1% of the installed base — contradicted by 274 confirmed compromises across 12,100 exposed instances — or (b) that the blast radius is contained to the mail server process alone — contradicted by Microsoft's documented chain to root access, credential theft, and cluster-wide lateral movement. The KEV listing and EPSS of 0.71663 independently confirm this is not a theoretical risk. Zimbra mail servers are canonically high-value infrastructure holding all organizational communications and authentication secrets; the CRITICAL floor applies.

06 · Verification

Crowdsourced verification payload.

Run this script on each Zimbra server as root or with sudo. Invoke with: sudo bash zimbra_cve_2026_73570_check.sh. No arguments needed. The script checks (1) whether zimbra-snmp is installed, (2) whether SNMP notifications are enabled, and (3) whether the installed ZCS version is patched.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-73570 Vulnerability Check
# Checks for: zimbra-snmp package, SNMP notification config, ZCS version
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

FIXED_MAJOR=10
FIXED_MINOR=1
FIXED_PATCH=20

echo "=== CVE-2026-73570 Check ==="
echo ""

# Check if Zimbra is installed
if [ ! -d /opt/zimbra ]; then
  echo "[INFO] Zimbra not found at /opt/zimbra"
  echo "UNKNOWN"
  exit 2
fi

# Get ZCS version
VERSION_FILE="/opt/zimbra/conf/.version"
if [ -f "$VERSION_FILE" ]; then
  ZCS_VERSION=$(grep -oP '\d+\.\d+\.\d+' "$VERSION_FILE" | head -1)
elif command -v zmcontrol &>/dev/null; then
  ZCS_VERSION=$(su - zimbra -c 'zmcontrol -v' 2>/dev/null | grep -oP '\d+\.\d+\.\d+' | head -1)
else
  ZCS_VERSION=""
fi

if [ -z "$ZCS_VERSION" ]; then
  echo "[WARN] Could not determine ZCS version"
  echo "UNKNOWN"
  exit 2
fi

echo "[INFO] ZCS version: $ZCS_VERSION"

# Parse version components
IFS='.' read -r V_MAJOR V_MINOR V_PATCH <<< "$ZCS_VERSION"

# Check if zimbra-snmp package is installed
SNMP_INSTALLED=false
if command -v dpkg &>/dev/null && dpkg -l zimbra-snmp 2>/dev/null | grep -q '^ii'; then
  SNMP_INSTALLED=true
elif command -v rpm &>/dev/null && rpm -q zimbra-snmp &>/dev/null; then
  SNMP_INSTALLED=true
elif [ -f /opt/zimbra/bin/zmswatchctl ]; then
  SNMP_INSTALLED=true
fi

echo "[INFO] zimbra-snmp installed: $SNMP_INSTALLED"

# Check if SNMP notifications are enabled
SNMP_ENABLED=false
if [ -f /opt/zimbra/conf/swatchrc ] || [ -f /opt/zimbra/conf/swatchrc.in ]; then
  if su - zimbra -c 'zmlocalconfig -q zimbra_snmp_enabled' 2>/dev/null | grep -qi 'true'; then
    SNMP_ENABLED=true
  fi
  # Also check if swatchdog is running
  if pgrep -f swatchdog &>/dev/null; then
    SNMP_ENABLED=true
  fi
fi

echo "[INFO] SNMP notifications enabled: $SNMP_ENABLED"

# Version comparison
VERSION_PATCHED=false
if [ "$V_MAJOR" -gt "$FIXED_MAJOR" ] 2>/dev/null; then
  VERSION_PATCHED=true
elif [ "$V_MAJOR" -eq "$FIXED_MAJOR" ] && [ "$V_MINOR" -gt "$FIXED_MINOR" ] 2>/dev/null; then
  VERSION_PATCHED=true
elif [ "$V_MAJOR" -eq "$FIXED_MAJOR" ] && [ "$V_MINOR" -eq "$FIXED_MINOR" ] && [ "$V_PATCH" -ge "$FIXED_PATCH" ] 2>/dev/null; then
  VERSION_PATCHED=true
fi

echo "[INFO] Version patched (>= 10.1.20): $VERSION_PATCHED"
echo ""

# Determine result
if $VERSION_PATCHED; then
  echo "PATCHED"
  exit 0
fi

if $SNMP_INSTALLED; then
  if $SNMP_ENABLED; then
    echo "[ALERT] zimbra-snmp is installed AND SNMP notifications are enabled on an unpatched version."
    echo "VULNERABLE"
    exit 1
  else
    echo "[WARN] zimbra-snmp is installed but SNMP notifications appear disabled. Exploitability is conditional."
    echo "VULNERABLE"
    exit 1
  fi
else
  echo "[INFO] zimbra-snmp is NOT installed. This instance is not exploitable via CVE-2026-73570."
  echo "PATCHED"
  exit 0
fi