Critical Zimbra Stored XSS Lets Crafted Emails Execute Code in User Sessions

What Happened

Zimbra has disclosed a critical stored cross-site scripting (XSS) vulnerability in its Classic Web Client. The attack vector is a specially crafted inbound email: a recipient opens the message in the web interface, and malicious JavaScript executes inside their authenticated session — no additional clicks, no downloads, no social engineering beyond the act of reading mail. Because the payload is stored server-side with the email itself, it persists and can fire for every user who opens the same message.

Why It Matters

Zimbra is deployed by thousands of organizations as self-hosted email and collaboration infrastructure — government agencies, ISPs, universities, and enterprises. Email is an inherently uncontrolled attack surface: you cannot gate what arrives in a user's inbox.

Stored XSS inside an authenticated mail session is a severe primitive. From a hijacked session, an attacker can:

• Exfiltrate the full mailbox — contacts, attachments, historical messages
• Install persistent silent forwarding rules — future mail leaves the organization undetected
• Harvest session tokens — enabling continued access after the user logs out
• Impersonate the victim to internal systems that trust the same browser context

Because the trigger is opening an email — normal, expected behavior — detection is hard and user training offers essentially zero protection. Zimbra has historically been a target for state-sponsored actors; CISA has issued prior advisories on in-the-wild Zimbra exploitation. This class of flaw does not stay theoretical for long.

What To Do

1. Patch now — not at next maintenance window. Zimbra has released updates for affected versions. Identify your running version and apply the fix immediately from the Zimbra security advisory.

2. Confirm Classic Web Client status. If you believe your org uses the Modern Web Client only, verify Classic is actually disabled — it often remains accessible via a URL parameter even when it is not the configured default.

3. Invalidate all active sessions post-patch. Any session active before the patch landed may already have a stolen token in attacker hands. Force a full session flush after confirming the fix is applied.

4. Audit for indicators of prior compromise. Review mail server logs for: newly created auto-forward rules pointing to external addresses, login events from unexpected IPs or unusual user-agents, and abnormal outbound SMTP volume that could signal data exfiltration.

5. Restrict webmail access by IP if feasible. If your Zimbra instance is internet-facing and serves a defined user population, a temporary IP allowlist on the webmail interface reduces exposure while you complete the above steps.

The blast radius here scales directly with how many users have Zimbra open in a browser tab right now. Treat this as a same-day patch.