SURIQ
The most important line in the new NSA and CISA advisory on Zimbra is not the version you patch to. It is that a password reset does not clean up after this attack. The malware that Russian operators dropped through CVE-2025-66376 creates its own application passwords inside the victim's mailbox, and those keep working after the account owner changes their password and after the flaw is patched. If you run Zimbra and you only bump the version, you have stopped the next crafted email. You have not evicted the last one.
The bug lives in the Classic web client of Zimbra Collaboration, a stored cross-site scripting hole. Zimbra closed it on November 6, 2025 in builds 10.0.18 and 10.1.13, so any earlier release on the 10.0 or 10.1 branch is exposed. Reading a message was enough to trigger it. The crafted email buries script in markup the sanitizer waves through, leaning on how the Classic client handles CSS @import to fire JavaScript in the logged-in session. No link to click, no attachment to open.
A zero-day that ran for months before the patch
According to the joint advisory, exploitation started no later than July 2025 and continued as a zero-day until the November fix. Proofpoint's telemetry puts the campaign running from July 2025 into February 2026, which means it kept working against every Zimbra server that had not applied the update. CISA added the flaw to its Known Exploited Vulnerabilities catalog on March 18, 2026, and the coordinated NSA and CISA writeup landed this month with the full technical breakdown.
The gap is the point. This was a nation-state zero-day for roughly four months, then it stayed useful against unpatched servers for months more. Anyone who triaged Zimbra patches by severity score would have been slow to it. NVD scored CVE-2025-66376 a 6.1, a medium, because its model assumes the victim has to view the message. MITRE scored the same flaw 7.2 and treated the view as not requiring meaningful interaction. Palo Alto's Unit 42 described it flatly as zero-click. The lesson for anyone building a patch queue: the base score was the wrong signal here. Exploitation status was the right one, and it takes a human reading the advisory to catch that, not a CVSS threshold.
The Classic web client keeps failing the same way
This is the second code-execution flaw in Zimbra's Classic web client we have written about in a matter of weeks. Earlier this month we flagged a separate stored XSS in the Classic UI that Zimbra fixed in 10.1.19 after Google's Threat Analysis Group reported it, with no public exploitation at the time. CVE-2025-66376 is a different bug, but the shape is identical: a crafted email defeats the Classic client's HTML sanitizer and runs script in the session. Two independent sanitizer bypasses in the same component, months apart, is a pattern. The durable fix is not the next point release. It is moving mailboxes off the Classic web client to the modern interface, which does not carry the same sanitizer surface. Patch now, then plan the migration, because a third bug of this class is a question of when.
What the payload took, and why it stays
The malware, which the advisory calls ZimReaper, runs entirely inside the browser session once the message renders. Once running, it grabs the past 90 days of stored messages, the whole company address book, any credential the browser had saved, the account's two-factor recovery codes, anti-forgery (CSRF) tokens, and which Zimbra build is in use. Then it does the part that outlives the cleanup: it uses Zimbra's own account API to mint application passwords under the label ZimbraWeb. Those hand over mailbox access by IMAP, POP3, and SMTP with no second factor required.
That last step is why remediation is not a version bump. App-specific passwords are a legitimate feature for legacy mail clients, and they are not invalidated when the user resets their login password or rotates their 2FA seed. An operator who patches to 10.1.13, forces a password reset, and calls it done has left the attacker a working key. Exfiltration used the group's collection tooling, which the advisory tracks as Flowerbed, over two channels: it tucks small amounts of stolen data inside DNS lookups and ships whole mailbox archives out over HTTPS. The DNS path is worth knowing, because it slips past controls that only watch web proxies.
Who ran it
Attribution in the advisory is deliberately hedged, and you should quote it that way. The activity is tracked as Laundry Bear and, by Microsoft, as Void Blizzard, with Palo Alto's CL-STA-1114 and Proofpoint's TA488 also named as overlapping designations. The advisory notes the mapping between these labels may not be one to one. Dutch intelligence agencies publicly named Laundry Bear in May 2025, after tying it to a 2024 breach of the national police force in the Netherlands. Reported targets across the campaign sit in government, defense, transportation, and finance across NATO members, Ukraine, and adjacent regions. The through-line with the group's other operations is that it goes for durable, recovery-grade access rather than a single session: the same instinct we saw when Russian operators phished Signal users for the backup recovery key, and in Turla's backdoor built for redundancy. Steal the thing that a reset cannot revoke, and you keep the access.
Rotate every key the mailbox touched
Patching to 10.1.13, or moving 10.0 servers onto a supported 10.1 build, stops new exploitation. Cleanup is a separate job, and it is where most of the risk sits now. For any mailbox that could have been exposed during the window:
- Reset the account password and invalidate active sessions, then regenerate the 2FA recovery codes. The old ones were in scope.
- In the account audit log, hunt
CreateAppSpecificPasswordevents and remove every credential carrying theZimbraWeblabel. This is the persistence mechanism, and the single highest-value thing to look for. - Flag accounts where
zimbraPrefImapEnabledis set toTRUEwithout a business reason, since the app passwords exist to enable exactly that access path. - Alert on
GetScratchCodesRequestSOAP calls, which is how the payload harvested recovery codes. - Filter DNS for the advisory's published command-and-control domains, and watch outbound DNS volume, not just web traffic, given the DNS exfiltration channel.
Treat the patch as the easy half. The harder half is assuming that any Zimbra server exposed between July and November 2025 already handed over its mail and a set of standing credentials, and working backward from there.