A remote code execution vulnerability exists in Zimbra Collaboration

CVE-2026-73570 is an unauthenticated OS command injection (CWE-78) in Zimbra Collaboration Suite's SNMP notification processing path. When the optional zimbra-snmp package is installed and the snmp_notify parameter is active — with the swatchdog watchdog service running (which is on by default) — an attacker can send specially crafted SMTP-layer requests that escape input boundaries and execute arbitrary shell commands as the zimbra user. All ZCS versions before 10.1.20 are affected. The patch shipped July 20, 2026; the CVE was published August 13, 2026.

Zimbra scored this HIGH at 8.9 with AC:H (high attack complexity). That rating is defensible on paper — the optional package dependency genuinely narrows the vulnerable population. But in practice, CERT Polska issued Alert 145/2026 on August 17 confirming active exploitation in the wild, Shadowserver tracks over 12,100 internet-exposed Zimbra instances, and the zimbra user has sweeping access to mail spools, application directories, and service configs. For organizations that have zimbra-snmp installed, the vendor's HIGH is accurate; we agree and hold at 8.9. The optional-package friction is the only thing keeping this from CRITICAL.

Why this verdict

• Active exploitation confirmed: CERT Polska Alert 145/2026 documents real-world attacks as of August 17, 2026. This is not theoretical.
• Pre-auth RCE on internet-facing infrastructure: Zimbra mail servers are internet-exposed by design. No credentials or user interaction required. The zimbra user has access to all organizational email — this is a mass-data-exfiltration outcome.
• Role multiplier: Zimbra is a mail server, canonically internet-facing and holding all organizational email. In environments where Zimbra also serves as the LDAP directory (common in smaller orgs), compromise extends to identity-store access. Blast radius: host → all mailboxes → potential credential harvest → lateral movement. This satisfies the HIGH floor for a high-value-role component.
• Optional package narrows population: zimbra-snmp is not installed by default — it is an explicit opt-in during deployment. This means a meaningful fraction of the ~12,100 exposed instances are *not* vulnerable even if unpatched. This is the primary reason the verdict stays HIGH rather than escalating to CRITICAL.
• AC:H limits mass exploitation: The CVSS vector's high attack complexity suggests the injection requires specific payload construction, not a trivial single-request exploit. Combined with no public PoC, this raises the attacker skill floor.

Why not higher?

CRITICAL would require that the vulnerability affects all or nearly all Zimbra deployments without additional prerequisites. The zimbra-snmp package is optional and must be explicitly installed — we lack data on adoption rates but it is reasonable that a significant fraction of deployments (potentially 30-60%) never install SNMP monitoring. Additionally, AC:H indicates non-trivial exploitation, and no public PoC exists to enable mass commodity attacks. These two factors together keep the effective population and ease-of-exploitation below the CRITICAL threshold.

Why not lower?

Active exploitation in the wild immediately disqualifies any downgrade below HIGH. The attack is pre-auth, network-accessible, and targets a component (mail server) that is internet-facing by design and holds highly sensitive data. The zimbra user's access to all mailboxes means successful exploitation has organization-wide data impact. Even with the optional package friction, confirmed ITW exploitation means the chain is proven viable and attackers have already solved the complexity barrier.

1. Disable SNMP notifications immediately — Run zmprov ms $(zmhostname) zimbraSnmpNotificationEnabled FALSE and restart the swatchdog service. This eliminates the vulnerable code path entirely without disrupting mail delivery. Deploy within hours given active exploitation.
2. Block SNMP-related ports at the perimeter — If you cannot disable SNMP notifications at the application layer, ensure UDP 161/162 and any custom SNMP trap ports are not reachable from untrusted networks. Note: the injection vector may traverse SMTP/HTTPS, so this alone is insufficient.
3. Audit for web shells on Zimbra servers — Immediately search /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/ for JSP or other script files created by the zimbra user in the last 30 days. Cross-reference CERT Polska IOCs from Alert 145/2026. Treat any finding as confirmed compromise.
4. Deploy WAF rules for SMTP command injection patterns — If Zimbra is behind a WAF or reverse proxy, add rules to inspect and block SMTP payloads containing shell metacharacters (;, |, $(), backticks). This is a partial control — effectiveness depends on the specific injection syntax attackers are using.
5. Restrict outbound network access from Zimbra servers — Limit egress from Zimbra hosts to only required destinations (DNS, patch repos, upstream mail relays). This constrains post-exploitation data exfiltration and C2 communication. Deploy within 3 days.

