A scripting bug in webmail, and ninety days of everybody’s email
Russian state-supported actors have been compromising Western government and commercial organisations running Zimbra Collaboration Suite since at least July 2025. The delivery is an email and the victim clicks nothing. Viewing the message in the Classic webmail client runs the attacker’s JavaScript, exploiting CVE-2025-66376, a cross-site scripting flaw in how Zimbra sanitises CSS import directives. In twelve asynchronous stages the payload takes the last 90 days of mail, the organisation’s Global Address List and whatever else it can reach, and pushes it out over DNS. The sectors CISA names are the Defence Industrial Base, federal and local government, education, energy, law enforcement, media, non-governmental organisations and technology.
What worked
The advisory does not say. It documents the tradecraft and the infrastructure in unusual detail and names no control at any victim that detected or stopped it. That is worth reading as a finding rather than as an omission. Exfiltration base32-encoded into DNS subdomains, sent to servers that are rotated every seven to sixty days, is built to pass the monitoring most organisations actually have rather than the monitoring they describe in an audit.
What failed
Patching, and then the password manager.
The flaw was a zero-day when exploitation began in July 2025. Zimbra released fixes for 10.1.13 and 10.0.18 in November 2025, and CISA says it "continues to be successfully exploited" well after that. Four months with no patch available, then months more with a patch nobody applied.
The second failure is quieter and worth sitting with. The script injects two hidden HTML elements requesting login credentials onto the page, outside the victim’s view, waits five seconds, and reads back whatever the browser’s password manager has autofilled into them. Nothing was tricked. The password manager did the job it was built to do, into a form the user never saw, on a page they had every reason to trust, in a session they had already authenticated. This is the part that a stronger password would not have helped with.
The number
90 days
of mail taken from each compromised mailbox, plus the full Global Address List, harvested in 20 batches of 77 directory lookups each.
What to do instead
Check the version first, because that is the whole of the immediate question. If you are on a vulnerable Zimbra build and cannot patch today, CISA’s interim advice is to move people off the Classic webmail client entirely and onto another mail client until you can. An advisory recommending that users stop using a product’s own interface is telling you how it rates the exposure.
Then assume the reads happened. What was taken is ninety days of mail and the address list, so this is not only a credential rotation. Revoke every Application Passcode and 2FA scratch key, force password changes, and go looking for the evidence: the SOAP request patterns CISA lists in mailbox.log, and localStorage items named zd_comp_YYYY-MM-DD.
Then fix the thing that made the credential theft free. Autofill into an invisible form is browser behaviour, not a Zimbra bug, and the next webmail scripting flaw will use it the same way. Moving authentication to a third-party service that supports passkeys takes the password out of the browser’s hands entirely, which is CISA’s own recommendation here and the only one on the list that survives the next occurrence.
And keep the network data. Every detection CISA offers is netflow or DNS: frequent queries with randomised subdomains, spikes to recently registered domains, outbound volume to virtual private servers. None of it is answerable without packet capture or NetFlow retained long enough to look backwards, which is a decision you make before the advisory rather than after it.
- PrimaryCISA AA26-204A