Zimbra Webmail XSS: The Crafted Email That Empties the Mailbox

Zimbra shipped Collaboration 10.1.19 on July 7 with a one-line security note: a stored cross-site scripting bug in the Classic Web Client, reported by Google's Threat Analysis Group. No CVE. No CVSS. No proof-of-concept. Just an urgent "upgrade the Classic Web Client as soon as possible" and a version bump. For a mail platform that, by Zimbra's own count, serves hundreds of millions of users across thousands of businesses and hundreds of government agencies, that is not a quiet patch. That is the exact shape of the last Zimbra webmail zero-day that state actors were already exploiting before anyone outside TAG knew it existed.

If you run Zimbra, the interesting question is not "how bad is the XSS." It is "what happens in the 30 days between a silent webmail patch and the day you notice your mailboxes have been read." This post is about that gap, and how to close it.

What Zimbra's webmail XSS patch actually closes

The fix lives in two packages — zimbra-patch and zimbra-mbox-webclient-war — bundled into the Daffodil 10.1.19 release on July 7, 2026. The vulnerability is a stored XSS in the Classic Web Client: a specially crafted email message carries JavaScript that executes inside the recipient's authenticated webmail session when the message is rendered. BleepingComputer's coverage confirms Google TAG as the reporter and notes Zimbra has not (yet) tagged the flaw as exploited in the wild.

Three properties make this worse than a typical XSS:

• It is stored, not reflected. The payload sits in the mailbox. The victim does not have to click a poisoned link — rendering the message is enough. On a webmail preview pane, that is effectively zero-click.
• It runs with the victim's session. JavaScript in the DOM of an authenticated Zimbra session can do anything the user can: read every folder, issue REST/SOAP calls, set filters, and lift the auth token.
• The Classic Web Client is the legacy default that never left. It is the lighter Ajax interface many organizations keep enabled precisely because it is faster on large folders. The Hacker News notes the modern client is not the affected surface — but "we only run the modern client" is a claim most admins have not actually verified per-account.

There is no CVE identifier and no CVSS score in the release notes. Do not read that as "minor." Read it as "you will not get a KEV entry to force your triage, so you have to triage it yourself."

Why Google TAG flagging it is the real signal

TAG does not chase run-of-the-mill web bugs. It tracks exploitation by government-backed attackers, and Zimbra webmail is one of its recurring case files — for a reason. A gov-heavy, self-hosted mail server reachable from the internet is the single richest target an espionage crew can ask for: it holds the correspondence, and webmail XSS lets you take it without dropping a binary an EDR could catch.

The precedent is exact. In 2023, TAG discovered a Zimbra Collaboration XSS zero-day in the wild — later patched as CVE-2023-37580 — and watched four separate groups exploit it against government organizations in Vietnam, Greece, Tunisia and Pakistan. Winter Vivern (UNC4907), an APT with a documented taste for XSS in Zimbra and Roundcube, was one of them. The detail worth burning into memory: Zimbra pushed the hotfix to public GitHub on July 5, 2023, and three of the four groups exploited the bug around and after that push — because a public code fix on a bug with no advisory is a roadmap for anyone watching the repository.

That pattern has not cooled. Per BleepingComputer's reporting, Zimbra flaws were exploited again in the last four months — CVE-2025-66376 tied to APT28 in March, and CVE-2025-48700 with more than 10,500 vulnerable instances still exposed in April. When the same product keeps landing on TAG's desk, the base rate for "this one is already being used" is not low.

The crafted email is not the mailbox exfiltration you'll catch

Here is the operationally important part, and the reason most Zimbra victims learn about the breach from the attacker rather than from a sensor.

The perimeter cannot see the exploit. The malicious email arrives over TLS-encrypted SMTP; your secure email gateway sees a message with no attachment and no macro. The payload only becomes code inside the browser, in the DOM of an already-authenticated session — server-side and network-side, nothing looks anomalous about the delivery. There is no dropper, no PE file, no C2 handshake at the moment of compromise.

What comes next is where the signal actually lives:

Analyst: "The gateway logged the inbound mail as clean. Endpoint saw nothing. So how did they get three ministries' worth of mail?" Reality: "They never touched an endpoint. The token was lifted in-session, and the mailboxes walked out over IMAP and REST — to an ASN this network had never talked to — over the next two weeks."

Post-compromise, a webmail XSS chain follows a stable script that maps cleanly to MITRE ATT&CK:

Stage	ATT&CK technique	What it looks like on the wire
Delivery	T1566 Phishing	Inbound mail, TLS, no attachment — invisible
Execution	T1059.007 JavaScript	In-browser only — no host artifact
Credential access	T1539 Steal Web Session Cookie	Auth-token theft, reused from a new IP/ASN
Collection	T1114.002 Remote Email Collection	Bulk IMAP/REST reads of entire mailboxes
Persistence	T1114.003 Email Forwarding Rule	Silent server-side forwarding/filter rules
Exfiltration	T1041 / T1020	Sustained outbound volume to a never-seen destination

