CVE-2025-66376: Patch Zimbra XSS Exploited by LAUNDRY BEAR

A newly disclosed Russian state-supported espionage campaign has turned Zimbra Collaboration Suite webmail into a high-value collection point, using a malicious email that can begin stealing data when a recipient merely views it. The operation, attributed primarily to LAUNDRY BEAR and also tracked as Void Blizzard, CL-STA-1114, and TA488, exploits CVE-2025-66376, a stored cross-site scripting flaw affecting vulnerable Zimbra Classic UI deployments. For organizations running self-hosted email infrastructure, the message is urgent: this is not a conventional phishing campaign that depends on a user clicking a link, opening an attachment, or entering credentials into a fake portal.
The campaign’s objective is plainly espionage. Once code runs in the victim’s authenticated Zimbra browser session, it attempts to collect the previous 90 days of email, the organization’s Global Address List, account details, authentication recovery data, and newly generated app-specific passwords. It can also enable IMAP access in an effort to create a durable route back into a compromised mailbox.
That combination makes this more serious than another isolated webmail bug. It is a practical example of how a client-side vulnerability can turn a trusted email platform into an automated intelligence-gathering tool, exploiting the browser’s existing trust in a user’s active session.

---

Overview: A Phishing Attack That Needs Almost No User Interaction​

Traditional phishing awareness advice focuses on user decisions: do not click suspicious links, do not download unexpected files, and do not disclose passwords to unfamiliar websites. Those principles remain valuable, but this campaign exposes a dangerous limitation in that model.
The malicious email is crafted so that JavaScript executes in vulnerable versions of the Zimbra Classic web client once the message is rendered. The victim’s required “action” may be no more than opening the email or previewing it in webmail. In effect, the email itself becomes the delivery mechanism for code running inside an already authenticated mailbox session.
This is why CVE-2025-66376 deserves immediate attention from Zimbra administrators and security teams. The vulnerability arises from inadequate sanitization of Cascading Style Sheets @import directives in HTML email content. The flaw enables stored cross-site scripting in affected Zimbra versions and can be abused to execute attacker-controlled JavaScript in the context of the webmail application.
The published fixed releases are:

• Zimbra Collaboration Suite 10.0.18
• Zimbra Collaboration Suite 10.1.13

Deployments below those release levels should be treated as exposed unless administrators have confirmed an equivalent vendor-supported remediation. The vulnerability was reportedly exploited before public disclosure and patch availability, making it a genuine zero-day exploit at the beginning of the campaign.
That timing matters. An adversary that already understands a flaw, has operational infrastructure prepared, and has tested a payload against real-world targets can extract significant intelligence before a patch reaches production systems.

Why LAUNDRY BEAR’s Zimbra Campaign Stands Out​

LAUNDRY BEAR had already been associated with credential theft, password spraying, adversary-in-the-middle phishing, and bulk cloud email collection. Earlier activity reportedly relied on lower-complexity access methods, including the use of stolen credentials and phishing sites designed to intercept passwords and session tokens.
The Zimbra operation demonstrates an escalation in technical capability. Rather than waiting for targets to surrender credentials, the actors can abuse the authenticated browser session of a legitimate user. That allows them to make requests to Zimbra services as though they were the victim.
This distinction has major consequences:

• Multi-factor authentication alone may not stop the initial theft. The victim is already signed in when the payload executes.
• User awareness training cannot fully prevent exploitation. The email does not need a deceptive link or attachment.
• Email is both the lure and the prize. The malicious message arrives through the same system the actors intend to harvest.
• The attack can generate persistence mechanisms from inside the account. That reduces reliance on a single stolen session.
• Compromise can spread operationally. Previously compromised mailboxes may be used to send further malicious email, making messages appear more credible and complicating reputation-based filtering.

The campaign is also notable because it targets organizations across sectors that routinely exchange sensitive correspondence: government, defense-related organizations, education, energy, law enforcement, media, technology, and non-governmental organizations.
For Windows-centric enterprises, this is not an issue limited to the Linux server hosting Zimbra. The relevant attack surface includes every Windows workstation, browser profile, password manager, endpoint security agent, DNS resolver, proxy, and network-monitoring platform used by staff to access the webmail service.

