APT28 linked to Zimbra XSS attacks on Ukraine; CISA adds CVE-2025-66376 to KEV
A Zimbra stored XSS (CVE-2025-66376) let one HTML email steal mailboxes, 2FA codes and app passwords. How Operation GhostMail worked and how to patch it.
On 18 March 2026, CISA added CVE-2025-66376, a stored cross-site scripting bug in Zimbra Collaboration's Classic web UI, to its Known Exploited Vulnerabilities catalog. A day earlier, Seqrite Labs had published "Operation GhostMail", a campaign against Ukrainian government bodies that used the bug to turn a single opened email into a full mailbox and credential stealer. The way the payload got past Zimbra's HTML sanitiser is a good case study for anyone who renders user-supplied HTML.
What happened
Zimbra fixed CVE-2025-66376 in November 2025 in ZCS 10.0.18 and 10.1.13. NVD describes it as Classic UI stored XSS via CSS @import directives in HTML email. NIST scores it 6.1, and the CNA scores it 7.2. CISA set 1 April 2026 as the remediation deadline for US federal agencies.
Seqrite reported that on 22 January 2026 a Ukrainian state hydrology agency received a phishing email from what appeared to be a compromised student account at a Ukrainian academy. The email had no attachment, no link and no macro. The whole attack sat in the HTML body and ran when the message was opened in a vulnerable Zimbra webmail session. Seqrite attributes the campaign to APT28 (Fancy Bear, Forest Blizzard), the group linked to Russia's GRU, with medium confidence. It cites overlaps with ESET's earlier "Operation RoundPress" Zimbra activity.
Who is affected
- Zimbra Collaboration installations older than 10.0.18 (10.0 branch) or 10.1.13 (10.1 branch) where users read mail in the Classic web UI.
- Government, defence and critical-infrastructure organisations, which Russian groups have repeatedly targeted through Zimbra: Winter Vivern in 2023 and APT29 mass exploitation, as warned by US and UK agencies in 2024.
- Users whose sessions ran the payload. Their mailbox, 2FA backup codes and saved browser passwords should be considered exposed.
What it means for developers and engineering teams
The sanitiser bypass. According to Seqrite, the attacker put the @import token inside tag and attribute names. Zimbra's sanitiser removed the token, and the leftover pieces joined into an SVG element with an onload handler that ran eval(atob(…)). This is a classic mistake: a sanitiser that deletes dangerous substrings, rather than parsing and allow-listing, can be tricked into building the payload. Anyone who renders untrusted HTML (comments, rich text, emails, Markdown with embedded HTML) should sanitise with a real parser such as DOMPurify, run it until the output stops changing or sanitise only once on a parsed tree, and add a strict Content-Security-Policy that blocks inline script and eval.
Why email filters missed it. Mail gateways mostly look for malicious attachments, URLs and macros. A message whose only weapon is HTML/CSS markup, interpreted by the webmail client, gives them very little to flag. The fix has to happen in the client: patched sanitisation and a restrictive CSP on the webmail origin.
What the stealer did with the session. Running in the victim's origin, the script called Zimbra's SOAP API with the CSRF token from localStorage. It read account details, fetched 2FA scratch codes (GetScratchCodesRequest), created an app-specific password named "ZimbraWeb" (CreateAppSpecificPasswordRequest), enabled IMAP, triggered browser autofill to collect saved passwords, and exported 90 days of mail as a .tgz. Data was sent out over HTTPS and also as Base32 chunks in DNS lookups to a zimbrasoft[.]com[.]ua subdomain. The app password is the persistence mechanism. It survives a normal password reset, so just changing the user's password does not lock the attacker out.
What to do now
- Upgrade Zimbra to 10.0.18 or 10.1.13 or later, and move users off the Classic UI where you can.
- For possibly affected accounts: revoke all app-specific passwords, regenerate 2FA scratch codes, reset passwords, end active sessions, and check whether IMAP was recently enabled.
- Hunt in DNS and proxy logs for
zimbrasoft[.]com[.]uaand for long, high-entropy subdomain queries that look like Base32 exfiltration. - Audit Zimbra logs for
CreateAppSpecificPasswordRequest,GetScratchCodesRequestand bulk?fmt=tgzexports. - Check that your Zimbra webmail sends a Content-Security-Policy header and review it for
'unsafe-inline'. Even a temporary reverse-proxy CSP reduces risk while you upgrade. - In your own apps: replace regex or substring-stripping sanitisers with a parser-based allowlist sanitiser, and set a CSP without
'unsafe-inline'or'unsafe-eval'.