Three checks before you trust your Zimbra server: CVE-2026-73570 actively exploited

Is this actually being exploited, or is it another “could theoretically”?

Exploited. On 30 September, Microsoft Threat Intelligence published an alert tracking active, in-the-wild abuse of CVE-2026-73570, an unauthenticated OS command injection bug in Zimbra Collaboration Suite. This isn’t a researcher’s proof-of-concept sitting in a GitHub repo. Attackers are landing on internet-facing mail servers, dropping web shells, and reading mailbox data.

When a vendor publishes detection guidance the same week it confirms exploitation, you’re already past the “early signs” stage. Treat it accordingly.

Do I need to be authenticated for this to hurt me?

No. That’s the whole problem. The flaw carries a CVSS of 8.9 precisely because it requires no authentication — an attacker who can reach the Zimbra web interface over the network can execute commands on the host. No stolen password, no phished session, no insider. Network reachability is the vulnerability prerequisite.

So the mental model “we’re fine, nobody has valid creds” doesn’t apply here. If port 443 answers from the internet, you’re in scope.

Which versions and configurations are exposed?

Microsoft’s guidance frames this around internet-facing Zimbra instances. I’m not going to hand you a precise affected-version matrix, because the authoritative one is Zimbra’s own security advisory — and inventing version numbers to sound confident is how people patch the wrong thing.

What I’ll say plainly: if your Zimbra web interface is reachable from the open internet, assume you’re exposed until you’ve confirmed against the vendor advisory for CVE-2026-73570 that your exact build and patch level is clear. “We think we’re current” is not confirmation. Check the running version:

1
2

# Run as the zimbra user on the host
su - zimbra -c "zmcontrol -v"

Then compare against Zimbra’s advisory for this CVE. Don’t rely on your memory of the last upgrade window.

How does the command injection actually work?

The category is the mechanism: unauthenticated user-supplied input reaches an OS command execution path on the server without being sanitised. Somewhere in the request-handling flow, attacker-controlled data is passed into something that ultimately runs a shell command, and the input isn’t escaped or validated the way it should be.

Zimbra typically runs its web stack under a dedicated zimbra service account, so injected commands execute with that account’s privileges — which on a mail server is more than enough to read mail stores, write files into the web directories, and establish persistence. I’m deliberately not reconstructing the exact vulnerable parameter here; the public detail is thin, and a half-right exploit walkthrough helps attackers more than defenders. The remediation doesn’t change regardless of the precise injection point.

What are the attackers doing once they’re in?

Two things Microsoft calls out specifically:

• Web shells for persistence. A small script planted in a web-accessible directory so the attacker can come back over plain HTTPS, blending into normal web traffic, long after the initial injection.
• Mailbox data access. This is a mail server. The crown jewels are right there — message bodies, attachments, contact lists, calendar invites, and whatever credentials your users have emailed themselves because everyone does.

The sequence that bites you in six months: they inject, drop a shell, and leave. You patch the initial bug weeks later, feel relieved, and the web shell is still sitting in your web directory waiting. Patching the CVE does not evict an attacker who already has a foothold. Hunt separately.

How do I check whether I’ve already been hit?

Start with Microsoft’s alert, not with me. Their 30 September write-up is the source of record for this campaign’s specific indicators — file paths, hashes, and detection logic drawn from what they actually observed. Pull those indicators and match them against your hosts first. If Microsoft names a path or a hash, that beats any generic pattern I could invent, and I’m not going to attribute file locations to their guidance that I can’t confirm are in it.

