Skip to content
feed: live
>_ 0dayNews
zimbra

Zimbra ships 10.1.19; Google TAG reported the XSS

Zimbra 10.1.19 patches a stored XSS in the Classic Web Client. No CVE yet, no confirmed exploitation — Google TAG reported it, which is the reason to patch now.

fuse Marisol "Fuse" Delgado · Published · 3 min read
share [x] [reddit] [linkedin] [email]

Zimbra released 10.1.19 on 2026-07-07 to close a stored XSS in the Classic Web Client. The vendor grades it High severity, low deployment risk. There is no CVE assigned. There is no CVSS score. Zimbra has not said exploitation has been observed. What is worth acting on: BleepingComputer’s coverage attributes discovery to Google’s Threat Analysis Group. That is the reason to patch this week, not the missing CVE.

What actually changed

Zimbra 10.1.19 fixes a stored cross-site scripting flaw in the Classic Web Client — the older Ajax-based webmail UI that still ships alongside the Modern interface in Zimbra Collaboration Suite. In Zimbra’s own words: “a specially crafted email could run malicious code when the email is opened. If exploited, it could allow access to mailbox information, session data, or account settings.”

The read across that description is session hijack, done inside the user’s own webmail — the attacker’s code is running as the recipient, in their session, against their mailbox. Modern UI is not called out by the vendor. If your organization has moved users to Modern, the exposure narrows, but “we told them to switch” is not the same as “Classic is off in COS.” Check.

Why the reporter matters more than the CVSS gap

TAG’s public track record leans hard toward vulnerabilities that were being used, or about to be used, against real targets — journalists, dissenters, government staff — before disclosure. That does not, on its own, mean this specific Zimbra flaw has been exploited in the wild; Zimbra has not said it has, and the vendor is usually the one to break that news. It does mean the finder had a reason to be looking at Classic Web Client parsing. That is not the same signal as a routine XSS turned up by a bug bounty sweep.

Do not wait for a CVE ID before you touch the patch calendar. There isn’t one yet, and there may not be for weeks.

What to actually do

  • Confirm your ZCS version. zmcontrol -v on the mailboxd host. Anything below 10.1.19 on the 10.1.x train is vulnerable in the Classic Web Client.
  • Upgrade to 10.1.19 per Zimbra’s 10.1.19 release notes. Vendor grades deployment risk as low; a rolling restart across mailbox servers is the mechanical part.
  • Verify Classic Web Client is actually disabled at the class-of-service level for anyone you consider migrated to Modern. Defaulting a preference is not the same as removing the alternate — a user whose COS still permits Classic can still reach it. Set the Classic Web Client feature to off on any COS that no longer needs it.
  • Pull the mailbox audit trail for admin and privileged accounts for the two weeks before the patch date. If a crafted message landed on Classic during that window, the observable trail is usually the account doing something the account holder did not: a filter rule that forwards to an outside address, an OAuth grant to an app nobody uses, an alias that appeared without a ticket. That is the hunt, not payload signatures.
  • If you cannot patch this window, disable Classic Web Client at the COS level and force users onto Modern until the upgrade lands. Zimbra’s advisory does not list a workaround; this is the operationally sensible temporary step, not a fix.

The honest timeline

  • 2026-07-07 — Zimbra publishes 10.1.19 and describes the Classic Web Client stored XSS. Severity High, deployment risk Low. No CVE. No CVSS. No credit line.
  • 2026-07-10 — BleepingComputer reports the flaw, attributes discovery to Google’s Threat Analysis Group, and confirms no CVE has been assigned as of press.
  • Now — still no CVE, still no CVSS, still no vendor confirmation of exploitation. TAG’s involvement is the signal to move anyway.

Patch this before your other Zimbra maintenance this week. The signal is not in the CVSS field the advisory did not fill in — it’s in the credit line the advisory also did not fill in, that a reporter identified separately. That is a different shape from the Progress ShareFile advisory this week, which was operationally incomplete; the Zimbra advisory is operationally complete — vendor, version, component, impact are all named — and the reason to hurry is the finder.

Sourcing

Found this useful? Share it.

share [x] [reddit] [linkedin] [email]