What happened?

Okay, grab your tin-foil hats, but keep your patch notes handy. A state-backed Russian espionage team quietly abused a previously unknown flaw in Zimbra’s Classic Web Client and spent months quietly reading inboxes. Security agencies and vendors flagged the campaign: the exploit is a stored XSS in the Classic UI that runs when a message is rendered in a vulnerable session, so just viewing (or previewing) the message can trigger it. Some researchers call the technique zero-click because the victim doesn’t have to do anything besides open the mail.

The bad code hides inside a crafted HTML email via clever CSS and broken-up tags, which tricks Zimbra’s sanitizer into leaving behind an executable fragment (think an <svg onload=...> that sneaks through). Once the JavaScript runs, it behaves like a tiny mailbox burglar: it grabs mailbox data, saved browser passwords, two-factor recovery codes, version info and more, then shuttles it out using DNS lookups and other sneaky channels.

Important version notes: the bug affects Zimbra Collaboration Server 10.0 before 10.0.18 and 10.1 before 10.1.13. Vendors released fixes, but a patch only blocks future messages — it doesn’t un-steal what was already taken.

What to do right now (patches and cleanup)

Patching is step one, but treating the account as potentially compromised is just as critical. Here’s a practical checklist to get you from panicked to (mostly) safe:

  • Upgrade Zimbra Classic UI instances to at least 10.1.13 (move 10.0 installs to a supported 10.1 release). Patching stops new exploit emails from executing.
  • Assume any mailbox that opened or previewed a suspicious HTML message is compromised: reset passwords, invalidate active sessions, and regenerate 2FA scratch codes.
  • Search your logs (for example, /opt/zimbra/log/audit.log) for calls to CreateAppSpecificPassword and remove any app password named ZimbraWeb or other unknown entries.
  • Look for accounts with zimbraPrefImapEnabled set to TRUE — if IMAP isn’t needed, disable it. The exploit can create app-specific credentials that bypass two-factor protections.
  • Alert on unusual SOAP activity like GetScratchCodesRequest — this isn’t common in normal use and may indicate the payload riffled through 2FA recovery options.
  • Inspect any delivered but unopened HTML messages for the fragmented @import-style patterns and tag-splitting tricks. If you have YARA or similar rules from threat vendors, run them against the raw message bodies.
  • Monitor DNS for long, random subdomain lookups — the attacker used DNS queries to exfiltrate data.
  • Search for large outbound archives or unusual IMAP/POP/SMTP connections that could be the attacker pulling mailbox data (the campaign was reported to exfiltrate about 90 days of mail in some cases).

Some victims discovered the exploit also toggled settings and created persistent app passwords that survive password resets, so don’t treat a password change alone as a complete cure. You may need to revoke app passwords, audit mailbox settings, and re-check logs after a cleanup.

Final note: patching ends the immediate threat, but the real risk is what was already taken. Treat affected accounts as compromised, hunt for signs of persistent access, and make sure you revoke any strange app-specific credentials.