Zimbra CVE-2025-66376 exploited to steal 90 days of mail and 2FA scratch codes

TL;DR

---

CVE-2025-66376, a stored XSS in the Zimbra Classic UI, had been used for Russian state-supported mail theft since at least July 2025.
Zimbra fixed it on November 6, 2025 in 10.1.13 and 10.0.18. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on March 18, 2026 and set an April 1 remediation deadline for US federal civilian agencies (now passed).
On July 23, 2026, the NSA, FBI, CISA, and partner agencies published joint advisory AA26-204A, naming the attack group LAUNDRY BEAR and its custom tooling Ulej.

The joint advisory also lists Void Blizzard, CL-STA-1114, and TA488 as overlapping industry names tracking the same activity.
It notes, though, that what each organization tracks may not map one-to-one.
I covered Russian credential theft before in APT28’s TP-Link router DNS hijack. That one grabbed Microsoft 365 credentials at the network level.
This time the webmail client itself is the entry point, and mail plus the 2FA recovery path are stolen inside the mail-reading screen.

The @import fragments reassemble into svg onload

CVE-2025-66376 is a cross-site scripting flaw (stored XSS): malicious code saved as an email body executes when the message is viewed. The root cause is in Zimbra Classic UI’s HTML sanitizer.
Inside a crafted HTML email, the attacker splits an executable tag like svg onload into small pieces using fake CSS @import statements and HTML comments.
Zimbra’s processing fails to recognize the fragments as a dangerous tag, and once the @import parts are stripped, the leftover strings reassemble in the browser as <svg onload=eval(atob(...))>.

The joint advisory calls the custom tool set, including the attack infrastructure, Ulej. Proofpoint calls the malicious in-browser JavaScript itself ZimReaper, and the collection-server side Flowerbed.
No link click or attachment execution is involved.
Opening or previewing the email in a vulnerable Classic UI is enough, and the JavaScript runs as that user’s logged-in Zimbra session.

NVD counts opening the mail as user interaction and scores it CVSS 6.1 with UI:R (user interaction required). MITRE scores it 7.2 with UI:N (no user interaction).
Proofpoint describes the view-only trigger as “half-click”, while Unit 42 calls the lack of any extra link or attachment step “zero-click”.

flowchart TD
    A["Crafted HTML email"] --> B["Rendered in Zimbra Classic UI"]
    B --> C["Sanitizer processes<br/>CSS @import fragments"]
    C --> D["Leftover strings reassemble<br/>as svg onload"]
    D --> E["Ulej<br/>runs ZimReaper"]
    E --> F["CSRF token<br/>autofill passwords<br/>2FA scratch codes"]
    E --> G["Brute-forces the GAL"]
    E --> H["Exports last 90 days<br/>of mail as TGZ"]
    F --> I["Sent to C2 via DNS queries"]
    G --> I
    H --> I

Account-side changes remain outside the mail body

ZimReaper picks up the CSRF token needed to call the API as the logged-in user, plus passwords from the browser’s autofill. It also retrieves 2FA scratch codes from the Zimbra API.
Scratch codes are backup codes for recovering login when the usual 2FA device is unavailable.
Separately from changing passwords, revoke the stolen scratch codes and reissue them.

The code then uses CreateAppSpecificPasswordRequest to create an app-specific password named ZimbraWeb.
App-specific passwords are separate passwords issued for mail clients that connect over IMAP, POP3, or SMTP.
With one in hand, the attacker keeps accessing mail over IMAP, POP3, and SMTP without ever passing 2FA.

In a case Seqrite analyzed (an email received by a Ukrainian government agency on January 22, 2026), the attack code flipped zimbraPrefImapEnabled to TRUE.
If IMAP is normally disabled in your organization, that setting change remains on the account.
If the whole company uses IMAP, cross-check names like ZimbraWeb, creation times, originating IPs, and SOAP API calls instead.

