Webmail sanitizers are supposed to be the boring, solved part of email security: strip the scripts, neutralize the tags, let the message through clean. A five month espionage campaign disclosed this week shows that assumption is no longer safe to make. A Russia aligned threat actor tracked as TA488, also known as Void Blizzard and Laundry Bear, exploited a previously unknown flaw in Zimbra Collaboration Suite’s HTML sanitizer to read a target’s inbox, harvest their two factor recovery codes, and pull their organization’s entire address book, all triggered by a message the victim never had to click.
What TA488 Actually Did
According to research from Proofpoint, the exploitation ran from at least July 2025 through February 2026, months before the flaw, tracked as CVE-2025-66376, was patched or publicly disclosed. TA488 built what Proofpoint calls “half-click” phishing emails: messages that only need to be opened or previewed, not clicked, for the exploit to fire. Targets spanned Ukrainian government entities alongside United States government agencies, nuclear facility operators, defense industrial base companies, and research institutions in high science fields.
Once triggered, the payload extracted the victim’s last 90 days of email, the organization’s Global Address List, browser autosaved passwords, CSRF tokens, and any two factor authentication recovery codes stored in the account. TA488 then created its own application specific password, labeled “ZimbraWeb” in Zimbra’s audit log, giving the group a persistent, low visibility way back into the mailbox that survives a normal password reset.
The Mechanism: How the Sanitizer Was Beaten
The flaw lived in how Zimbra’s Classic Web Client parsed HTML email. Proofpoint’s analysis describes attackers splitting a malicious SVG tag across fake CSS @import directives and HTML comments, so that no single fragment of the message looked dangerous to the sanitizer. The victim’s browser, however, reassembled the fragments into a working tag once it rendered the page, and the embedded script executed in the context of the logged in mailbox. Proofpoint assesses that the technique likely originated with Russian state intelligence and was passed to TA488 rather than developed independently by the group, based on the sophistication of the tag splitting method relative to the actor’s typical tradecraft.
Starting around October 2025, TA488 added XOR obfuscation to the payload, a sign the operators were actively iterating to stay ahead of detection as defenders began to notice earlier variants.
Who Else Was in Scope
The joint advisory describes a target set broader than the defense and nuclear sector organizations named in the Proofpoint research: government, energy, technology, education, media, law enforcement, and non governmental organizations across the United States and allied countries, consistent with an intelligence collection mandate rather than a narrowly scoped operation. That breadth is itself a signal. A campaign built around a single sanitizer flaw in a widely deployed, self hosted webmail platform scales to any sector running the affected software, regardless of whether that organization has any obvious intelligence value on its own. Downstream access to a partner’s or vendor’s mailbox is often the actual objective.
Why This Keeps Happening
This is not Zimbra’s first sanitizer failure this year. CyberTech reported in June on a separate critical stored XSS in the Classic Web Client, patched before it reached the kind of sustained exploitation seen here. Webmail HTML rendering keeps drawing state actors for a straightforward reason: a mailbox is a preauthenticated foothold. No credential phishing page, no malware download, no user decision beyond opening a message that looks like routine correspondence. For platforms like Zimbra, Roundcube, and other self hosted webmail clients that render rich HTML by design, the sanitizer is not a peripheral control. It is the entire perimeter.
What It Means for the Security Leader
The joint advisory from the NSA and CISA (AA26-204A), issued alongside the Proofpoint and Unit 42 research, puts this campaign in the same bracket as other Russian state operations against Western critical infrastructure and defense targets: patient, low noise, and aimed at long term intelligence collection rather than immediate disruption. For a CISO, the operational lesson is narrower than “patch Zimbra.” A five month exploitation window on a zero day means detection had to come from behavior, not signatures. The application specific password TA488 created is the kind of artifact that a mature identity monitoring program catches and a default configuration does not log prominently.
Organizations running self hosted or on premises webmail should treat it as a Tier 1 identity system for logging and alerting purposes, not as commodity infrastructure. That means audit logging on credential and token creation events, not just login events, and a defined response path when an unexpected app specific credential appears.
What Defenders Should Do Now
- Patch to Zimbra Collaboration 10.0.18 or 10.1.13 or later immediately if not already applied.
- Search Zimbra’s
/opt/zimbra/log/audit.logforCreateAppSpecificPasswordevents, and revoke any credential named “ZimbraWeb” or otherwise unrecognized. - For any account with signs of compromise, reset the password, invalidate all active sessions, and regenerate two factor recovery codes rather than assuming a password reset alone is sufficient.
- Deploy the detection signatures Proofpoint published for this campaign and review inbound mail for the tag splitting pattern (fragmented SVG content spread across fake CSS import directives and HTML comments) even after patching, since the technique itself is reusable against other sanitizers.
- Treat webmail platforms as identity infrastructure: extend privileged access monitoring and anomaly detection to mailbox and token creation events, not just authentication events.
Source: Proofpoint
