CVE-2026-73570: Zimbra Collaboration Suite (ZCS) OS Command Injection Vulnerability

What this software does

Zimbra Collaboration Suite (ZCS) is a full-featured email and collaboration platform that many organizations run on their own servers instead of using a hosted provider. It includes mail transfer, calendaring, contacts, and webmail, and it typically holds the entire email history of the organization that runs it. Because it is a mail server, it is exposed to the internet by design — it has to accept incoming SMTP connections from anywhere, or it would not be a mail server. That permanent internet exposure is what makes a flaw in its mail-handling path so serious.

What went wrong

The vulnerability is an OS command injection in how ZCS processes SMTP requests. Command injection means the software takes part of the incoming request and passes it to the operating system's command interpreter without properly sanitizing it. An attacker who can send a specially crafted SMTP request can get the server to execute arbitrary operating system commands.

The commands run as the Zimbra user — the dedicated service account that the mail system runs under. That account has broad access to the mail store, the configuration files, and the databases that hold the entire mail system together. The attacker does not need an account on the system, does not need to authenticate to the mail server, and does not need any user interaction. The description does not state an authentication requirement, and the CVSS vector agrees on that point: no privileges required, no user interaction required.

The one mitigating factor in the vector is attack complexity being rated high. That suggests the crafted request is not trivial to produce — it may require specific knowledge of the mail server's internal state or a particular sequence of conditions. But "high complexity" in a CVSS vector is a modest barrier, and it has not stopped this from being exploited in the wild.

Why this one matters

This is confirmed exploited in the wild, listed in CISA's Known Exploited Vulnerabilities catalogue. That is not a prediction or a likelihood estimate — it is a statement that someone has already done this against a real target. The EPSS probability of exploitation within 30 days is about one in five, which is high for a vulnerability that requires any degree of crafting.

What that combination means operationally is simple: this is the profile that automated scanning finds quickly. A mail server is reachable from the internet by definition, the flaw needs no credentials, and the payoff is code execution as a user that can read every mailbox on the system. If you run ZCS, you should assume that public scanners are already looking for this, and that the gap between "patch available" and "you patched" is the window that matters. The severity rating of 8.9 is high, but the real number to watch is how many days you stay exposed.

Are you affected?

You are affected if you run Zimbra Collaboration Suite and you have not applied the fixed version. There is no configuration option that makes you safe — this is in the core SMTP handling path, which is enabled by default and cannot be disabled without breaking mail delivery.

The attack arrives over SMTP, which means any server that accepts inbound mail is reachable by the attacker. If your ZCS server is behind a firewall that only allows mail from specific relay hosts, your exposure is reduced, but that is an unusual setup for a mail server and you should not assume it applies to you.

How to fix it

The fix ships as an upstream release from the Zimbra project itself, in version 10.1.20. This will not arrive through your distribution's package manager — there is no distribution package for ZCS, so your usual apt upgrade or dnf update will not deliver this fix. You need to take the upstream release and upgrade however you originally installed ZCS.

Once you have applied the upgrade, do not stop there. The most common way a patch silently fails is that the package on disk is new but the running process is still the old one, because the service was not restarted. Restart the Zimbra services after upgrading, and verify that the version the running service reports matches the fixed version — not the version on disk, but the version the live process tells you it is. A mail server that has been up for months will happily keep running the vulnerable code in memory until you restart it.

If you cannot patch immediately

If you cannot apply the fixed version today, the honest answer is that there is no good mitigation for this one. The vulnerable code is in the SMTP path, which you cannot disable without stopping mail delivery entirely. Blocking SMTP at a proxy or firewall would stop the attack, but it would also stop your mail — which for most organizations is not a viable trade.

What you can do is limit the damage if you are hit. Restrict outbound connections from the Zimbra server to only the hosts it legitimately needs to reach — mail relays, DNS servers, update servers. An attacker who gets command execution as the Zimbra user will try to use that access to reach other systems or to exfiltrate the mail store. A restrictive outbound firewall makes both of those harder. This is not a fix; it is buying time and reducing the blast radius while you arrange the upgrade.

How to tell if you were already targeted

Because this is confirmed exploited in the wild, checking for signs of compromise is worthwhile. Look for processes running as the Zimbra user that are not part of normal mail operation — a shell, a script interpreter, or anything connecting outbound to an address that is not a mail relay or update server. Check the Zimbra user's crontab and any scheduled tasks for entries nobody on your team added. Look for recently modified files in the Zimbra installation directory and in the web server's document root, particularly scripts that were not there before.

If you find anything suspicious, preserve the evidence before deleting it — take a copy of the files and the relevant log entries, then involve your incident response process. Do not simply remove the suspicious file and assume you are clean; an attacker with command execution can install persistence in many places, and removing one artifact without understanding the full scope leaves you compromised.

Reducing the blast radius

Run ZCS as its own dedicated user with minimal privileges beyond what the mail system needs — do not run it as root, and do not give the Zimbra user access to the rest of the server. The description says commands execute as the Zimbra user, so the damage an attacker can do is bounded by what that account can reach.

Keep the Zimbra server isolated from the rest of your infrastructure. It should not be on the same network segment as your internal file servers, databases, or administrative systems. A mail server is internet-facing by design, which means it is the most likely entry point for an attacker — treat it as a hostile perimeter system and segment it accordingly.

Finally, apply ZCS updates promptly when they are released. This is the second command injection flaw in a mail server's SMTP path to be exploited in the wild in recent memory, and the pattern is consistent: the fix ships, scanners pick it up within days, and the organizations that wait are the ones that get hit. When the next update lands, treat it as urgent until you have verified the running service is on the new version.