---

Inside the Ulej Payload​

The custom capability behind the operation is called Ulej, a Russian word for “beehive.” It is designed to automate collection and exfiltration from a victim’s Zimbra account once the malicious email is viewed.
The payload uses several layers of obfuscation intended to frustrate simple signature matching. It is hidden within an SVG element, Base64-encoded, and protected with XOR-based encryption. The outer script decodes and decrypts an inner script, then runs the collection logic.
This construction is not especially sophisticated in isolation. Base64 encoding, XOR obfuscation, SVG-based smuggling, and harmless-looking filler code are all familiar techniques. However, their operational value is substantial because the actors can change keys, alter payload formatting, and add irrelevant directives to create many variants of the same functional attack.
A static detection rule that catches one sample may therefore miss the next.

The 12-stage collection process​

The malicious script reportedly operates through a sequence of asynchronous stages, including:

1. Sending a start signal to attacker infrastructure.
2. Identifying the victim’s email address.
3. Gathering details about the Zimbra environment.
4. Attempting to obtain two-factor authentication scratch codes.
5. Creating an app-specific password.
6. Collecting device-status information.
7. Enumerating OAuth consumers.
8. Attempting to capture passwords through browser autocomplete.
9. Enabling IMAP.
10. Collecting the Global Address List.
11. Downloading and packaging archived email.
12. Sending completion telemetry.

This is not opportunistic browser-based scraping. It is a purpose-built mailbox collection workflow engineered around Zimbra’s own authenticated interfaces.
The use of valid Zimbra SOAP requests is particularly important. Security teams may see requests that appear legitimate at a protocol level because they originate from a real user session and invoke normal application functions. Detection depends on identifying suspicious volume, sequencing, timing, and context, not simply blocking a single invalid request.

---

What the Attackers Attempt to Steal​

The campaign’s collection priorities reveal its intelligence value. Email remains one of the richest sources of organizational information because it contains policy discussions, strategy, attachment exchanges, technical planning, personal contacts, password reset messages, vendor communications, and clues to future operations.

Ninety days of email​

Ulej attempts to retrieve messages from the last 90 days, excluding items already categorized as junk. The collection is organized day by day, allowing the actor to capture a substantial recent archive without needing access to years of historical data.
For a government office, defense contractor, university, or energy operator, 90 days can encompass project planning, incident correspondence, travel information, supplier negotiations, staff changes, legal discussions, and internal decision-making.
The campaign also stores state information in the browser’s localStorage, marking dates that have already been processed. This allows a repeat execution on the same endpoint to avoid redundant archival attempts while continuing to collect current-day messages.
That behavior has a defensive upside: the presence of local storage keys following a zd_comp_YYYY-MM-DD pattern may help incident responders identify affected endpoints and estimate which dates were likely targeted for collection.

The Global Address List​

The Global Address List, or GAL, is another highly valuable target. A corporate or government directory gives an espionage actor a structured map of employees, functions, email addresses, naming conventions, and potential relationships.
The payload attempts to enumerate this directory through large numbers of SearchGalRequest operations. Such activity is unusually noisy compared with ordinary user behavior, especially when a single account sends a high volume of broad directory searches in rapid succession.
The stolen directory can support future campaigns by helping attackers:

• Identify executives, administrators, analysts, and technical personnel.
• Create highly convincing social-engineering messages.
• Discover departmental naming patterns.
• Map internal organizational structure.
• Expand targeting from one compromised mailbox to many more users.

Authentication material and persistence options​

The payload attempts several forms of credential-related collection and account manipulation:

• 2FA scratch codes
• Newly created app-specific passwords
• Passwords inserted automatically by browser password managers
• Account email address and environment details
• IMAP enablement

