Dateline: August 20, 2026
No Login, No Click: Attackers Are Hijacking Zimbra Servers Right Now
Poland’s national cyber team just pulled the fire alarm. Attackers have started breaking into Zimbra mail servers through a flaw that needs no password, no phishing, and no user click. If your mail server runs the wrong version, someone could already be running commands on it.
What Happened?
On August 17, CERT Polska issued Alert 145/2026 confirming that a critical Zimbra RCE vulnerability is being exploited in live attacks. The bug is tracked as CVE-2026-73570.
It lives in Zimbra’s SNMP monitoring path. When SNMP trap notifications are switched on through the snmp_notify setting and the Swatchdog service is running, an unauthenticated attacker can inject operating-system commands and run them as the zimbra user. Swatchdog runs by default, so any server with the optional SNMP feature turned on is a target.
Zimbra shipped the fix back on July 20 in version 10.1.20. The patch was out for a month before attackers turned the flaw into a working weapon. That gap is the whole story. A patch on a download page protects nobody. A patch installed on the server does.
This is not Zimbra’s first bad stretch. The platform has been hit by wave after wave of critical bugs, and a Russian state group spent months last year stealing mail and 2FA codes through a separate Zimbra flaw. Mail servers hold sensitive messages, login material, and internal records. That makes them a permanent bullseye.
What’s the Impact?
A remote attacker with no credentials can take over the mail server. From there the options get ugly fast.
They can drop web shells for lasting access. They can read mailboxes. They can harvest credentials and session data. They can use the server as a launch pad to move deeper into the network. CERT Polska is telling defenders to treat any sign of exploitation as a full server compromise, not a minor alert.
Thousands of companies run Zimbra, with heavy exposure across Europe and Asia. Every internet-facing instance that skipped the July update is now sitting in the blast radius.
Zimbra SNMP Command Injection — Hunting Signals
CVE-2026-73570 · Fixed in ZCS 10.1.20 · Active exploitation confirmed
Why no hashes or IPs? No public file hashes, C2 IP addresses, or malicious domains have been released for this campaign at time of publication. Exploitation runs through crafted requests and hands-on activity, so the reliable signals are behavioral. Hunt for the diagnostic indicators below.
Log Signatures — /var/log/zimbra.log
Unexpected service state flips
Entries where a payload or service transitions stopped → running or running → stopped without a matching admin action. May signal command execution through the SNMP path.
Swatchdog / SNMP anomalies
Abnormal activity tied to the Swatchdog service or SNMP trap processing on servers where snmp_notify is enabled.
File System — Files created by the zimbra user in the last 30 days
Web app directories (web shell risk)
/opt/zimbra/jetty/webapps/
/opt/zimbra/jetty_base/webapps/
Temp directory (staged scripts / binaries)
/tmp/ — check for dropped scripts, binaries, or unfamiliar temporary artifacts.
Host & Network Behavior
Suspicious process activity
Unusual child processes spawned by the zimbra account, or shell activity not tied to normal operations.
Abnormal outbound connections
Unexpected egress from the mail server, especially to newly seen infrastructure. Treat as potential payload retrieval or C2.
Exposed SNMP surface
SNMP trap notifications enabled via snmp_notify with Swatchdog running (default). Reachable UDP port 161 raises exposure.
If You Find a Match
Preserve logs and suspect files · isolate the affected server · rotate potentially exposed credentials and session material · treat as full server compromise · engage incident response. Patching to 10.1.20 does not remove an attacker who is already resident.
How to Avoid This
- Patch first. Hunt second. Do both today.
- Upgrade every Zimbra instance to version 10.1.20 or later. Check your installed version before you assume you are safe.
- If you cannot patch right away, review whether SNMP trap functionality is even needed. Where it is not, disable it. Treat that as a stopgap, not a fix.
- Then go hunting. Read
/var/log/zimbra.logfor odd service state changes, the kind where a payload flips from stopped to running or back. Inspect the web app and temp directories for files the zimbra user created in the last 30 days. - If you find evidence of a break-in, preserve the logs, isolate the box, rotate exposed credentials, and call in incident response.
