Zimbra Stopped Backporting Without Saying So — and an Exploited Bug Just Proved It

Key Dates at a Glance

• CVE-2026-73570 added to CISA KEV: 2026-08-21; federal remediation deadline: 2026-08-24
• CERT Polska confirmed active exploitation: 2026-08-17 — 28 days after the fix shipped
• Zimbra 10.1: current line — latest 10.1.20 released 2026-07-20, the only release that fixes CVE-2026-73570
• Zimbra 10.0: End of General Support 2025-06-30; last patch 10.0.18 shipped 2025-11-06
• Zimbra 9.0: End of Technical Guidance 2025-06-30; last patch 9.0.0 P46 shipped 2025-06-18
• Zimbra 8.8.15 (LTS): End of Technical Guidance 2024-12-31

What the vulnerability actually is

CVE-2026-73570 is an OS command injection in Zimbra’s SNMP monitoring component. Per the NVD record, it affects Zimbra Collaboration “before 10.1.20” when the optional zimbra-snmp package is installed and SNMP notifications are enabled: untrusted input is not sanitized during notification processing, so an unauthenticated attacker can send specially crafted SMTP requests that end up executing arbitrary operating-system commands as the zimbra user. NVD scores it CVSS 3.1 8.9, High. Because the trigger is ordinary mail traffic arriving at a mail server, the usual “it’s not exposed” reassurance does not apply — a Zimbra server’s job is to accept SMTP from strangers.

Zimbra shipped the fix in 10.1.20 on July 20, 2026, describing it as “a permanent fix for the critical SNMP vulnerability.” CERT Polska reported an active exploitation campaign on August 17 — 28 days later. CISA added the CVE to the Known Exploited Vulnerabilities catalog on August 21, the only addition that day, with a remediation deadline of August 24 under BOD 26-04. Shadowserver’s scans, as reported by Security Affairs, count more than 12,100 Zimbra servers reachable from the internet, roughly 4,500 of them in Asia and 4,400 in Europe.

One fix, one version — and three lines that get nothing

Zimbra’s own security advisory table lists a single fixed release for CVE-2026-73570: 10.1.20. There is no 10.0.x patch, no 9.0.0 patch level, no 8.8.15 patch. That is consistent with where the three older lines sit on Zimbra’s release index:

A sourcing note we want on the record, because it is the kind of thing that gets flattened in the retelling: no advisory enumerates 8.8.15, 9.0 or 10.0 as confirmed vulnerable. NVD’s affected range (“before 10.1.20”) technically sweeps them in, and the code in question predates 10.1, but the flaw only reaches a server with the optional SNMP package installed and notifications enabled. The claim we are prepared to stand behind is narrower and, for an operator, just as decisive: no fix exists for those lines, and the vendor has told you they are past support.

The backport window closed one line at a time, and nobody announced it

This is the part that makes Zimbra a case study rather than a news item. Read Zimbra’s patch-release posts in order and you can watch the backports stop:

Three things stand out. First, 9.0 was still receiving security patches until June 2025 — five years after GA and right up to its End of Technical Guidance date, which is better than most vendors manage. Second, 10.0 kept getting patches for four months after its own published end of support. An operator who noticed 10.0.16 and 10.0.18 arriving after June 30, 2025 could reasonably have concluded the date was soft and the backports would keep coming. Third, they then stopped without a post, a notice, or a changed date on the release index. The advisory table for 2026 tells the whole story: sixteen CVE-2026 entries, fifteen of them fixed in 10.1.x only, and the one exception — a CSRF fix credited to 10.1.13 and 10.0.18 — is the November 2025 release that turned out to be 10.0’s last.

That is precisely the pattern our Backport Myth research documented across 624 candidate CVE-and-EOL-version pairs the day before this CVE hit KEV: vendors do backport past end of life — often, quietly, and for a while — and the backport ends not with an announcement but with the first serious bug that does not get one. The exploited bug is the announcement. For Zimbra 10.0 that moment was July 20, 2026; for 9.0 it had already passed a year earlier.

Zimbra is a KEV regular

CVE-2026-73570 is the nineteenth Zimbra Collaboration Suite entry in CISA’s catalog since the first was added in January 2022, and the fifth in 2026 alone (January 22, February 17, March 18, April 20, August 21). Five of the nineteen carry CISA’s “known ransomware campaign use” flag, all from the 2022 wave of mass exploitation. Put differently: a Zimbra server on a line that no longer receives fixes is not waiting for a hypothetical. It is on a product that attackers return to several times a year, and the next entry will also be fixed in 10.1.x only.

What to do this week

1. Find your Zimbra versions. As the zimbra user, zmcontrol -v prints the exact release and patch level. Anything that is not 10.1.20 or later has no fix for an actively exploited unauthenticated RCE.

2. Check whether the vulnerable component is even present. dpkg -l zimbra-snmp (or rpm -q zimbra-snmp) tells you whether the optional package is installed, and your install-time configuration records whether SNMP notifications were enabled (the installer’s SNMP notifications / trap-host prompt). If the package is absent, the documented trigger is absent. This is a stopgap you verify, not a patch you trust.

3. On 10.1.x: upgrade to 10.1.20 now. That is the entire federal remediation action, due August 24.

4. On 10.0, 9.0 or 8.8.15: the upgrade to 10.1 is the fix. There is no patch coming for these lines — the vendor’s release index and a year of advisory history both say so. If the upgrade cannot happen this week, removing or disabling the SNMP component removes the documented trigger for this CVE, but leaves you exposed to every other 2026 fix these lines did not receive. If you need a paid bridge while you migrate, use the form above — we will tell you plainly whether any independent vendor covers Zimbra.

5. Assume compromise on any internet-facing server that sat unpatched after August 17. CISA’s KEV entry carries forensics-triage requirements for a reason: the campaign was running for days before the catalog entry. Review the zimbra user’s shell history, cron entries and outbound connections, and rotate any credentials a command running as zimbra could reach — that includes the LDAP and MySQL passwords in localconfig.xml.

Frequently asked questions