CVE-2026-73570: Zimbra Vulnerability Now Under Active Exploitation — Attack Mechanics + Remediation
CVE-2026-73570 (CVSS 8.9) is being actively exploited in Zimbra Collaboration Suite. A breakdown of the attack chain, CVSS vector and step-by-step remediation.
CVE-2026-73570: Zimbra Vulnerability Now Under Active Exploitation — Attack Mechanics + Remediation
If your organization runs Zimbra Collaboration Suite as your mail platform instead of Exchange, there's something worth checking today. CISA added CVE-2026-73570 to its Known Exploited Vulnerabilities (KEV) Catalog on August 21, with a remediation deadline of August 24 for Federal Civilian Executive Branch (FCEB) agencies — just 3 days, notably tighter than the usual window.
This isn't a "there's a vulnerability, patch now" news blurb. We're walking through how the exploit chain actually works, because understanding the mechanics is what tells you whether — and how badly — your environment is exposed.
What happened
| |
|---|
| CVE | CVE-2026-73570 |
| Product | Zimbra Collaboration Suite (ZCS) |
| Vulnerability class | OS Command Injection (CWE-78) |
| CVSS 3.1 | 8.9 (HIGH) |
| Added to CISA KEV | August 21, 2026 |
| Fixed in | 10.1.20 |
| Affected versions | Everything below 10.1.20 (Zimbra's advisory doesn't state a specific lower-bound version for this particular CVE) |
One thing worth clearing up: CISA's short description says the attacker sends "specially crafted SMTP requests," which reads as if every internet-facing Zimbra mail server is exposed. Cross-checking Zimbra's own Security Advisories and NVD tells a narrower story.
How the attack actually works
The real flaw sits in SNMP notification processing, inside the optional zimbra-snmp package — not the core mail-delivery path every Zimbra install runs.
A server is only exposed if all three of these are true:
- The
zimbra-snmp package is installed (an optional component, not a default one)
- SNMP trapping is enabled via the
snmp_notify parameter, with the swatchdog service actually doing the work behind the scenes — per CERT Polska's advisory, swatchdog runs by default once zimbra-snmp is installed, so the variable that actually matters to check is the snmp_notify setting, not a separate toggle
- The version is below 10.1.20
When those conditions line up, here's the chain:
- No authentication needed. The attacker doesn't need any credentials (
PR:N) or any user action (UI:N) — the official CVE description says the trigger is a specially crafted SMTP request, with the actual flaw occurring during SNMP notification processing on the receiving end. So the request comes in over SMTP, and the OS command gets embedded in a field that flows into the SNMP notification path the system expects to hold an ordinary notification value.
- Zimbra processes that value without sanitizing it first. This is the textbook shape of CWE-78: untrusted external input gets concatenated straight into a command the shell interprets, instead of being escaped or passed through a parameterized call.
- The embedded command actually executes, running as the
zimbra user. Not root — but plenty enough to read or modify every mailbox on the system, exfiltrate config or credentials stored under that account, or serve as a foothold for lateral movement elsewhere on the network.
Reading the CVSS vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L = 8.9 HIGH
| Metric | Value | What it means |
|---|
| Attack Vector | AV:N | Exploitable over the network — no local access needed |
| Attack Complexity | AC:H | High — requires a specific configuration (zimbra-snmp installed + snmp_notify enabled), not a spray-and-hope-it-lands bug |
| Privileges Required | PR:N | No credentials needed |
| User Interaction | UI:N | No user action required |
| Scope | S:C | Impact isn't confined to the vulnerable component itself |
| Confidentiality / Integrity | C:H / I:H | Full read and modify access |
| Availability | A:L | Partial availability impact, not a full system outage |
AC:H reflects that exploitation needs a specific configuration in place (zimbra-snmp installed + snmp_notify enabled) rather than hitting every internet-facing server unconditionally — it's not something that hits every server it touches, only the subset with SNMP notifications actually turned on. That's not the same as "not dangerous," though: CISA's KEV listing confirms this is being exploited against servers that do meet the precondition, in the wild, right now.
A transparency note: Zimbra's own advisory still doesn't publish code-level detail — its Zimbra-native severity field still reads "TBD." The more specific mechanism detail here (the snmp_notify parameter, the swatchdog service, the filesystem paths to check) comes from CERT Polska's advisory, not from Zimbra or NVD directly. Public proof-of-concept code has since appeared in open repositories — treat any such code as untrusted, and don't run it against systems you don't own. Everything above otherwise reflects what CISA, NVD, Zimbra, and CERT Polska have confirmed — not our own reverse engineering.
Why ordinary logging misses this until it's too late
The real risk with this class of bug isn't just "a vulnerability exists" — it's that the fallout blends into normal traffic. An unexpected child process spawned under the zimbra user (a shell, a curl/wget pulling something from outside, a reverse shell) is easy to miss inside the volume of logs a mail platform generates, unless it's mapped against something like MITRE ATT&CK technique T1059 (Command and Scripting Interpreter) or correlated against unusual outbound connections. Spotting that signal in raw logs by hand takes real effort, especially at mail-platform log volumes.
zcrLog's Threat Analysis maps behavioral detections to MITRE technique T1059 (Command and Scripting Interpreter), the same technique category unauthorized command execution like this falls under — one way to make an anomaly like this easier to spot, though it's not a substitute for patching or the hunting steps below.
Remediation — what to do right now
Fix the root cause first
- Update Zimbra Collaboration Suite to 10.1.20 or later
- Verify with
zmcontrol -v both before and after the update to confirm the patch actually landed
If you can't patch immediately (compensating controls)
- The trigger is a crafted SMTP request — the same inbound path any working mail server has to keep open — so firewalling the SNMP trap port (UDP 161/162) does not close this off; that port controls a different kind of access than the one this CVE actually uses
- Disable or remove the
zimbra-snmp package (or at minimum turn off snmp_notify) if you don't actually rely on SNMP monitoring — this is the actual compensating control that removes the vulnerable code path, per CERT Polska and Zimbra's own guidance
- If you do rely on SNMP monitoring and can't disable it, patching is the only reliable fix — treat this as a priority update rather than something a network-layer control can substitute for
Check whether you've already been hit (threat hunting)
CERT Polska — Poland's national CERT, which published its own advisory specifically for this CVE — offers more concrete guidance than the vendor advisory does:
- Check
/var/log/zimbra.log for entries indicating a malicious payload service being started and stopped
- Audit files created by the
zimbra user over the past 30 days, specifically in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/ — CERT Polska recommends checking these paths in the context of the ongoing campaign it's tracking
Beyond CERT's own steps, two more general hunting ideas worth adding on your own initiative (not something CERT's advisory specifically calls for):
- Look for unexpected child processes under the
zimbra-snmp service or the zimbra user — anything that shouldn't originate from a mail/collaboration service
- Review outbound connection logs initiated by the
zimbra user for unfamiliar IPs or domains
CERT Polska described an "ongoing campaign" exploiting this vulnerability as of its advisory on August 17 — several days ahead of CISA's KEV addition on August 21. The advisory doesn't state exactly when the campaign began, but confirmed active exploitation that far back means that if your environment meets the risk conditions and hasn't been checked yet, your hunt should extend back to at least mid-August.
Quick self-check
| Condition | Does this apply to you? |
|---|
| Running Zimbra Collaboration Suite below 10.1.20 | Check with zmcontrol -v |
zimbra-snmp package installed | Check via your package manager |
snmp_notify parameter enabled | Check Zimbra's notification configuration |
| SNMP trap port open to the general internet | Check your firewall/security group rules |
If all three of the first conditions apply, you're in the exposed group and should update first. In the meantime, pulling logs from multiple sources — mail server, firewall, endpoint — into one correlated view via a SIEM makes it far easier to see which servers actually meet the risk conditions, instead of checking each one by hand. Take a look at zcrLog pricing if that's useful to you.
Get in touch
Questions about this vulnerability, or want help assessing Zimbra exposure across your environment? Our team offers a free consultation.
Sources: CISA KEV Catalog · NVD — CVE-2026-73570 · Zimbra Security Advisories · CERT Polska