Unauthenticated RCE in Zimbra

CERT Polska has confirmed active in-the-wild exploitation of CVE-2026-73570, a command injection flaw in Zimbra Collaboration Suite that hands an unauthenticated attacker remote code execution as the zimbra user. The bug carries a CVSS score of 8.9 and was patched in ZCS 10.1.20 last month. Any internet-facing Zimbra server still running an earlier build with the optional zimbra-snmp package installed should be treated as a live target, and if SNMP notifications are enabled on it, as a possible incident.

What the flaw actually does

The vulnerability lives in Zimbra's SNMP notification processing. When the optional zimbra-snmp package is installed and SNMP notifications are turned on, untrusted input reaching that code path is not sanitized before it lands in a shell context. An attacker sends specially crafted SMTP requests to the mail server, the notification handler processes attacker-controlled content, and arbitrary operating system commands execute as the Zimbra service account.

Two details make this worse than the score suggests. First, no authentication is required: no mailbox, no valid recipient, no captured credential. Second, the trigger arrives over SMTP on port 25, which is the one port a mail server exists to leave open. There is no firewall rule that closes this attack surface without taking the server out of service.

Execution lands as the zimbra user rather than root. That is a real limit and worth stating plainly: the attacker does not get an immediate kernel-level foothold. It is also close to irrelevant in practice. The zimbra account owns the mail store, the LDAP configuration, the Jetty web application directories and the TLS material. Whoever owns that account owns the mail.

Hunting for compromise

CERT Polska published a short indicator checklist alongside its bulletin. Start with the service log, then walk the drop directories.

• /var/log/zimbra.log: look for unexplained Zimbra service restarts. Successful injection through this path tends to disturb the service, and a restart with no change ticket behind it is the cheapest lead available.
• /opt/zimbra/jetty/webapps/ and /opt/zimbra/jetty_base/webapps/: any file created in the last 30 days that you cannot tie to a patch or a deployment. Webshells dropped here inherit the application server and survive a restart.
• /tmp/: staging payloads, downloaders and short-lived tooling. Anything owned by the zimbra user that you did not put there deserves a full look.
• Outbound connections that are not mail. A mail host that starts speaking HTTP to an unfamiliar address is doing something other than delivering mail.

Thirty days is the window CERT Polska named, and it is a floor rather than a ceiling. The patch shipped last month, and the gap between a Zimbra fix and working public exploitation has historically been short. If your log retention reaches further back, hunt back to the 10.1.20 release date at minimum.

Zimbra is a standing target, not an occasional one

This is not an isolated event. Zimbra sits in front of government ministries, universities, hospitals and regional service providers, frequently in deployments that one small team maintains alongside a dozen other systems. That profile has made it a durable favorite for state-aligned operators. Last month the U.S. government detailed a phishing campaign run by the Russia-linked group Laundry Bear, also tracked as CL-STA-1114, TA488, UNK_PitStop and Void Blizzard, which has targeted Zimbra mail servers at Western government and commercial organizations since at least July 2025. That operation weaponized CVE-2025-66376, a stored cross-site scripting flaw in Zimbra's Classic UI, to deliver a JavaScript payload named ZimReaper that harvested email communications and other sensitive data.

The lesson is not the specific actor. It is that a Zimbra bug with a working exploit gets picked up quickly by operators who want mailboxes, and mailboxes are exactly what these servers hold. CVE-2026-73570 skips the phishing step entirely and goes straight to command execution.

What to do this week

• Update to ZCS 10.1.20 or later. No configuration change beats the patch.
• If you cannot patch within 24 hours, disable SNMP notifications or remove the zimbra-snmp package on hosts that do not need it. That removes the precondition the exploit depends on.
• Hunt before you patch, or at least preserve evidence first. Copy /var/log/zimbra.log and capture a timestamped file listing of the three directories above before the update rewrites anything.
• Rotate what the zimbra account can reach: service credentials, LDAP bind passwords, API tokens for connected systems, and the TLS private keys if you have any reason to think the host was touched.
• Review mailbox delegation and forwarding rules across the whole tenant. Mail theft configured through legitimate features outlives any webshell you delete.

The scoping question worth answering today is a small one: which of your Zimbra hosts run a build older than 10.1.20, and which of those have zimbra-snmp installed with notifications enabled. That is two commands per host. Exploitation is confirmed and ongoing, so the interval between finishing that inventory and finishing the patch is the interval you are exposed.