Zimbra's CVE ID came 24 days after the patch. Microsoft's earliest dated probing is day 8

Day 0, day 8, day 24, day 32, day 72

Zimbra released version 10.1.20 on 20 July 2026. Microsoft's analysis says its telemetry saw probing of the same flaw from 28 July, which is day 8. The CVE record was not published until 13 August, day 24. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalogue on 21 August, day 32, and gave federal agencies three days. Microsoft published its analysis on 30 September, day 72. Every day count in this briefing is in calendar days from the 20 July release, and we derived each one.

What that does not establish. The dates do not say when the first server was compromised: Microsoft dates the probing, not the first web shell. They give no count of victims, because Microsoft gives none. They name no actor, because Microsoft names none. They do not say that any mailbox was read, only that mailbox data was accessed and that one attempted upload is not confirmed to have completed. And they say nothing about how many servers were upgraded after they had already been entered, which is the question that matters most to anyone who runs Zimbra.

The practical reading is narrower. A vulnerability process that started on the CVE ID started 24 days after the fix existed. One that waited for the KEV listing started after 32 days. Both are later than the day Microsoft's probing data begins. Briefing 114 found the same shape at Roundcube, a release note with no CVE, no severity and no score, with the exploited flaw on line three. Briefing 165 found a fix with no CVE, score or version at Kiteworks. Briefing 174 sets out CISA's rule that a three-day patch clock can carry a compromise check with it, which applies here too.

The timeline, with the arithmetic shown

Each date below comes from a page we read in full, and the last column says how firm it is. Times are UTC where a source gives one. The diagram draws the same dates to scale, with a zoom on the crowded fortnight in August.

Dated events, 26 June to 30 September 2026, with the standing of each. Secondary and community sources are marked.

Date (2026)	What happened	How firm it is
26 Jun	Zimbra says it published a security advisory on the SNMP flaw.	Zimbra's own 20 July blog, one line. The advisory itself was not found on the Zimbra pages read, so its content is unknown.
30 Jun	A public Zimbra community forum thread discusses the cause and a workaround. A community build notes an SNMP mitigation on 1 July.	Third-party forum, read in full. It shows public discussion, not what Zimbra said.
20 Jul	Zimbra 10.1.20 released. Its release notes list nine security fixes, the SNMP one first, with no CVE ID and no score.	Zimbra release notes and blog. Primary.
28 Jul to 7 Aug	Microsoft sees two scanning tools probing the injection point, confirming command execution without delivering a payload.	Microsoft, primary for its own telemetry. The earliest dated attacker activity in any source we read.
7 Aug	A public forum thread, dated that day, has administrators posting log lines of attempts. One says an attempt retrieved a configuration file.	Users' own claims, unverified. Not linked here because the thread quotes attack strings.
12 Aug, 21:44	CVE ID reserved.	CVE record. Primary.
13 Aug, 15:19	CVE record published by MITRE as the assigning CVE Numbering Authority. NVD lists it an hour later.	CVE record and NVD. Primary.
17 Aug	CERT Polska bulletin 145/2026 says the flaw is actively exploited.	Primary. Polish text, our translation.
20 Aug	Shadowserver's first count of Zimbra servers with artifacts of probable compromise: 155.	Shadowserver public dashboard, read 30 September. Help Net Security reports the same figure.
21 Aug	CISA adds the flaw to KEV, due 24 August, with forensic triage required.	KEV feed and CISA alert. Primary.
22 Aug	Shadowserver's count peaks at 274, with 41 in the United States.	Shadowserver's post of 24 August and its dashboard. Primary.
24 Sep	Zimbra 10.1.21 released.	Zimbra release notes. Primary.
30 Sep	Microsoft publishes its analysis at 14:00 UTC, revised at 16:07 UTC.	Microsoft's page metadata. Primary.

The arithmetic. Calendar days, derived by us from the dates above.