The creation of an application passcode named “ZimbraWeb” is a particularly strong warning sign. An app-specific password can be used by clients that do not support the standard multi-factor authentication flow. In the context of this campaign, it can provide a route for continued mailbox access outside the normal browser session.
Enabling IMAP is equally concerning. If an attacker obtains usable credentials or an app-specific password, IMAP can offer a persistent and efficient method of collecting mail through a desktop client or automated tooling.

---

The Password Manager Risk Is Real but Nuanced​

One of the more striking claims in the advisory is that the malicious script attempts to harvest passwords from browser autocomplete behavior. The attack injects hidden credential fields into the rendered page and waits to see whether a browser or password manager populates them automatically.
This should not be interpreted as proof that every password manager is universally vulnerable to theft through any hidden form. Browser behavior, extension safeguards, field matching rules, origin checks, enterprise policies, and user interaction requirements differ widely.
Still, the technique is a meaningful reminder that browser-based credential storage creates an additional layer of risk when a trusted web application suffers a cross-site scripting flaw. The script is running in the context of a legitimate site the user already trusts.
Organizations should take several practical lessons from this:

• Use phishing-resistant authentication where possible.
• Review password-manager enterprise policies and browser autofill settings.
• Avoid treating password managers as a substitute for patching browser-facing applications.
• Assume password rotation may be necessary after a confirmed compromise, including passwords unrelated to Zimbra if they could have been present in the user’s browser vault.
• Monitor for unusual credential prompts or unexpected autofill behavior in webmail sessions.

Passkeys and hardware-backed authentication can reduce exposure to reusable passwords, although they do not magically neutralize every risk from a fully compromised web session. Defense must account for the application, identity system, endpoint, and network together.

---

Flowerbed: The Infrastructure Behind the Exfiltration​

The stolen data is sent to attacker-controlled infrastructure using a framework called Flowerbed. The framework reportedly runs in Docker containers and includes services identified as Catcher, Certbot, Nginx, and Gardener.
At a high level, the infrastructure performs four jobs:

• Receives DNS and HTTPS-based exfiltration.
• Uses TLS certificates to make HTTPS communications appear routine.
• Stores received data temporarily on the attacker’s virtual private servers.
• Supports operational health checks and rapid infrastructure replacement.

The use of Docker is unsurprising. Containers enable fast, repeatable deployment to rented servers and make it easier for actors to rebuild their infrastructure as domains and IP addresses are blocked or exposed.
The attackers reportedly rotate servers on a relatively short timeline, sometimes using them for only weeks. That means static blocklists remain useful for retrospective hunting but are insufficient as a standalone defense. Security teams need behavior-based detection capable of spotting the operational pattern even after the infrastructure changes.

DNS exfiltration as a stealth channel​

The campaign sends smaller data items through DNS queries, encoding the information into subdomains. DNS is attractive to attackers because many networks allow outbound DNS resolution with minimal inspection, and DNS traffic can blend into the constant background noise of ordinary endpoint activity.
The use of DNS does not mean the operation is invisible. It creates detectable signals, including:

• High-frequency queries to a newly registered or low-reputation domain.
• Long and seemingly random subdomain labels.
• Repeated queries from a browser-accessing endpoint shortly after viewing a message.
• Base32-like strings in DNS labels.
• Atypical query patterns to domains unrelated to normal business activity.
• Repeated communication involving a small group of user workstations.

Security teams should avoid assuming that encrypted DNS eliminates visibility. Whether an organization uses traditional resolvers, DNS over HTTPS, or DNS over TLS, it should retain enough telemetry to detect anomalous resolution behavior at the endpoint, proxy, resolver, or security gateway layer.

HTTPS exfiltration complicates inspection​

Larger data, including archived email, is sent through HTTPS. The attackers use valid certificates, making the traffic appear as ordinary encrypted web activity to controls that only inspect destination and certificate metadata.
This is where Windows enterprise security architecture can make a material difference. Organizations using web proxies, secure web gateways, endpoint detection and response platforms, DNS security tools, and carefully governed TLS inspection can correlate suspicious browser activity with unusual outbound data transfers.
A browser process making an unexpected large POST request to an unfamiliar domain shortly after a Zimbra webmail message is opened should be a high-value correlation event, especially when it occurs alongside suspicious SOAP activity in the Zimbra logs.

