Thirty-One Days of Silence Between a Zimbra Patch and a Warning

Thirty-one days. That’s the gap between July 20, when Zimbra shipped version 10.1.20 to fix CVE-2026-73570, and August 20, when CERT Polska went public with the news that attackers were already using it. A month where the fix existed and the warning didn’t.

I review tools for a living, which mostly means I spend my days figuring out whether a thing does what its landing page claims. This Zimbra situation isn’t an AI story, but it’s the clearest illustration I’ve seen lately of the problem that keeps showing up in every toolkit evaluation I do: the gap between “a patch exists” and “you knew you needed it.”

What actually happened

The short version: CVE-2026-73570 is a command injection flaw in Zimbra Collaboration Suite’s SNMP monitoring component. If SNMP notifications are enabled, an unauthenticated attacker can get remote code execution. No credentials needed. From there, the reported goal is credential theft and reading email.

Zimbra’s security team patched it in 10.1.20 on July 20. CERT Polska reported active exploitation on a Monday in August. And the part I find most instructive: there is no public count of how many instances were compromised. Nobody has published numbers on whether the hits were real deployments, honeypots, or servers that had already applied the update.

The part that should bother you

A missing number is not a small detail. It’s the whole story.

When a vulnerability gets disclosed with no compromise count, every downstream decision you make is guesswork. Your security team can’t size the blast radius. Your leadership can’t decide whether this is a weekend emergency or a Tuesday ticket. And if you’re a smaller shop running self-hosted Zimbra because it was the affordable option, you’re reading the same four paragraphs everyone else is and trying to infer urgency from tone.

I keep running into this same shape in the AI tooling I test. A vendor ships a model update, mentions a “security improvement” in the changelog, and gives you nothing about what the old behavior allowed. You’re left guessing whether your six-month-old integration was quietly doing something you wouldn’t have approved.

SNMP is the detail worth sitting with

The flaw lives in the SNMP monitoring component, and it only bites when SNMP notifications are enabled. That’s a configuration-dependent vulnerability, which means some portion of Zimbra operators were never exposed at all.

Which raises a question most teams can’t answer quickly: do you know whether SNMP notifications are on in your deployment? Not “do you think so” — do you know? For a lot of self-hosted setups, monitoring got configured once during initial deployment by someone who has since changed jobs. The config is correct. The institutional memory is gone.

This is the same failure mode I see with AI agent deployments. Somebody enabled a tool-use permission or a webhook during setup because it was needed for a demo, and it’s still on eighteen months later. The attack surface isn’t what you designed. It’s what you designed plus everything you forgot to turn off.

What I’d actually do

Based only on what’s confirmed, here’s the practical sequence:

• Check your Zimbra version. If you’re below 10.1.20, you’re running unpatched code against a flaw with confirmed exploitation.
• Check whether SNMP notifications are enabled. This determines whether you were ever reachable.
• Assume credential theft if you were exposed and unpatched during that window. The reported objective is stealing login credentials, so password rotation is the obvious follow-on.
• Don’t wait for a compromise count. It may never come. Treating absence of data as absence of risk is how the July-to-August gap turns into a breach notification.

The reviewer’s note

Self-hosted email is a reasonable choice. It gives you control over your data, it avoids per-seat pricing that scales badly, and for plenty of organizations it’s the right call. But control is not free — it’s an ongoing obligation. The patch landed on July 20 and did nothing for anyone who didn’t apply it.

What I’d push for in any stack, email or AI tooling or otherwise: a standing process that watches upstream releases for the software you actually run, not the software you meant to inventory. Version checks on a schedule. A written list of which optional components are enabled and why. Unglamorous work that pays off exactly once, on a day like August 20, when someone forwards you a CERT advisory and you can answer “already patched” in under a minute.

Thirty-one days was the window here. Next time it might be shorter, and you won’t get advance notice either way.

🕒 Published: October 1, 2026