Interval	Days	What it measures
Zimbra's advisory, 26 Jun, to the 10.1.20 release, 20 Jul	24	Zimbra's stated advisory to its fix.
Release to first probing Microsoft dates, 28 Jul	8	The fix existed and probing had begun.
Release to CVE ID reserved, 12 Aug	23	Time before anyone asked for an ID.
Release to CVE record, 13 Aug	24	How long the fix existed with no CVE ID.
Release to CERT Polska bulletin, 17 Aug	28	Time to the first public warning of exploitation.
Release to KEV listing, 21 Aug	32	How long the fix existed before the list many programmes key on.
Release to KEV due date, 24 Aug	35	The end of the federal clock.
First probing to CVE record	16	Probing before any ID existed.
First probing to KEV listing	24	Probing before any official exploitation listing.
KEV listing to Microsoft's analysis	40	Time to the most detailed public account.
Release to Microsoft's analysis	72	The full span.
KEV due date to latest Shadowserver reading, 29 Sep	36	Servers still tagged after the federal deadline.

"Public disclosure" needs care. Microsoft writes that the flaw "was publicly disclosed on August 13, 2026". That is the date of the CVE record. Zimbra's own blog says it disclosed the vulnerability in an advisory on 26 June, and a public forum thread was discussing the cause and a workaround by 30 June, 44 days before the CVE record. We could not retrieve Zimbra's 26 June advisory, so we cannot say what it told administrators. Zimbra calls the 20 July release a "permanent fix", which suggests an earlier interim one; that is our inference. What is solid is narrower: a reader who dates exposure from the CVE record is using the latest of the public dates, not the earliest.

The score: who set 8.9, and what moves it

The 8.9 in the coverage is a CVSS 3.1 base score. In the CVE record it sits in the container of the CVE Numbering Authority, which is MITRE: the record's assigner is "mitre", the ID was reserved on 12 August, and the record's generator field names a CVE request form. Who filed the request is not stated. NVD lists the score as a secondary score from MITRE and has added none of its own. Zimbra's advisory table shows CVSS as "TBD" and the Zimbra rating as a dash for this entry on 30 September, and credits no reporter, where other rows in the same table name one. So the number was set neither by the vendor nor by NVD.

Labels on one flaw, as found on 30 September 2026. Each row says what the label is and what it leaves out.

Source	Label	What it does not tell you
CVE record and NVD, set by MITRE	CVSS 3.1 base 8.9, High. Network, no privileges, no user interaction, scope changed, attack complexity high.	That exploitation is hard in practice. Microsoft saw probing 8 days after the fix.
Zimbra advisory table	CVSS: TBD. Zimbra rating: a dash. Fix release: 10.1.20.	Any vendor severity in the table. No reporter is credited.
Zimbra blog, 20 July	Patch Security Severity: High. Deployment Risk: Low. The text calls it a critical vulnerability.	Why the word critical appears when the score is below 9.0.
CISA KEV	Added 21 Aug, due 24 Aug, forensic triage: yes, known ransomware use: unknown.	Who is exploiting it, or how many servers.
CISA ADP record, 22 Aug	Exploitation: active. Automatable: no. Technical impact: total.	Microsoft describes automated payload delivery in observed cases. The labels answer different questions, and neither is a count.

We recomputed the base score from the published vector with the CVSS 3.1 equations: exploitability 2.2, impact 6.0, base 8.9, which match NVD's own sub-scores. Changing one metric, attack complexity from high to low, with everything else unchanged, gives 10.0. That is our arithmetic and it is not a claim that the vector is wrong. The record does not say why the authority chose high. Our inference is that the two conditions for exposure, an optional package and a non-default setting, are the reason, and Shadowserver's own note that its unpatched count "does not mean exploitable" points the same way. If so, "High, 8.9" carries a judgement about how many servers are exposed, not a finding that the flaw is hard to use. heise made a related point on 21 August, that 8.9 narrowly misses critical.

Which versions are fixed, and which are not addressed

On the record, Zimbra 10.1.20, released 20 July 2026, fixes it. NVD and the CVE record say Zimbra Collaboration is affected before 10.1.20, and Zimbra's advisory table lists 10.1.20 as the only fix release for this entry. The release note is one line: "Fixed a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled." It does not say unauthenticated, email or remote. Zimbra's note on the page explains why: "In line with industry best practices, information disclosure is limited for security vulnerability fixes."

Three limits apply.