Mail bodies were also taken in bulk.
In Proofpoint’s analysis, the code brute-forced the organization’s Global Address List (GAL) two characters at a time to build a mail directory, then used Zimbra’s export feature to package the last 90 days of mail as a TGZ and POST it to C2.
CSRF tokens and passwords were Base32-encoded and sent through DNS queries; the Ulej samples analyzed in the joint advisory send the same data over HTTPS as well.
Queries for long random-looking subdomains of known C2 domains never show up in HTTP logs, so check DNS logs separately.

Update Classic UI installs to 10.1.20

Zimbra’s 10.1.13 release notes list CVE-2025-66376 as fixing a stored XSS exploitable through CSS @import in the Classic UI.
Affected versions are ZCS 10.0 before 10.0.18 and 10.1 before 10.1.13.
The 10.0 line reached end of life (EOL) on December 31, 2025 and no longer receives security updates.

As of July 2026, the Zimbra Security Advisories page shows XSS fixes around the Classic Web Client continuing after that.
10.1.17 and 10.1.19 also fixed XSS bugs in mail display and attachment preview, and 10.1.20 fixed four more stored XSS flaws in the Classic Web Client.
10.1.13 is the minimum for CVE-2025-66376, but environments that keep using Classic UI should go to 10.1.20.

With the Ghost CMS CVE-2026-26980 exploitation, the injected JavaScript and API keys had to be handled separately from the update.
Zimbra is the same: after updating to 10.1.20, the created app-specific passwords, the 2FA scratch codes, and the changed IMAP settings all stay in place.
Revoke and restore those individually, along with scoping which mail was taken.

Traces to check in logs, accounts, and endpoints

For mail that may have been opened in Classic UI during the vulnerable window, use the YARA rules Proofpoint published for the malicious code and sweep for the split @import fragments and the svg onload reassembly pattern.
Quarantine messages that were only received; accounts that previewed one go into compromise investigation and credential revocation.

The joint advisory’s default place to look is /opt/zimbra/log/mailbox.log.
Look for bursts of SearchGalRequest, CreateAppSpecificPasswordRequest, and GetScratchCodesRequest from the same user in a short window.
The advisory treats an app-specific password named ZimbraWeb, which the webmail itself never needs, as an indicator of compromise.

For organizations where the activity is found, the advisory recommends revoking every user’s app-specific passwords and 2FA scratch codes and changing all employee passwords.
Session invalidation, restoring accounts where zimbraPrefImapEnabled was flipped to TRUE, and quarantining the malicious mail are carried out as separate steps.
On user endpoints, check the Zimbra page’s localStorage for zd_comp_YYYY-MM-DD keys.
The attack code uses them to record per-day mail collection completion, so they help pin down which days of mail were taken.

The 9 domains and 9 IPs published by Unit 42 and the joint advisory are leads for hunting past traffic.
The advisory itself cautions that the published indicators of compromise (IOCs) are for confirming past activity, and the IPs and domains have likely changed since.
Proofpoint says the C2 domains imitated Zimbra and mail-analysis services and received Base32-encoded values over DNS.
Cross-check subdomains starting with d- plus a 12-character identifier seen from endpoints or your DNS resolvers, bulk uploads to virtual private servers (VPS), sudden connections to newly registered domains, and webmail access through Mullvad VPN.

References

• Joint Cybersecurity Advisory AA26-204A: Russian State-Supported Cyber Actors Conduct Phishing Campaign Targeting Users of Zimbra Collaboration Suite
• The Hacker News: Russian Espionage Group Exploited Zimbra Zero-Day to Steal Mail and 2FA Codes
• Proofpoint: TA488 Targets Zimbra Mailservers with Half-Click Exploits
• Unit 42: Russian Global Webmail Espionage
• Seqrite: Operation GhostMail
• Zimbra Releases 10.1.13
• Zimbra Releases 10.1.20
• Zimbra Security Advisories
• NVD: CVE-2025-66376