---

Detection: Where Administrators Should Hunt First​

Organizations should assume that detection requires investigation across both the server and client sides of the email environment. No single log source tells the whole story.

Review Zimbra mailbox activity​

The default Zimbra mailbox log location, /opt/zimbra/log/mailbox.log, is central to initial hunting. Administrators should search for suspicious SOAP request activity, especially from accounts that do not normally perform administrative or directory-heavy functions.
High-risk indicators include:

• Large numbers of SearchGalRequest commands from one user in a short period.
• CreateAppSpecificPasswordRequest activity creating an application password called ZimbraWeb.
• GetScratchCodesRequest operations that retrieve two-factor authentication recovery codes.
• ModifyPrefsRequest operations that enable IMAP unexpectedly.
• Sudden bursts of account, device, OAuth, and directory lookups from a user who merely appears to be reading email.

A single SOAP request is not necessarily malicious. The concern is the combination of requests and their relationship to suspicious email viewing, browser activity, and outbound connections.

Investigate affected endpoints​

On Windows endpoints, incident responders should examine:

• Browser history associated with Zimbra webmail sessions.
• Browser developer-console or security telemetry where retained.
• DNS cache and resolver logs.
• Proxy and firewall records.
• EDR telemetry showing browser-initiated network connections.
• Browser localStorage for suspicious zd_comp_YYYY-MM-DD entries.
• Password manager and browser autofill configuration.
• Recently created or altered email-client profiles.
• Evidence of unusual IMAP usage after a webmail session.

Endpoint investigation should also identify which devices accessed the mailbox during the suspected compromise window. The script’s use of browser local storage means one device may carry useful evidence even if the user later signs in from a different system.

Hunt across the mail environment​

The original malicious email may remain in the victim’s Inbox, Sent folder, trash, quarantine, journaling system, or backup archives. Search should not be restricted to one user mailbox.
Security teams should look for messages with:

• Unexpected SVG content.
• HTML containing suspicious CSS @import directives.
• Encoded JavaScript in unusual attributes such as onload.
• Similar sender patterns or delivery timestamps.
• Reused body structures with altered obfuscation.
• Messages sent from accounts within the organization that have no ordinary reason to contact the recipient.

The last point matters because the campaign evolved to use likely compromised accounts as distribution points. Internal email is often trusted more readily than outside mail, but internal origin is not proof of safety.

---

Immediate Mitigations for Zimbra Administrators​

The most important action is straightforward: patch vulnerable Zimbra systems immediately.
Organizations running versions earlier than 10.0.18 on the 10.0 release line or earlier than 10.1.13 on the 10.1 release line should prioritize the update as an active-exploitation issue, not routine maintenance.
If an immediate update cannot be completed, administrators should reduce exposure by limiting use of the vulnerable Classic web interface. Directing users to an alternative supported mail client can help reduce the risk while a tested patch rollout is completed.
A practical response plan should include the following actions.

1. Identify every Zimbra instance and exposed webmail endpoint.
   Include production, disaster recovery, test, regional, and legacy systems. Forgotten secondary deployments are common weak points.
2. Confirm exact version levels.
   Do not rely on asset inventory labels or assumptions. Verify the installed Zimbra version on each system.
3. Patch to a fixed supported release.
   Use a controlled emergency change process, but do not let routine change windows delay remediation indefinitely.
4. Validate the web client after updating.
   Confirm users are no longer exposed to the vulnerable behavior and ensure the correct service nodes received the update.
5. Search logs for compromise indicators before and after patching.
   Patching stops continued exploitation but does not remove attacker-created app passwords, enabled IMAP access, stolen credentials, or existing persistence.
6. Review application passcodes and authentication recovery codes.
   Revoke suspicious app-specific passwords, especially any named ZimbraWeb.
7. Reset passwords where compromise is suspected.
   Consider the possibility that stored passwords from browser autocomplete may have been collected.
