Zimbra CVE-2026-73570 Exploited: Why Patching Isn't the Finish Line

What Happened

Zimbra Collaboration Suite has an unauthenticated remote code execution flaw, tracked as CVE-2026-73570, and it is being actively exploited right now. Researchers first flagged exploitation attempts against unpatched servers, and within days CISA added the vulnerability to its Known Exploited Vulnerabilities catalog and ordered federal agencies to patch on an urgent timeline. Poland's CERT issued its own warning about active exploitation in the wild, which tells you the campaign is not confined to one region or one sector.

The technical detail that matters most: this is unauthenticated. An attacker does not need stolen credentials, a phished password, or an insider. They need a reachable Zimbra instance and the exploit chain, which reportedly runs through the platform's SNMP component to achieve command injection and full remote code execution. That combination, unauthenticated plus RCE plus a mail server, is the kind of finding that makes a SOC analyst's coffee go cold.

Zimbra has shipped a fix. Organizations are advised to update to the patched release (10.1.20 in the vendor's guidance) as the remediation path. If your Zimbra instance is internet-facing, and most are, because that is the point of a mail server, the exploitation window between public disclosure and mass scanning has been shrinking with every major CVE cycle. Analysts covering this one have made the same observation: the days of "we'll patch it next maintenance window" are effectively over.

Who's Exposed

Anyone running an unpatched, internet-reachable Zimbra Collaboration Suite deployment is a target, full stop. That includes:

• MSPs and MSSPs hosting Zimbra for multiple downstream clients on shared or multi-tenant infrastructure.
• Mid-market and enterprise organizations running Zimbra as their primary mail platform, often because it is lighter-weight and cheaper to operate than a hosted Microsoft 365 or Google Workspace tenant.
• Any environment where Zimbra sits at the edge with SNMP or admin interfaces exposed to the internet rather than restricted to internal management networks.

If you manage infrastructure for clients and even one of them runs Zimbra, this is not a "check with the client later" item. It is a "check right now" item, because mail servers are a preferred foothold. They hold credentials, they relay trust, and they are frequently under-monitored relative to how much damage a compromise there can cause.

Why Patch Compliance Is a Vanity Metric Here

Here is the uncomfortable part of this story that dashboards will not tell you. Confirming that a Zimbra server is now running the patched version answers exactly one question: is the door currently locked. It answers nothing about whether someone already walked through it while it was open.

Active exploitation campaigns against a newly disclosed RCE typically run for days or weeks before most organizations even see the CVE announcement, let alone schedule and complete the patch. During that window, attackers who got in ahead of the fix do not politely leave once you update the software. Web shells, scheduled tasks, and new admin accounts created before the patch was applied survive the patch. The vulnerability that let them in gets closed. The access they already established does not.

This is exactly the gap that security researchers covering this CVE keep circling back to: patch-and-pray treats a CVE announcement as the end of the incident, when for anyone exploited before they patched, it is closer to the beginning. A vulnerability scanner will happily report "compliant" on a server that has an attacker's persistence mechanism sitting quietly in a cron job. Compliance and compromise are two different questions, and only one of them shows up on a patch report.

What a Partner Should Actually Do This Week

If you have Zimbra anywhere in your client base or your own environment, here is the sequence that matters, in order:

1. Inventory first. Confirm every Zimbra instance under management, its current version, and whether the admin or SNMP interfaces are reachable from the public internet. You cannot protect what you have not counted.
2. Patch, but treat it as step one, not the finish line. Apply the vendor fix immediately on every affected instance. This stops new exploitation attempts. It does nothing for exploitation that already happened.
3. Hunt for pre-patch compromise. Review authentication logs, admin account changes, mailbox export activity, and process execution on the mail server going back to before the vulnerability's disclosure window. Look specifically for web shells, unexpected scheduled tasks, and outbound connections that do not match normal mail server behavior.
4. Check for lateral movement, not just server-level compromise. A compromised mail server is rarely the end goal. It is a credential harvesting platform and a pivot point into directory services, VPNs, and other internal systems. If the mail server talks to Active Directory or Entra ID, that trust relationship needs scrutiny too.
5. Document and communicate. If you are an MSP or MSSP, your clients need to know this happened, what you found, and what you did about it, in writing. "We patched it" is not the same statement as "we patched it and confirmed no prior compromise," and clients deserve to know which one you are actually making.

The Vijilan Connection

This is the exact scenario our Global SOC is built to handle, and it is worth being specific about why. A patch report tells a partner that a door is closed. It does not tell them whether someone already walked through it, set up a workspace, and is waiting for the next opportunity. Closing those two gaps requires two different capabilities, and most tooling only gives you one.

The first is retrospective log hunting: pulling authentication history, process execution records, and network telemetry from before the patch was applied, and looking specifically for the fingerprints of a pre-patch web shell or lateral movement attempt. That is analyst work, not a dashboard, and it is what separates "we're compliant" from "we're clean."

The second is authority to act, immediately, not eventually. When our Global SOC analysts find indicators consistent with compromise on a mail server, whether that is through ThreatRespond™ Managed XDR correlating identity and endpoint telemetry, or through direct log analysis against a monitored platform, the response is isolation, not just a flagged ticket sitting in a queue waiting for someone on the client side to see it at 9am. A compromised mail server left connected for even a few extra hours is a credential-harvesting machine with a live internet connection. The value of a SOC that can act is measured in what does not happen next.

For partners managing Zimbra, or any internet-facing mail platform, across a client base, that pairing, the hunt and the authority to contain, is the difference between a patch note and an incident report. If this CVE has you rethinking how mail server telemetry gets watched across your book of business, that is a conversation worth having before the next KEV entry lands.

We never compete with our partners for their clients. If you want to talk through what monitoring and response coverage looks like for the platforms you already manage, visit /msp. If you're evaluating cost against risk on this one, our /pricing page has the detail.

Frequently asked questions

What is CVE-2026-73570?

It is an unauthenticated remote code execution vulnerability in Zimbra Collaboration Suite, reportedly reachable through the platform's SNMP component, that is under active exploitation and has been added to CISA's Known Exploited Vulnerabilities catalog.

Is patching Zimbra enough to be safe?

Patching stops new exploitation attempts but does nothing about compromise that may have already occurred before the patch was applied. Organizations that were exposed during the active exploitation window should hunt for web shells, unauthorized admin accounts, and lateral movement, not just confirm patch status.

How do I know if my Zimbra server was compromised before I patched?

Review authentication logs, admin account changes, and process execution history going back before the vulnerability's disclosure window, looking for indicators like unexpected scheduled tasks, web shell artifacts, or unusual outbound connections.

What should MSPs tell clients running Zimbra right now?

That the patch has been applied, and separately, whether a compromise hunt was performed and what it found. Those are two distinct statements and clients should get both, in writing.