• Later releases. 10.1.21 came out on 24 September, and its release notes list twelve security fixes, including one for an unauthenticated weakness in self-service password recovery and two in the OnlyOffice integration. Microsoft's advice is "10.1.20 or later". A server stopped at 10.1.20 is missing these.
• Older branches. The newest 10.0.x release on Zimbra's Security Center is 10.0.18 (6 November 2025) and the newest 9.0.0 patch is Patch 46 (18 June 2025). Neither line has a fix listed for this flaw, and no page we read says whether those lines contain the vulnerable code or are still supported. NVD's range, read literally, includes them. A forum poster whose signature shows 10.0.5 reported attempts; attempts in a log are not evidence of a vulnerable server.
• Conditions. CERT Polska says instances are affected when SNMP trap notifications are enabled through the snmp_notify parameter and the swatchdog service is running, which is the default. The zimbra-snmp package is optional. Shadowserver's 24 August post counted at least 8,200 unpatched instances and added that this does not mean exploitable, because the flaw needs a non-default configuration. Its dashboard showed 4,149 on 29 September.

What Microsoft states, and what it does not

Microsoft's post is long and specific, and it is careful about its own limits. It says the activity covers several confirmed compromises and that no single host necessarily showed every stage. The coverage is less careful than the post.

What Microsoft states in its 30 September 2026 post, and what it leaves out.

Topic	Stated by Microsoft	Not stated
Timing	Activity targeting the same injection path between the 20 July fix and the 13 August disclosure. Two scanning tools probing from 28 July to 7 August, confirming command execution with no payload.	A date for the first web shell, credential theft or mailbox archive. Whether anything happened before 20 July. Microsoft notes its 30-day hunting window does not cover the early activity.
Victims	Affected organisations in more than one region and industry. Several confirmed compromises.	How many organisations or servers, which regions or industries, and whether any are in the UK.
Actor	Automated payload delivery and hands-on-keyboard activity. Several tool families: a remote-access agent, a credential dumper, a cryptominer.	Any named actor, any state or criminal attribution, or whether one operator or several are involved.
Mail	Attackers accessed email and collected mailbox data. On one server, recent mailbox backup content was archived and an upload to cloud storage was attempted.	That any message was read, how many mailboxes, or that any archive left the network. Microsoft says the evidence does not confirm the upload completed.
Secrets	Service credentials for LDAP, MySQL, Postfix, Amavis and replication. The pre-authentication key, the session-token signing key and the two-factor secret attribute. TLS certificate and key files staged.	Which servers lost which secrets, and whether any stolen secret was used afterwards.
Patched servers	The fix existed before the activity it describes. "Do not assume that removing one known JSP eliminates access."	How many victims were later upgraded and would now pass a version check, and how many were rebuilt.
Detection	A detector built for this pattern "recognized every confirmed exploitation event" in evaluation mode.	A false-negative rate, or any view of servers without Microsoft sensors. It is a vendor statement about its own product.

What "harvest authentication secrets" covers. The Hacker News headline compresses a specific list. Microsoft says the actor went for Zimbra's centralised service and authentication secrets, not individual mailbox passwords. The post lists the service accounts' credentials and then three directory attributes: the pre-authentication key, the key Zimbra uses to sign session tokens, and the two-factor secret attribute. Microsoft's own description of the last two keys is the serious part: the token key lets an attacker generate session tokens for any account without a password, and the pre-authentication key lets them build pre-authenticated login URLs for any account. What the post does not say is which servers lost which of these, or whether any was used afterwards.

Where the coverage reads more than the post says. The Hacker News writes that the attack activity Microsoft documented was identified "during the interval" between 20 July and 13 August. Microsoft's sentence is about "activity targeting the same injection path", and the only part of the activity it dates is the probing. The web shells, the sudo change, the credential collection and the mailbox archive are not dated in the post, and some of it may have come after 13 August, when the CVE record existed. We cannot tell from the page.

Commercial interest. The post describes its evidence as Defender and endpoint detection telemetry, and its protection section describes Microsoft's own products, including Defender detections and Security Copilot prompts. That does not make the findings wrong. It does mean the population is hosts that report to Microsoft, not Zimbra servers in general, and the statement that its detector caught every event it saw is a statement about the events it saw.

The one victim number that exists, and what it counts