8. Revoke and regenerate multi-factor authentication recovery codes.
   Scratch codes should be treated as potentially exposed for affected users.
9. Review IMAP configuration and client access logs.
   Disable unnecessary protocols and investigate newly observed mail client behavior.
10. Block known malicious infrastructure, but do not stop there.
    Domain, certificate, IP, and hash indicators are useful for retrospective detection. Behavioral monitoring remains essential because the actors rotate infrastructure.

---

Strengths and Limits of the Current Defensive Guidance​

The advisory’s strongest contribution is its unusually detailed technical description. It gives defenders specific logging targets, suspicious request names, local storage artifacts, traffic patterns, data formats, and account changes to investigate. That level of detail can substantially shorten the time between alerting and meaningful incident response.
The guidance also correctly emphasizes that organizations may discover the attack only after data has already left the environment. This is a realistic assessment. Because email collection can begin immediately after message rendering, prevention and rapid patching are far more valuable than relying solely on post-compromise cleanup.
However, several risks remain difficult to eliminate.

Patch urgency can collide with operational reality​

Zimbra often supports critical business functions, and some organizations may have complex integrations, customized authentication flows, archival systems, mobile-device dependencies, or constrained maintenance windows. Those realities can slow patch deployment.
Yet delay carries a concrete cost. Every additional day a vulnerable webmail interface remains available creates an opportunity for a user to open a malicious message and begin automated mailbox collection. In this case, postponing patching is not a theoretical risk calculation; it is continued exposure to an operation already associated with active exploitation.

Identity controls cannot compensate for vulnerable web applications​

Strong passwords, MFA, conditional access, and device compliance policies remain foundational. But they cannot fully protect a user when malicious code executes through the authenticated session of the email application itself.
This is an important architectural lesson. Identity security is necessary, but it is not a substitute for application security, browser security, endpoint telemetry, and network visibility.

Static indicators will age quickly​

Known domains, IP addresses, certificate hashes, sender addresses, and sample hashes are valuable for hunting. But the actors’ use of short-lived VPS infrastructure and configurable payloads means these indicators can expire quickly.
Organizations should build detections around durable behaviors:

• Suspicious Zimbra SOAP sequences.
• Unexpected creation of app passwords.
• Unauthorized IMAP enablement.
• Directory-enumeration bursts.
• Long random DNS subdomains.
• Browser-based outbound data transfers to unfamiliar infrastructure.
• Mailbox access changes following receipt of HTML-rich email.

---

The Broader Lesson for Enterprise Email Security​

This campaign is a reminder that email security cannot be reduced to spam filtering and user awareness campaigns. Modern mail systems are highly capable web applications with complex interfaces, APIs, embedded content handling, identity integrations, and rich browser sessions.
That capability brings risk. A flaw in HTML sanitization can become a pathway to mailbox-wide intelligence collection. A browser session can become a trusted execution environment for an adversary. A seemingly harmless app-specific password can become a persistence mechanism. And an ordinary DNS request can be repurposed into a covert exfiltration channel.
For Windows organizations, the most effective response is layered:

• Keep Zimbra and browser-facing services patched.
• Harden browsers and managed password behavior.
• Require strong, phishing-resistant authentication where available.
• Retain useful endpoint, DNS, proxy, and Zimbra application logs.
• Monitor for suspicious mailbox API activity rather than only failed logins.
• Treat unexpected app passwords, scratch-code access, and IMAP changes as security events.
• Prepare incident-response procedures that account for stolen mail, stolen contacts, and potentially exposed credentials beyond the email platform itself.

LAUNDRY BEAR’s campaign demonstrates that the line between phishing and exploitation is increasingly blurred. When viewing an email is enough to trigger account compromise, the defense must move beyond telling users to be cautious. It must ensure the mail platform, the browser session, and the surrounding security controls are ready for an adversary that expects the user to do nothing more than read their inbox.

---

References​

1. Primary source: CISA
   Published: 2026-07-23T12:00:00+00:00
   
   Loading…

   www.cisa.gov