Executive summary
The UK's National Cyber Security Centre (NCSC) and international partners warned on 23 July 2026 of a Zimbra Collaboration Suite (ZCS) campaign they attribute to LAUNDRY BEAR and assess as almost certainly supported by the Russian state. The joint advisory describes exploitation of CVE-2025-66376 when a user views a malicious email in vulnerable webmail, followed by attempted collection of messages, credentials and authentication material. It warns of persistent access through application passcodes even after the original email has been viewed. We assess it is likely (B2) that patching alone will leave unresolved account exposure where exploitation occurred, because the reported payload can create another means of mailbox access and collect reusable authentication information.
Context and the observation window
The NCSC announcement says the group has targeted Zimbra users since July 2025, including organisations in government, defence, education, energy and other sectors. The joint technical advisory calls the capability Ulej, or beehive, and says the vulnerability was patched in November 2025. This is a new public account of a longer-running campaign, not a newly patched July 2026 vulnerability.
Proofpoint's report published on 23 July 2026 describes its TA488 investigation and the JavaScript payload it calls ZimReaper. Proofpoint says its direct telemetry alone did not support high-confidence attribution to Void Blizzard, also known as Laundry Bear, but that collaboration with US government partners confirmed the association. The joint advisory separately cautions that industry tracking labels need not correspond one-to-one across all activity. We use each publisher's names within that stated scope.
There is also a material visibility difference. The joint advisory warns of continuing successful exploitation, while Proofpoint says it had observed no TA488 activity since February 2026. Those statements should remain separate. Proofpoint's observation limit does not establish that the wider campaign ended, and the joint warning does not imply that Proofpoint saw a new July 2026 attack.
Technical analysis
Viewing the message triggers the vulnerable client
Proofpoint describes a stored cross-site scripting (XSS) issue in the webmail client's handling of HTML email. The malicious message exploits inadequate sanitisation of Cascading Style Sheets (CSS) import directives, allowing JavaScript to execute in the authenticated webmail context. Opening or previewing the message is sufficient in a vulnerable client; the user need not follow a link or open an attachment.
This is why the NCSC's “zero-click” description should be explained precisely. Viewing remains the trigger described by the sources. We recommend retaining that detail in user communication so the response does not focus solely on whether someone clicked a phishing link.
The historical CISA Known Exploited Vulnerabilities (KEV) catalogue identifies the Classic user interface and records addition on 18 March 2026. Its known ransomware-use field is Unknown. That field neither establishes ransomware involvement nor proves its absence; the joint advisory's assessment of this particular campaign is espionage.
The authenticated browser supplies access
The joint advisory describes the payload seeking a cross-site request forgery (CSRF) token from browser storage and using Simple Object Access Protocol (SOAP) requests against Zimbra. It says failure to acquire that token prevents those SOAP requests. This dependency is important when assessing what an individual execution could have achieved.
The described collection includes the user's email address, account information, recovery codes and the organisation's Global Address List. It also attempts to retrieve non-junk messages from the preceding 90 days. The capability is not proof that all those records were successfully stolen from every targeted account. We recommend separating the payload's requested scope from the exports and outbound transfers actually supported by logs.
Application passcodes support continued access
The advisory describes creation of an application passcode named ZimbraWeb and an attempt to enable Internet Message Access Protocol (IMAP) access. Application passcodes support mail clients that cannot use the normal two-factor authentication (2FA) process. The script also seeks 2FA scratch codes and attempts to capture a password supplied through autocomplete.
Proofpoint reports that the generated application password can support IMAP, Post Office Protocol version 3 (POP3) or Simple Mail Transfer Protocol (SMTP) access without a further 2FA challenge. It also reports subsequent phishing from compromised accounts, while explicitly leaving unclear whether the application password or other stolen credentials enabled that later access. We retain that uncertainty rather than assigning every follow-on message to one authentication mechanism.
Collection and exfiltration leave different evidence
The joint advisory describes Domain Name System (DNS) and encrypted web traffic as exfiltration channels. Smaller authentication and account values can travel in DNS queries, while email archives use the web channel. The receiving infrastructure is called Flowerbed in the advisory; its collection component receives and stages the material.
A particularly useful limitation concerns browser storage. The payload records date-shaped keys in local storage while processing email collections, but the advisory says those keys are written regardless of successful exfiltration. They can support a finding that the collection routine ran. They cannot, alone, prove that the corresponding day's mail reached the attacker.
Impact and investigative scope
The joint advisory's attribution and espionage assessment rest on the campaign it describes. They should not be extended to every XSS attempt against Zimbra or to an unexplained application passcode without supporting evidence. Similarly, evidence of a malicious message reaching a mailbox is not identical to evidence that a vulnerable client displayed it.
We recommend distinguishing delivery, vulnerable-client viewing, payload execution, account modification and confirmed data transfer in the incident timeline. Each step changes the scope of the response. A successful software update addresses future exploitation through the flaw; it does not revoke an application passcode created earlier or determine the sensitivity of messages already exported.
Indicators and detection opportunities
The joint advisory warns that its infrastructure indicators are intended for historical investigation and may be outdated. Check current activity before taking action against an address or domain. The examples below therefore combine historical leads with account and browser artefacts.
| Evidence | What it can establish | Qualification |
|---|---|---|
synacorzimbra[.]nl or istc-cloud[.]com in historical network records |
Connections to infrastructure listed in the joint advisory | Both are historical indicators; retain timestamps and reassess current status |
Application passcode named ZimbraWeb |
The persistence artefact described by both sources | Preserve creation and use records, then follow remediation guidance |
Bursts of SearchGalRequest activity |
Possible directory enumeration matching the payload | Correlate with the account and surrounding requests |
GetScratchCodesRequest and application-passcode creation |
Access to recovery material and potential persistence | Determine whether the action was expected and authorised |
Browser keys shaped as zd_comp_YYYY-MM-DD |
Evidence consistent with the payload's collection tracking | The keys do not establish successful exfiltration |
The advisory points investigators to /opt/zimbra/log/mailbox.log for SOAP activity. Proofpoint additionally recommends reviewing /opt/zimbra/log/audit.log for application-password creation. Preserve both sources where available, with mailbox activity, browser evidence and outbound network records. A search limited to endpoint malware detections would not answer the account-level questions described here.
Immediate response
First, close the vulnerable viewing path. The joint advisory identifies fixes in ZCS 10.0.18 and 10.1.13. Where immediate updating is infeasible, it recommends alternative mail clients and avoiding the Classic ZCS webmail client until the installation is no longer vulnerable. Validate the deployed version and the clients users actually access.
Second, preserve evidence and identify the compromised population. Review the listed account artefacts and relevant network history, recording dates for each supported finding. Search suspected mailboxes for the originating malicious email, then identify and quarantine related messages by body content, sender and subject as the advisory recommends.
Third, address persistent authentication. For an organisation that identifies activity associated with the campaign, the joint advisory calls for revoking all users' application passcodes and 2FA scratch keys, and requiring all employees to change passwords. That is broader than deleting the suspicious ZimbraWeb entry from one account. Coordinate replacement credentials and legitimate client access as part of the response, without leaving the old passcodes usable.
Fourth, assess data exposure from the available evidence. Reconstruct export requests, transfer destinations and the timing of malicious-message viewing. Treat the reported 90-day collection scope as a capability to investigate, while recording uncertainty where logs cannot establish successful transfer or complete coverage.
ATT&CK context
The advisory maps server-side mailbox collection through application programming interface (API) calls to Remote Email Collection, T1114.002. That is the relevant distinction: the script requests mail from the service rather than simply copying an existing local mailbox file.
Use the mapping to assign coverage to account-level export and access activity as well as the endpoint. It does not establish that every API request is malicious, or that all mail available to the user was taken. The source's collection and authentication artefacts supply the context needed to assess those events.
Hardening after containment
The joint advisory recommends prompt mail-platform updates and network monitoring with retained flow or packet evidence. It highlights unusual outbound volumes, suspicious DNS requests with random-looking subdomains and sudden connections to recently established domains. We recommend testing those detections against normal mail exports and legitimate application activity before relying on them for attribution.
The agencies also recommend considering a passkey-capable third-party authentication service. They explicitly retain the need to monitor application passcodes, which may still be required. This qualification matters: strengthening interactive sign-in does not remove every alternative means of authenticating a mail client.
Review how application passwords are approved, inventoried and revoked, and make unusual creation visible to the incident team. This is our operational recommendation based on the persistence mechanism. A recovery exercise should confirm that investigators can identify both the user-facing session and any separately issued client credential.
History and outlook
The advisory places initial exploitation in July 2025, patch availability in November 2025 and publication of the vulnerability record on 5 January 2026. CISA's listing followed on 18 March 2026. These dates support the historical zero-day description while making clear that a fix predates the July 2026 warning.
Our likely (B2) judgement is that account recovery remains necessary after patching where exploitation is established. The evidence is the payload's application-passcode creation and authentication-material collection. The principal uncertainty for each organisation is what succeeded, what access persisted and which messages were transferred; resolving those questions requires local evidence rather than a campaign label alone.
