A Stored XSS Flaw Hiding in Plain Sight

A newly disclosed vulnerability in Zimbra Collaboration Suite is giving security teams a reason to check their patch logs twice. Tracked as CVE-2025-66376, the flaw is a stored cross-site scripting (XSS) issue in the Classic Web Client, the older, HTML-based interface still used by many Zimbra deployments alongside the modern web app.

What makes this bug notable is how little a victim has to do to trigger it. According to the disclosure, simply opening a malicious email in the Classic UI is enough to run attacker-controlled code inside the victim's authenticated webmail session. From there, the attacker can pull session tokens, browser-stored passwords, and even two-factor authentication scratch codes, the backup codes users rely on when their primary 2FA method isn't available.

How the Attack Works

Stored XSS vulnerabilities are particularly dangerous because the malicious payload doesn't need to be clicked or downloaded separately. It gets embedded directly into content the mail client renders automatically, in this case through Cascading Style Sheets (CSS) directives inserted into an email. Zimbra's Classic Web Client failed to properly sanitize this content, allowing the CSS to execute JavaScript in the context of the logged-in user's mailbox session.

Once that code runs, it inherits whatever the victim's session already has access to. That's what allows it to reach beyond the inbox and grab authentication tokens, credentials cached in the browser, and 2FA scratch codes stored for account recovery. In practice, this turns a single opened email into a potential full account takeover, without the victim entering a password or clicking a suspicious link.

This is not the first time the Classic Web Client's handling of embedded content has caused problems. Zimbra has previously had to patch similar HTML and ICS-file sanitization issues in the same interface, a pattern that underscores why organizations still running the legacy client face recurring exposure until they either patch aggressively or migrate away from it entirely.

Who Needs to Act

The vulnerability affects Zimbra Collaboration (ZCS) 10 before version 10.0.18 and 10.1 before version 10.1.13. Zimbra has released fixed builds, and the company's own security advisory describes the patch as addressing a critical stored XSS issue in the Classic Web Client. Organizations running affected versions should treat this as a priority update rather than something to schedule for the next routine maintenance window, given that exploitation requires no user interaction beyond opening an email.

Because the flaw lives in session-level access, patching alone may not be sufficient if an account was already compromised before the update was applied. Administrators should also consider auditing recent login activity, rotating session tokens, and reissuing 2FA scratch codes for accounts that had access to the Classic UI while the vulnerability was unpatched.

What This Means For You

If you use Zimbra webmail, whether as an individual, a small business, or as part of a larger organization's email infrastructure, this vulnerability is a reminder that authentication tokens and backup codes are only as safe as the software rendering your inbox. Two-factor authentication is a strong defense against password-based attacks, but a stored XSS bug that can lift scratch codes directly from a browser session shows that 2FA isn't a silver bullet if the underlying web client itself is compromised.

For everyday users, the practical risk depends on whether your email provider or IT department runs Zimbra and, specifically, whether the Classic Web Client is still in use. Most people won't need to do anything beyond waiting for their administrator to apply the patch. For administrators and IT teams, though, this is an immediate action item.

Actionable Takeaways

  • Confirm your Zimbra deployment is running ZCS 10.0.18, 10.1.13, or later; anything earlier is exposed to CVE-2025-66376.
  • If your organization still relies on the Classic Web Client, prioritize patching over the modern interface migration timeline you may have planned.
  • After patching, review recent authentication logs for anomalies and consider rotating session tokens for accounts that were active during the exposure window.
  • Reissue 2FA scratch codes for any accounts with signs of suspicious activity, since stolen backup codes can bypass two-factor protections entirely.
  • Treat stored XSS advisories from your email provider as high priority going forward, since this is not the first time Zimbra's legacy client has needed emergency sanitization fixes.

Staying ahead of vulnerabilities like this one comes down to routine patch discipline and knowing exactly which web client your organization actually uses day to day. A few minutes spent confirming your Zimbra version now is far cheaper than recovering from a compromised mailbox later.