Run this script on each Zimbra server as root or the zimbra user. It checks whether the zimbra-snmp package is installed, whether SNMP notifications are enabled, and whether the installed version is vulnerable. Example: sudo bash zimbra_cve_2026_73570_check.sh

#!/bin/bash
# CVE-2026-73570 Vulnerability Check for Zimbra Collaboration
# Run on each Zimbra server as root or zimbra user
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

ZIMBRA_BIN="/opt/zimbra/bin"
VULN_STATUS="UNKNOWN"

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

# Get Zimbra version
VERSION=$($ZIMBRA_BIN/zmcontrol -v 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+')
if [ -z "$VERSION" ]; then
  echo "UNKNOWN - Could not determine Zimbra version"
  exit 2
fi

echo "Zimbra version detected: $VERSION"

# Check if zimbra-snmp package is installed
SNMP_INSTALLED=false
if dpkg -l zimbra-snmp 2>/dev/null | grep -q '^ii'; then
  SNMP_INSTALLED=true
  echo "zimbra-snmp package: INSTALLED (via dpkg)"
elif rpm -q zimbra-snmp 2>/dev/null | grep -qv 'not installed'; then
  SNMP_INSTALLED=true
  echo "zimbra-snmp package: INSTALLED (via rpm)"
else
  echo "zimbra-snmp package: NOT INSTALLED"
  echo "PATCHED - zimbra-snmp not installed, CVE-2026-73570 does not apply"
  exit 0
fi

# Check if SNMP notifications are enabled
SNMP_ENABLED=$($ZIMBRA_BIN/zmprov gs $($ZIMBRA_BIN/zmhostname) zimbraSnmpNotificationEnabled 2>/dev/null | grep -i 'TRUE')
if [ -n "$SNMP_ENABLED" ]; then
  echo "SNMP notifications: ENABLED (vulnerable code path active)"
else
  echo "SNMP notifications: DISABLED (vulnerable code path inactive)"
  echo "PATCHED - SNMP notifications disabled, attack vector mitigated"
  exit 0
fi

# Compare version - vulnerable if < 10.1.20
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)

if [ "$MAJOR" -lt 10 ]; then
  VULN_STATUS="VULNERABLE"
elif [ "$MAJOR" -eq 10 ] && [ "$MINOR" -lt 1 ]; then
  VULN_STATUS="VULNERABLE"
elif [ "$MAJOR" -eq 10 ] && [ "$MINOR" -eq 1 ] && [ "$PATCH" -lt 20 ]; then
  VULN_STATUS="VULNERABLE"
else
  VULN_STATUS="PATCHED"
fi

echo ""
if [ "$VULN_STATUS" = "VULNERABLE" ]; then
  echo "VULNERABLE - Zimbra $VERSION with zimbra-snmp and SNMP notifications enabled"
  echo "  -> Upgrade to 10.1.20+ or disable SNMP notifications immediately"
  echo "  -> Check for IOCs: find /opt/zimbra/jetty/webapps /opt/zimbra/jetty_base/webapps /tmp -user zimbra -mtime -30 -type f"
  exit 1
else
  echo "PATCHED - Zimbra $VERSION is at or above 10.1.20"
  exit 0
fi

Sources

1. NVD - CVE-2026-73570
2. CERT Polska Alert / OffSeq Threat Radar
3. Zimbra Security Center
4. Zimbra 10.1.20 Patch Release Blog
5. CyberSecurityNews - Zimbra SNMP Command Injection
6. GBHackers - Zimbra RCE Vulnerability
7. CyberPress - Zimbra OS Command Injection Exploited
8. Canadian Centre for Cyber Security Advisory