Microsoft gives no count. The only published count is from the Shadowserver Foundation, a non-profit that scans the internet, working with CERT Polska. The Hacker News article of 30 September leaves it out; its August article carries it. We read the dashboard through a browser on 30 September, and its numbers match Shadowserver's own post of 24 August: 274 instances seen compromised on 22 August, 41 of them in the United States. The reports carry the detail "Artifact from probable CVE-2026-73570 compromise".

Shadowserver's zimbra-compromised tag, counted IP addresses, read from its public dashboard on 30 September 2026. Percentage changes are ours.

Country	24 Aug	29 Sep	Change
All countries	267	117	down 56%
United States	46	12	down 74%
Sweden	21	17	down 19%
France	20	8	down 60%
Germany	17	5	down 71%
United Kingdom	11	4	down 64%

This count is not a count of victims. It counts IP addresses, not organisations, and not mailboxes. It counts artifacts visible to Shadowserver's scans, so a server that was entered and then cleaned of visible artifacts drops out, and so does one whose shells cannot be reached from outside. The series starts at 155 on 20 August, not at zero, which fits a detection that began then (our inference), so it cannot date when compromise began. And the fall from 274 to 117 does not show that 157 servers were properly cleaned: artifacts removed, servers taken offline and changes of address draw the same line. Sweden is the stubborn row, 21 on 24 August and 17 on 29 September while the United States fell from 46 to 12. The sources do not say why.

What the record says about the UK, and only that. Shadowserver's dashboard shows 7 UK addresses tagged on 20 August, a peak of 12 on 22 and 23 August, 11 on 24 August and 4 on 29 September. Separately, it flags 80 UK addresses as possibly unpatched on 20 August and 40 on 29 September; that flag is version-based and, in Shadowserver's words, does not mean exploitable. Microsoft does not mention the UK. We found no NCSC publication on this flaw in a web search and in a search of the NCSC site on 30 September, which is not proof that none exists. The Canadian Centre for Cyber Security issued advisory AV26-816 on 14 August and updated it on 21 August.

"Now-patched" is a date, not a state

The Hacker News opens with "now-patched". It is a true label for the flaw and a misleading one for any server that could be reached before it was upgraded. A version check says whether the injection path is closed. It does not say whether someone used it first.

CISA treats this as a compromise-check problem, not only a patching one. The KEV entry for this flaw carries the forensic-triage flag. Under BOD 26-04 that means a federal agency must remediate within three days and also carry out a forensic triage to assess whether the system is compromised. CISA's implementation guidance orders the work: collect evidence before patching where possible, because patching may jeopardise the artifacts. Briefing 174 sets out the argument in more detail.

The Zimbra case adds a twist from Microsoft's own list. Memory-backed execution, through an anonymous in-memory file, is among the techniques observed, and memory does not survive a restart. Our inference, not Microsoft's: a server that is upgraded and restarted loses that evidence, which is a reason to collect first.

Three more labels deserve the same suspicion. "Optional package" suggests a small exposure; the real question is whether the package is on your servers, and nodes in one cluster can differ. "Non-default configuration" can be read as "not exploitable", when it means "check". And "restrict SMTP access to trusted hosts", on Microsoft's list of interim mitigations, cannot be done on a server that must receive mail from the internet. The two practical stopgaps on that list are removing the package or disabling the notifications. Blocking SNMP ports alone does not match the path CERT Polska and Microsoft describe, which arrives through email and is processed by the log-watching service; that is our reading of their descriptions.

What to hunt and harden, at defender level

Microsoft and CERT Polska publish the specific paths, log patterns and queries. This briefing does not repeat crafted requests or payloads; use their pages for specifics. The order below puts evidence before the upgrade and the decision about the server last.

What we could not verify

The question this leaves

The fix was on Zimbra's own pages on 20 July. The things most vulnerability programmes key on, a CVE ID, a score and a KEV listing, arrived on days 24 and 32, and Microsoft's probing data begins on day 8. The vendor's one-line note and its "information disclosure is limited" policy explain a good part of that gap, and they put the work of noticing on the customer.

So the question for your own process: if a Zimbra server of yours was reachable from the internet on 28 July, on an earlier version with SNMP notifications enabled, what evidence do you hold today that nobody ran a command on it, other than the fact that it now runs a fixed version?

Key facts