CVE-2025-48700

What it actually does

This vulnerability is a stored cross-site scripting flaw in the Zimbra Collaboration Classic UI message-rendering path. A specially crafted email containing malformed HTML tag structures, dangerous attribute values, CSS @import content, or related script-injection patterns can bypass insufficient sanitization and execute JavaScript when the message is viewed in the Classic UI. Because the script runs in the victim user's authenticated webmail session, it can read or modify data accessible to that session, perform actions as the user, steal session-related material where browser and application controls allow, redirect the user, or stage additional phishing and mailbox-access activity. The issue requires the victim to view the malicious email but does not require clicking a link or opening an attachment.

Why it matters to the business

Successful exploitation can expose email contents, contacts, calendar data, authentication/session artifacts, and other information available through the webmail session. It can also allow attackers to send messages, create forwarding rules, manipulate mailbox settings, or pivot into broader business email compromise activity. Because this issue is listed in CISA KEV, has active in-the-wild exploitation, and affects internet-facing email infrastructure, organizations should treat remediation as urgent even though the CVSS score is moderate. The CISA remediation due date is 2026-04-23, but exposed systems should be remediated well before that date because email platforms are high-value targets for espionage, credential theft, and fraud.

How an attack unfolds

An attacker sends a crafted email to a Zimbra user whose mailbox is accessed through the Classic UI. The message body contains HTML that abuses weak sanitization, such as crafted tag nesting, malicious attributes, CSS import behavior, or script-like payloads designed to survive the mail-rendering filter. When the recipient opens or previews the message in the Classic UI, the browser renders the sanitized-but-still-dangerous content and executes attacker-controlled JavaScript in the trusted Zimbra origin. The script can then interact with Zimbra webmail APIs and page content using the victim's authenticated session, potentially reading messages, extracting sensitive data, changing mailbox settings, creating persistence through rules or delegated access where permitted, and transmitting stolen data to attacker-controlled infrastructure. In active exploitation scenarios, operators are likely to combine the XSS with phishing, token/session theft attempts, mailbox reconnaissance, and business email compromise workflows.

How to fix it

Upgrade Zimbra Collaboration to a vendor-fixed release or apply the relevant vendor patches for all affected branches, including ZCS 8.8.15, 9.0, 10.0, and 10.1 where applicable. For source/package tracking, ensure the following fixed code revisions or later are included: zimbra/zm-mailbox commit 36b0176b086d3ced0cd751ec0aca4d9869574496, zimbra/zm-zcs-lib commit 544f6ac469b9b633b2d42a8d66b8db8b24043708, and zimbra/zm-build commit 16fcfbde0910368571419d9becd0401a95af6e7f. If using Bitnami-packaged Kyverno where this dependency is present, upgrade to version 1.14.2 or later. As interim risk reduction, disable or restrict Zimbra Classic UI where operationally feasible, encourage use of the modern UI if not affected by the same rendering path, block known malicious HTML patterns at secure email gateways, increase filtering for active content in email bodies, and ensure strong cookie attributes, MFA, and re-authentication controls are enabled. Remove suspicious mailbox rules, delegated access, and unauthorized forwarding settings identified during investigation.

How to confirm the fix worked

Confirm the installed Zimbra build is a vendor-fixed version or contains the fixed commits listed for zm-mailbox, zm-zcs-lib, and zm-build. Validate that all mailbox nodes, proxy nodes, containers, and packaged deployments are updated consistently, not only a single frontend. Review change-management evidence, package versions, git commit identifiers, and vendor patch metadata. Where safe and authorized, test with a benign proof-of-concept email containing inert XSS-like markers and @import-like content to confirm the Classic UI neutralizes the content rather than executing or preserving dangerous attributes. Confirm the Classic UI is disabled or restricted if used as a mitigation. Re-scan externally visible Zimbra services and review response headers and application version leakage to ensure no vulnerable instances remain exposed.

Typical attack path

