The Email Only Had to Render
A joint government advisory says Laundry Bear used a view-based Zimbra exploit to collect mail, directory data, and authentication material—then create a path back into the account.
The malicious message did not need to win an argument. It did not need a recipient to follow a link or open an attachment.
A joint cybersecurity advisory says the Russian state-supported group known as Laundry Bear used CVE-2025-66376 against vulnerable Zimbra Collaboration Suite webmail. The exploit ran when a target viewed a crafted email in the Classic UI.
The email client did not merely display the lure. It became the execution and collection surface.
The agencies place the Zimbra campaign in operation by July 2025. A patch followed in November; the July 2026 advisory warns that unpatched systems remain exploitable.
The View Was the Trigger
The advisory uses the careful term view-based. Some reporting calls the technique zero-click; “half-click” is another useful shorthand. The distinction is that the recipient still has to view or preview the message, but does not have to take the action most phishing controls are built to catch.
Once the vulnerable Classic UI rendered the message, embedded JavaScript could execute inside the authenticated webmail session. The vulnerability was a zero-day when Laundry Bear first used it. Zimbra patched it in November 2025, but the agencies say the exploit continues to work against systems that remain unpatched.
That changes the detection boundary. Link inspection, attachment detonation, and user-reported clicks can all be quiet while the browser session is already making account requests.
The NSA release says the campaign has targeted Zimbra users across U.S. and allied government and commercial networks since at least July 2025. The joint advisory lists compromised users in defense, government, education, energy, law enforcement, media, non-governmental, and technology organizations.
Mail Was Only One Collection Target
The payload attempted to collect the previous 90 days of a victim’s email. It also reached for the user’s email address, a password exposed through browser autocomplete, the organization’s Global Address List, two-factor authentication scratch codes, and a newly created application passcode.
That is more than mailbox theft. The directory maps people and relationships. Mail supplies current projects, attachments, decisions, and conversation history. Authentication material can extend access after the original browser session ends.
The 90-day mailbox window is a collection objective, not a verified loss count for every target. The public advisory describes what the capability attempts and confirms that users at multiple organizations were compromised; it does not publish a victim-by-victim inventory of every data class successfully removed.
Viewing the message in a vulnerable Classic UI could move the operation directly into an authenticated session. The payload then attempted account collection and sent data through DNS and HTTPS.
Persistence Used a Supported Feature
The campaign’s most important account change was not exotic malware on the mail server. The script attempted to enable IMAP and create a Zimbra application passcode named ZimbraWeb.
Application passcodes exist for clients that cannot complete the normal two-factor flow. In this campaign, that legitimate compatibility path became a persistence mechanism: an attacker-controlled passcode could support later mailbox access through a legacy mail protocol.
A password reset by itself may therefore leave the wrong credential alive. The response has to examine the account’s current state—application passcodes, 2FA scratch keys, IMAP enablement, and mailbox access—not just the password a person remembers.
The advisory identifies concrete artifacts. Zimbra records relevant SOAP activity in mailbox.log; suspicious patterns include bursts of directory searches, requests to create an application-specific password, and requests for 2FA scratch codes. The payload also wrote date-shaped markers into browser localStorage as it worked through mailbox days.
The account and browser retain useful evidence: SOAP request patterns, the ZimbraWeb passcode name, 2FA-code access, and date markers associated with mailbox collection.
DNS and HTTPS Told Different Parts of the Story
Laundry Bear’s Ulej capability used two outbound paths. Smaller values—including environment and authentication data—could be encoded into DNS queries. Larger material, including email content, contacts, and attachments, moved over HTTPS to the actor-controlled Flowerbed collection framework.
That split matters during scoping. A DNS-only hunt can find small collection events and miss the mailbox archive. An HTTPS-volume alert can find bulk transfer and miss the account material that made persistence possible.
The agencies recommend retaining network and log evidence and watching for frequent DNS queries with seemingly random subdomains, sudden connections to recently established domains, unusual outbound transfers to virtual private server providers, and suspicious access to webmail from VPN infrastructure.
Indicators in the advisory are useful pivots, but they are historical. The report explicitly warns that infrastructure changes quickly. Behavioral evidence—message rendering followed by unusual account API calls, new passcodes, mailbox searches, and outbound transfer—has a longer shelf life.
Patch the Server, Then Hunt the Account
The first action is direct: make sure Zimbra is on a non-vulnerable release. The advisory says fixes were released in ZCS 10.1.13 and 10.0.18. Where immediate patching is not possible, it recommends moving users away from the Classic web client until the system is updated.
Patching closes the rendering flaw. It does not revoke persistence already created or recover mail already exfiltrated.
A complete response has five linked moves:
Find the message and its viewers. Use the published indicators and payload characteristics to identify recipients, then quarantine matching messages across the environment.
Hunt the account changes. Review mailbox.log, application passcodes, IMAP enablement, 2FA scratch-code access, browser localStorage markers, and suspicious mailbox activity.
Close every authentication path. Remove unauthorized application passcodes, revoke 2FA scratch keys, and require new unique credentials.
Join host, identity, and network time. Correlate message-view timing with SOAP requests, DNS behavior, HTTPS transfer, and later mailbox access.
Scope the content loss. Record the dates associated with each affected account and determine which mailbox days, contacts, and attachments could have left the environment.
The patch removes the vulnerable render path. Account revocation, artifact hunting, and exfiltration scoping close what may already have happened.
Email Security Has a Render Boundary
This campaign compressed phishing, exploitation, collection, and persistence into the act of viewing a message.
User awareness still matters, but “do not click” was not a sufficient control. The vulnerable renderer, authenticated account APIs, legacy mail access, browser state, and outbound network all belonged to the same incident surface.
When rendering can execute inside a trusted session, the detection chain has to start before the click and continue after the patch.