What I can give you is a read-only triage pass built from standard Zimbra directory conventions, not from published IOCs. Treat it as a net for anomalies to investigate, then confirm anything it surfaces against Microsoft’s actual indicators. It reports; it doesn’t delete:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#!/usr/bin/env bash
# Generic Zimbra web-shell triage — REPORT ONLY. Nothing is modified or removed.
# These are conventional Zimbra web-serving paths, NOT Microsoft-published IOCs.
# Cross-reference every hit against Microsoft's 30 Sept CVE-2026-73570 alert.
# Adjust paths to match your deployment before trusting a clean result.
​
ZIMBRA_ROOT="/opt/zimbra"
​
echo "== Recently modified web-executable files under the Zimbra tree (last 30 days) =="
# Typical web-serving directories live under the Jetty paths; confirm yours.
find "$ZIMBRA_ROOT" -type f \( -name '*.jsp' -o -name '*.jspx' -o -name '*.php' \) \
  -mtime -30 -printf '%TY-%Tm-%Td %TH:%TM  %u  %p\n' 2>/dev/null | sort
​
echo
echo "== Suspicious POSTs to script files in access logs =="
# Adjust log path to match your deployment.
grep -Erh 'POST .*\.(jsp|jspx|php)' "$ZIMBRA_ROOT"/log/ 2>/dev/null \
  | awk '{print $1, $4, $6, $7}' | sort | uniq -c | sort -rn | head -40
​
echo
echo "== Shell-spawning indicators in recent logs =="
grep -Erih 'wget|curl|/bin/sh|/bin/bash -c|base64 -d' \
  "$ZIMBRA_ROOT"/log/ 2>/dev/null | tail -40
​
echo
echo "Triage complete. Every line above is a lead, not a verdict."
echo "Authoritative indicators: Microsoft Threat Intelligence, 30 Sept 2026."

Tune the window to the exposure period you care about. If you find something, Microsoft’s published hashes and paths are more reliable than my generic patterns — match against those before you conclude anything. And if you confirm a shell, treat the box as compromised: isolate, image, rotate every credential that touched it, and involve IR before you start deleting evidence.

There’s no patch version in the headline. What do I actually do right now?

Go to Zimbra’s security advisory for CVE-2026-73570 and apply the fixed build they specify for your release line. I’m not quoting a version here because I won’t publish a patch number I can’t verify — and a wrong one sends you chasing a release that doesn’t fix this. The vendor advisory is authoritative; use it.

In priority order:

1. Patch internet-facing instances first, per Zimbra’s advisory. These are the ones under active attack.
2. Hunt before you declare victory. Run the triage above and match against Microsoft’s indicators. Patching closes the door; it doesn’t remove anyone already inside.
3. Rotate secrets on any host where you can’t rule out compromise — service account credentials, API tokens, anything the zimbra user could read.

Can I just firewall it off instead of patching?

As a stopgap for the next few hours while you stage the patch — yes, and you should. Restrict the web interface to known source ranges, put it behind a VPN or a reverse proxy with IP allowlisting, and drop it off the open internet entirely if your users can tolerate that. No reachability, no unauthenticated exploit.

But network isolation is a compensating control, not a fix. The bug is still in the code, and the moment someone pokes a hole in the allowlist — a new office, a cloud egress IP, a “temporary” rule that outlives the person who made it — you’re exposed again. Isolate today, patch this week, don’t confuse the two.

My org doesn’t run Zimbra. Why is this on my desk?

Because your partners might. Zimbra is heavily deployed across education, government, and mid-market enterprises running on-prem mail. If a supplier, contractor, or acquired subsidiary runs an exposed instance, their compromised mailbox server is a very good source of your legitimate-looking email, your shared documents, and your account recovery flows.

So for SOCs: add a hunt task even if you have zero Zimbra internally. Flag inbound mail and shared infrastructure from partners known to run it, and watch for the usual post-compromise tells — new OAuth grants, unusual forwarding rules, logins from the partner’s mail infrastructure to your tenant.

How urgent is this, really?

Immediate for anyone running internet-facing Zimbra. Unauthenticated, remotely exploitable, actively used to steal mail, with public detection guidance already out — that combination doesn’t get a grace period. Patch or isolate today; hunt this week.

For everyone else, it’s a this-week hunt task scoped to your partner and supply chain exposure. The organisations that get burned by this won’t be the ones who got hit on day one. They’ll be the ones who patched the CVE, skipped the web shell hunt, and found out in Q1 that someone had been reading the CEO’s inbox since September.