1. Identify an organization using an affected Zimbra Collaboration version with Classic UI enabled or commonly used.
2. Craft an email containing HTML/CSS/script-injection content that bypasses the vulnerable sanitization logic, including tag/attribute abuse or @import-based payloads.
3. Send the malicious message to targeted users or shared mailboxes.
4. Wait for a user to view or preview the message in the Zimbra Classic UI.
5. Execute JavaScript in the victim's authenticated Zimbra webmail session.
6. Use the victim session to read mailbox data, call webmail endpoints, change settings, create forwarding/filter rules, send email, or exfiltrate sensitive information.
7. Optionally maintain access through mailbox rules, delegated access, stolen credentials, or follow-on phishing from the compromised account.

How to detect it

To determine whether exploitation already occurred, examine raw inbound email messages, secure email gateway logs, Zimbra mailbox logs, Zimbra audit logs, web access logs, proxy logs, and endpoint/browser telemetry for suspicious message rendering followed by abnormal authenticated webmail actions. Hunt for emails containing CSS @import, malformed nested tags, event-handler attributes, javascript: URLs, encoded script content, remote resource loads to unfamiliar domains, or HTML that appears designed to evade sanitization. Correlate receipt and view times of suspicious emails with Zimbra web requests from the same user session, especially SOAP/REST calls that read messages, search mail, export data, modify preferences, create filters, add forwarding addresses, send new messages, or alter delegated access. Review mailbox artifacts for unauthorized filters, forwarding rules, new trusted addresses, unexpected sent mail, deleted security notifications, and unusual login geography or user agents. Because exploitation happens in the user's browser under the Zimbra origin, server-side logs may show legitimate authenticated actions rather than an obvious exploit string; the strongest signals are suspicious email content followed by abnormal mailbox behavior. If threat intelligence is available for campaigns targeting Zimbra, compare remote resource domains, sender infrastructure, subject lines, and payload structures against those indicators.

• @import
• <style
• </style>
• onerror=
• onload=
• onclick=
• onmouseover=
• javascript:
• data:text/html
• data:application/javascript
• eval(
• document.cookie
• localStorage
• sessionStorage
• XMLHttpRequest
• fetch(
• /service/soap
• /service/home/
• CreateFilterRulesRequest
• ModifyFilterRulesRequest
• GetMsgRequest
• SearchRequest
• SendMsgRequest
• ModifyPrefsRequest
• AddMsgRequest
• zmmailbox
• zimbraMailForwardingAddress
• zimbraPrefMailForwardingAddress
• zimbraPrefForwardReplyPrefix
• script src=

What your security team should do

• Prioritize patching or upgrading all affected Zimbra Collaboration systems because the vulnerability is in CISA KEV and exploitation has been observed in the wild.
• Inventory all Zimbra webmail endpoints, including internet-facing proxies, internal-only deployments, lab systems, and packaged/containerized builds.
• Temporarily restrict Classic UI access or steer users to a non-vulnerable interface until patches are confirmed across all nodes.
• Hunt for malicious emails containing @import directives, suspicious HTML attributes, obfuscated JavaScript, or remote resource loads received before remediation.
• Review Zimbra audit, mailbox, nginx/access, and webmail logs for unusual session activity following message views, including abnormal SOAP/REST calls, mailbox export activity, filter changes, and forwarding rule creation.
• Inspect high-risk mailboxes for unauthorized filters, forwarding addresses, delegated access, unfamiliar signatures, sent-message anomalies, and unexpected login locations.
• Reset sessions and consider credential resets for accounts that viewed suspicious messages or show evidence of abnormal mailbox activity.
• Add mail-gateway and SIEM detections for crafted HTML/CSS patterns associated with email-borne XSS, while recognizing that attackers may obfuscate payloads.
• Preserve suspicious messages in raw RFC822/EML form for forensic analysis before deletion or quarantine.
• Track vendor advisories and CISA KEV requirements, with remediation completed before 2026-04-23 at the latest.