You get an alert from your web proxy: an unusual POST to a path that contains the string "snmp" against a Zimbra host. A few minutes later your EDR shows /bin/sh spawned by the "zimbra" user and a new cron entry writes into /opt/zimbra. That sequence — HTTP request, process spawn as zimbra, and persistence touches — is the sequence defenders are now seeing for CVE-2026-73570. CISA added this CVE to its KEV catalog on August 21, 2026, and Zimbra shipped a fix in release 10.1.20.
What the exploit looks like in practice
Public reporting and vendor notes indicate CVE-2026-73570 is a pre-auth command injection in the SNMP notification processing when the optional zimbra-snmp package is installed and SNMP notifications are enabled. Attackers deliver a crafted SNMP notification or related HTTP payload that reaches the SNMP notification handler and causes the Zimbra process to call system-level commands as the zimbra user. The practical detection surface is HTTP(S) logs that contain SNMP-related strings and host-level process creation logs where the zimbra user invokes shells or networking tools.
Because exploitation is unauthenticated, perimeter controls like WAFs and reverse proxies are the first place you can block or detect suspicious requests. But many teams will find gaps: patched hosts, vulnerable SNMP service still enabled, or reverse proxies forwarding raw request bodies. Shadowserver and other scanning groups have already reported hundreds of compromised Zimbra instances, which means hunting across logs and endpoints is necessary even after patching. The following sections give concrete rules and commands you can drop into existing toolchains.
Look for three observable steps when hunting: an HTTP or network request that mentions SNMP or contains unusual shell characters, immediate or short-latency process creation by the zimbra user, and persistence artifacts (new webshells, cron entries, or SSH keys). Triage should start with containment (isolate the host and preserve memory/disk) and then move to forensic collection; the playbook below is arranged to support that triage flow with practical signatures and queries.
Network detection: Suricata/Snort signatures and what they'll catch
At network layer, the most reliable immediate detection is pattern-matching on HTTP(S) payloads proxied in plain-text by reverse proxies or on decrypted traffic at TLS termination points. A conservative Suricata rule looks for SNMP-related indicators in a request body combined with suspicious shell characters such as backticks, $(), or ; which often appear in command injection attempts. Deploy such signatures on IDS sensors or at TLS-terminating proxies where decryption is available.
Drop this Suricata rule into your ruleset as a starting point. It intentionally matches on strings rather than an exact exploit request to catch fail variants; tune it by whitelisting internal monitoring sources and known SNMP management traffic. If your environment performs TLS decryption at the edge, place this rule there. If you cannot decrypt, watch for anomalous outbound connections from Zimbra servers instead (SSH, unusual high-port connections).
alert http any any -> $ZIMBRA_SERVERS any (msg:"Zimbra CVE-2026-73570 possible SNMP command-injection"; flow:established,to_server; content:"snmp"; http_client_body; pcre:"/[\`\$\(\);]{1,}/R"; classtype:attempted-admin; sid:1000001; rev:1;)Network rules are noisy by default; use them for high-confidence detections by combining with process telemetry. For example, trigger a high-fidelity alert only when the Suricata hit is followed within 2 minutes by an EDR process-creation event for user zimbra invoking a shell. That correlation eliminates many false positives from legitimate SNMP management traffic.
SIEM and endpoint hunts: Sigma, Splunk, and Elastic queries
Use Sigma to write portable detection logic that catches suspicious process creation by the zimbra user. Match process names (/bin/sh, bash, python) and common inline execution flags (-c). In SIEM ingest, ensure you have process events and the 'user' or 'uid' field set so the rule can identify executions by the zimbra account. The Sigma rule below is compact and targets process creation logs from Windows and Linux agents configured to populate Sysmon-like fields.
title: Zimbra SNMP RCE - suspicious shell by zimbra user
logsource:
product: linux
service: auditd
detection:
selection:
SubjectUserName: zimbra
Image|endswith:
- "/bin/sh"
- "/bin/bash"
CommandLine|contains_any: ["-c", "eval", "base64", "python -c"]
condition: selection
level: highIf you run Splunk, this translated query hunts for child processes started by the zimbra user and looks for hatch patterns such as base64 decoding or inline shells. Run it across the last 72 hours for initial triage; expand to 30 days if you suspect long-running intrusions. Correlate with web proxy logs for requests containing "snmp".
index=os_proc OR index=processes sourcetype=procmon OR sourcetype=auditd user=zimbra (process="/bin/sh" OR process="/bin/bash" OR process="/usr/bin/python") | search CommandLine="* -c *" OR CommandLine="*base64*" | table _time host user process CommandLineElastic users should query process.events where process.entity_id or process.executable matches known shells and host.user.name equals zimbra. Enrich these hits with recent network events to prioritize hosts that contacted remote IPs shortly after shell execution. These SIEM hunts convert noisy lower-fidelity signals into high-confidence triage items.
Host triage, YARA and common forensics actions
On the host, start with volatile data collection: ps, open network connections, and active processes run as zimbra. Check for unexpected crontab entries for the zimbra user, new binaries under /opt/zimbra, and webroot modifications. Preserve /var/log/messages, /opt/zimbra/log, and the mailbox store. If you find a suspicious process, dump it and collect memory; typical exploitation chains spawn shells that then download a secondary payload or drop a webshell into a writable webroot.
Use YARA to hunt for common webshell artifacts in web directories and in the Zimbra install paths. The example rule below looks for base64 decoding functions and PHP eval patterns; adapt it for your environment if Zimbra is serving different languages or you see custom payloads during investigation. Run YARA with recursion restricted to /opt/zimbra to reduce noise.
rule zimbra_webshell_common {
meta:
author = "ShellCodeX"
description = "Common webshell strings and base64 decoding"
strings:
$s1 = "eval(base64_decode"
$s2 = "preg_replace("
$s3 = "system("
condition:
any of them
}
# run: yara -r zimbra_webshell_common.yar /opt/zimbraCommon triage commands you will use repeatedly are included below. These check for zimbra-owned shells, recent file writes, and network connections created by the zimbra user. Capture full outputs into your evidence archive before making changes. If you see outgoing SSH or uncommon high-port connections, isolate the host immediately.
ps -u zimbra -o pid,ppid,cmd
lsof -u zimbra
crontab -u zimbra -l
find /opt/zimbra -type f -mtime -7 -ls
ss -tunap | grep -E "(ssh|nc|socat|ftp)"Containment checklist and next steps for defenders
Immediate containment priorities: (1) Isolate the host from the network (or apply host-only firewalling) to stop outbound data movement; (2) preserve volatile evidence (ps, netstat, memory dump); (3) snapshot disks for forensic analysis; (4) rotate credentials for service and administrative accounts that may have been accessed; and (5) search and remediate other Zimbra hosts with the same configuration. Because the vulnerability is unauthenticated, assume any exposed, unpatched Zimbra with zimbra-snmp enabled is high-risk.
Patching is mandatory: upgrade to Zimbra 10.1.20 or later as Zimbra's advisory indicates the SNMP notification handling flaw was fixed in that release. After patching, rerun the network and host hunts above. If you find confirmed exploitation, perform an escalation to incident response for a full forensic timeline: document the initial request, subsequent parent-child process relationships, files written, and any C2 communications. Notify stakeholders per your incident handling policy and consider external notification where required.
What to drop into your toolchain now: the Suricata rule above at TLS termination points, Sigma translations to your endpoint and SIEM stack, the Splunk/Elastic queries for retrospective hunts, and the YARA rule for filesystem sweeps. If you have limited staff, prioritise hosts that are internet-exposed and those running zimbra-snmp. Finally, log and track every remediation action so you can demonstrate compliance with BOD 26-04 where applicable.
What to do next: apply the vendor patch (10.1.20+), run the network/endpoint hunts against at least the previous 30 days of telemetry, and treat any hit as high severity: isolate, collect forensic artifacts, and rebuild from known-good images where compromise is confirmed. Use the signatures and queries above as a baseline and tune them to your environment.