Every row after "Execution" is a network event. The bulk mailbox export, the token replayed from an unfamiliar ASN, the forwarding rule that quietly copies every inbound message — those are exactly the behaviors that leave the endpoint clean and light up the wire. TAG's 2023 write-up said the four groups used the bug "to steal email data, user credentials, and authentication tokens." Nothing about that objective has changed; only the CVE number is missing.

Patch timing is a trap

The no-CVE, TAG-reported combination creates a specific failure mode:

• No KEV entry (yet) means no BOD-driven deadline auto-populating your ticket queue. Under the risk-based tiers of BOD 26-04, a bug only earns a mandated clock once it is cataloged — a silent vendor patch does not.
• No CVSS means your vulnerability-management tooling may not even score it, so it never crosses your severity threshold for emergency change.
• The public version bump telegraphs the fix. As in 2023, the diff between 10.1.18 and 10.1.19 is a starting gun for anyone who wants to reverse the patch faster than your slowest-patching tenant applies it.

The takeaway is not "patch faster" — you already know that. It is that between the patch and full deployment, your only visibility into whether someone got in first is behavioral, on the network, not signature-based on the host.

Remediation

Treat this as an assume-breach exercise, not just a patch ticket. The Classic Web Client has been reachable and vulnerable since long before July 7.

1. Am I affected?

Check your version and whether the Classic Web Client is actually enabled:

su - zimbra
zmcontrol -v                 # anything below 10.1.19 is vulnerable
zmprov gcf zimbraWebClientClassicAppEnabled   # TRUE = the legacy client is live

If zimbraWebClientClassicAppEnabled is TRUE (the default on many upgraded deployments), users can reach the vulnerable interface regardless of which client they "normally" use.

2. Patch — exact fixed version

Upgrade to Zimbra Collaboration 10.1.19 (Daffodil), which ships the fixed zimbra-patch and zimbra-mbox-webclient-war packages. Confirm with zmcontrol -v after restart. Cross-check the Zimbra Security Advisories page for the current release before deploying.

3. Can't patch this hour? — compensating controls

• Disable the Classic Web Client globally until you patch: zmprov mcf zimbraWebClientClassicAppEnabled FALSE, then zmcontrol restart. Users fall back to the modern client, which is not the affected surface.
• Enforce a Content-Security-Policy at the reverse proxy (script-src 'self') so injected inline scripts fail to execute even if the payload lands.
• Verify the header is live: curl -I https://mail.example.com | grep -i content-security-policy.

4. Hunt for compromise

Assume the window was open before you patched. Look for the consequences, not the email:

• Rogue forwarding / filters (T1114.003): audit every account for unexpected forwarding addresses and Sieve rules.

  zmprov ga [email protected] zimbraPrefMailForwardingAddress zimbraMailSieveScript
  

• Anomalous mailbox reads (T1114.002): grep mailbox.log and audit.log for large SearchRequest/export operations, and for IMAP/REST sessions that pull whole folders in bursts.
• Token reuse from new locations (T1539): correlate auth-token use across source IPs/ASNs; a token minted for one office and replayed from a hosting-provider ASN is your smoking gun.
• Egress: sustained outbound volume from the Zimbra host to a destination it has no history of talking to — the exfiltration itself.

5. Eradicate + verify

• Invalidate every active session and force auth-token rotation so any stolen token dies (clearing cached sessions and restarting the mailbox service; rotate credentials for any account showing anomalous access).
• Remove attacker-planted forwarding rules: zmprov ma [email protected] zimbraPrefMailForwardingAddress "".
• Confirm the fix with a benign test: send <script>alert('XSS_TEST')</script> to a test account and open it in the Classic Web Client. Post-patch it must render as inert text, not fire.
• Review the trailing 30 days of audit.log before you declare the incident closed — the compromise likely predates the patch.

Where Zero Hunt fits

The lesson of this bug is a detection lesson: the compromise is invisible at the point of entry and only becomes visible as behavior on the network. That is precisely the gap Zero Hunt's AI Traffic Analysis was built to close. Our proprietary deep-learning model — trained on billions of PCAP sequences, running locally on the appliance GPU at a 2.7+ Gbit/s baseline, with four parallel inference heads (suspicious traffic, malware classification, attack-type identification, application fingerprinting) — watches the wire while the activity is happening. The bulk IMAP/REST export of a mailbox that historically only received mail, an auth token replayed from a never-seen ASN, a sudden sustained egress from a mail host: those are the signatures of an in-progress webmail exfiltration, and they show up on the wire the moment the attacker starts pulling data — not in the next morning's SIEM digest, and not weeks later when a partner tells you your correspondence is for sale.

Ahead of that, the 10-agent generative pentest swarm answers the other half: its Web and Credential agents chain stored-XSS-into-session-theft the way an adversary would, per-target and per-environment, so you find the reachable Classic Web Client and the exploitable session flow before Winter Vivern's successors do. Every offensive skill the swarm uses is backtested in the AI Gym against a corpus of web and exploitation exercises before it ever touches your production estate — and it all runs 100% on-prem, which matters when the asset you are testing is the mail server that holds everything. See the platform overview or get in touch if a silent webmail patch just landed in your change queue.