Vulnerability · Email Security

Russian Espionage Group Exploited a Zimbra Zero-Day to Steal Mail and 2FA Codes

July 24, 2026 · 6 min read

A Russian state-supported espionage group called LAUNDRY BEAR has been quietly raiding Zimbra webmail accounts since at least July 2025, exploiting CVE-2025-66376, a stored cross-site scripting flaw that fires the moment a target views a malicious email. No link clicks, no attachments, no social engineering beyond getting the message into the inbox. The payload, a novel tool the group named Ulej (Russian for "Beehive"), walks out with 90 days of email, the full organizational address book, browser-saved passwords, and 2FA recovery codes. CISA, NSA, FBI, the UK NCSC, and Australia's ACSC published joint advisory AA26-204A on July 23, 2026, confirming active exploitation across government, defense, energy, financial, education, and media organizations in Western countries.

What actually happened

CVE-2025-66376 lives in the Classic UI of Zimbra Collaboration Suite. The vulnerability is a stored XSS flaw that abuses CSS @import directives inside HTML email. When Zimbra renders the message in a user's browser, the malicious CSS triggers JavaScript execution inside the already-authenticated webmail session. The victim's session cookie and credentials are right there. No phishing page, no redirect, no warning. CISA's advisory describes the technique as "zero-click" or "half-click" depending on whether you count opening a message as user interaction. NVD scored the CVE at 6.1 on that reasoning. MITRE scored it at 7.2, arguing that viewing a message is not a meaningful interaction. Either way, the bar for exploitation is vanishingly low.

Zimbra released patched versions 10.1.13 and 10.0.18 in November 2025, and the CVE was formally published in the National Vulnerability Database on January 5, 2026. CISA added it to the Known Exploited Vulnerabilities catalog and ordered U.S. federal agencies to patch by April 1, 2026 under Binding Operational Directive 22-01. Exploitation had been running since at least July 2025, meaning the group had a minimum of four months of undetected access before a patch even existed. Organizations still on the 10.0 branch face an additional problem: version 10.0 reached End of Life on December 31, 2025. Version 10.0.18 patches this specific CVE but does not restore vendor support, which means no future security fixes for that branch.

The Ulej exfiltration tool is what makes this campaign particularly damaging. Once the JavaScript payload executes, Ulej systematically pulls the last 90 days of the victim's email, the complete organizational email directory, any passwords the browser has saved, and 2FA recovery codes or application passcodes. That last item is worth pausing on. The attackers collected 2FA codes as part of the same automated sweep that grabbed passwords. Palo Alto Networks Unit 42 and Proofpoint published concurrent research alongside the July 23 advisory, and LAUNDRY BEAR is tracked under additional aliases including Void Blizzard, CL-STA-1114, and TA488, which was formerly designated UNK_PitStop.

Why this should matter to you even if you don’t run Zimbra Collaboration Suite

Zimbra is a common mail platform across mid-size government agencies, universities, utilities, and international NGOs, exactly the sectors LAUNDRY BEAR targeted. If your organization does not run Zimbra, this campaign still illustrates a pattern worth understanding: a webmail XSS vulnerability that executes on message render is an attacker's dream scenario because every email you receive from an untrusted sender becomes a potential trigger. Similar XSS flaws have appeared in other major webmail platforms over the years, and any organization running server-side webmail should treat this as a prompt to review both patch status and session security controls.

The 2FA angle is the piece that should get the most attention. Many security programs treat 2FA as the safety net that catches credential theft. The Ulej tool targets that assumption directly. If 2FA recovery codes or TOTP passcodes are accessible inside the webmail session, an attacker who controls that session can collect them without ever needing to know your password independently. The attack sequence becomes: compromise session, harvest credentials, harvest 2FA codes, and authenticate to downstream systems at leisure. That sequence bypasses the protection most organizations believe 2FA provides.

The sector list in the advisory is broad enough that almost any organization of consequence appears on it: government, defense, energy, technology, education, media, law enforcement, transportation, financial, and NGOs. LAUNDRY BEAR appears to be running broad collection campaigns rather than surgically targeted operations, which means the threat is diffuse. A mid-size regional utility or a university with research contracts is as plausible a target as a defense prime. If you are in any of those sectors and run any version of Zimbra older than 10.1.13, patch status is the immediate question.

The control that would have blunted it

The control that would have materially reduced the impact of this specific attack is hardware-backed or application-based MFA that does not expose recovery codes through the webmail interface. Here is the distinction that matters in this case: TOTP codes and recovery codes that are stored or displayed within the webmail session are accessible to any JavaScript running in that session. A hardware security key using FIDO2 or WebAuthn produces a cryptographic assertion that is bound to the origin domain, never exposed as a string of digits, and never stored anywhere the Ulej payload could read it. The attacker's JavaScript has nothing to collect because the credential never exists as readable text inside the browser context.

Cyber insurers are increasingly explicit about this. Many carrier questionnaires and policy conditions now distinguish between SMS-based MFA, TOTP apps, and phishing-resistant hardware MFA. FIDO2 hardware keys are the form most likely to satisfy the "phishing-resistant MFA" language that appears in current policy requirements, particularly for privileged accounts and remote access. If your organization is relying on TOTP codes sent to or stored in a browser session to satisfy that policy requirement, it is worth reviewing those policy terms carefully with your broker. What qualifies as compliant MFA has narrowed over the past two years.

There are real operational tradeoffs here. Hardware keys cost money, require procurement and inventory management, and create a support burden when users lose or break them. TOTP authenticator apps are a reasonable middle tier for lower-risk accounts, provided recovery codes are stored out-of-band, for example in a password manager or printed and stored physically, and never accessible inside a webmail or browser session. The architectural principle is that the second factor should be uncorrelated with the primary credential storage path. When both the password and the 2FA code live in the same session context, they collapse into a single factor from the attacker's perspective.

Beyond MFA architecture, a few additional controls are relevant here. Content Security Policy headers on webmail deployments can constrain what JavaScript is allowed to execute and where data can be sent, which would have limited Ulej's exfiltration path even if the XSS fired. Session timeout policies reduce the window of exposure. And if your organization runs Zimbra, the immediate action is patching to 10.1.13 or migrating off the EOL 10.0 branch entirely. Patching a CVE on an unsupported version buys you a fix for this specific flaw and nothing else going forward.

Strondex's MFA solutions page covers the architecture differences between TOTP, push-based, and FIDO2 hardware authentication, including how each maps to current cyber insurance policy requirements.