CVE-2025-27915

What it actually does

This is a stored cross-site scripting vulnerability in the Zimbra Collaboration Classic Web Client affecting ZCS 9.0, 10.0, and 10.1. The vulnerable client insufficiently sanitizes HTML embedded in calendar invitation content from ICS files. A malicious calendar entry can include JavaScript in an ontoggle event handler inside a <details> element; when a victim opens or views the email/calendar content in the Classic Web Client, the script executes in the victim’s authenticated Zimbra web session. Because execution occurs in the user’s browser with the user’s session context, an attacker can perform actions available to that account, such as modifying mail filters, forwarding or redirecting email, reading exposed mailbox content, stealing CSRF tokens or session-adjacent data accessible to JavaScript, and initiating other authenticated web actions. The issue is known to be exploited in the wild and is listed in CISA KEV with a remediation due date of 2025-10-28.

Why it matters to the business

Successful exploitation can compromise mailbox confidentiality and integrity without requiring the attacker to know the user’s password. A single opened malicious calendar invite or email can let an attacker silently redirect incoming messages, steal sensitive communications, maintain access through malicious mail rules, and support follow-on fraud, espionage, or credential-reset abuse. Because Zimbra often hosts executive, legal, finance, and operational communications, exploitation can create broad business risk including data exposure, account takeover chains, invoice fraud, regulatory notification exposure, and disruption to trusted email workflows. The vulnerability has active in-the-wild exploitation and KEV status, so organizations running affected Zimbra versions should treat remediation and mailbox-rule review as urgent even if EPSS is moderate.

How an attack unfolds

An attacker prepares an email or calendar invitation containing an ICS payload with HTML that abuses inadequate sanitization in the Classic Web Client. The payload places JavaScript in an ontoggle handler within a <details> tag so that when the message or calendar content is rendered by the victim, the browser treats the content as active script rather than inert calendar text. The attacker sends the message to a target Zimbra user. When the victim views the message in the Classic Web Client, the malicious script executes under the victim’s authenticated Zimbra session. The script can then issue same-origin requests to Zimbra web or SOAP endpoints as that user, commonly to create or modify mail filters that redirect future mail to an attacker-controlled mailbox, exfiltrate displayed mailbox data, or perform other unauthorized account actions. Known public reporting describes zero-day exploitation of this Zimbra issue, so defenders should assume targeted exploitation may involve carefully crafted calendar messages, mailbox rule changes, and post-exploitation email collection rather than noisy server-side code execution.

How to fix it

Upgrade Zimbra Collaboration to a vendor-fixed release that contains the sanitization fix for the Classic Web Client. For source-based deployments, ensure zm-build includes commit c099c685055ce0dda8f78a7ecb764482f407f0df and zm-mailbox includes commit f71bb9e0fc4367158daab23460145facb880685b, or a later vendor release containing those changes. If the affected component is packaged through an operating-system vendor, apply the relevant vendor security update; the supplied package data indicates linux-starfive-6.5 for Ubuntu 22.04 LTS fixed in 6.5.0-1016.17~22.04.1, though the primary exposed application risk is Zimbra Collaboration. Until patching is complete, reduce exposure by disabling or restricting the Classic Web Client where feasible, encouraging the Modern Web Client if not affected in the same way, filtering or sanitizing inbound ICS/calendar content at the mail gateway, blocking suspicious HTML event handlers in calendar attachments, and limiting external access to Zimbra web interfaces through VPN or trusted networks. After patching, review existing mailbox filters, forwarding settings, delegated access, and suspicious calendar messages because patching prevents new exploitation but does not remove attacker-created persistence.

How to confirm the fix worked

Confirm the installed Zimbra Collaboration version is a vendor-fixed build for ZCS 9.0, 10.0, or 10.1, or confirm source deployments contain zm-build commit c099c685055ce0dda8f78a7ecb764482f407f0df and zm-mailbox commit f71bb9e0fc4367158daab23460145facb880685b or later. Validate that the Classic Web Client no longer executes JavaScript from ICS content by using a safe, non-exfiltrating test calendar message containing inert event-handler test content and confirming it is rendered as sanitized text or stripped markup. Review mail gateway and Zimbra logs to confirm malicious ICS payloads are blocked or safely delivered after controls are applied. Verify user mailbox settings for unexpected filters, forwarding addresses, account delegates, personas, signatures, and external sharing rules. For internet-facing deployments, perform authenticated and unauthenticated exposure checks to identify Zimbra web interfaces and confirm access controls are intentional.

Typical attack path

1. Identify an organization using Zimbra Collaboration with the Classic Web Client enabled and an affected version of ZCS 9.0, 10.0, or 10.1.
2. Craft a malicious ICS calendar invite or email containing HTML with a <details> element and an ontoggle JavaScript event handler.
3. Send the malicious message or invitation to one or more target users.
4. Wait for a victim to open or preview the message in the Classic Web Client.
5. Execute JavaScript in the victim’s authenticated browser session.
6. Use the victim’s session to call Zimbra web or SOAP functionality, such as creating mail filters, adding forwarding behavior, or accessing mailbox content.
7. Redirect or collect future email, harvest sensitive messages, or use mailbox access for follow-on credential reset, phishing, or business email compromise activity.
8. Remove or hide obvious traces where possible, such as deleting the original message or creating subtle mailbox rules.

How to detect it

Investigate both delivery of malicious calendar content and post-exploitation mailbox changes. Review mail gateway logs, message stores, and quarantine systems for inbound messages or attachments with MIME type text/calendar, .ics filenames, BEGIN:VCALENDAR content, and embedded HTML event handlers such as ontoggle inside <details> tags. Inspect Zimbra logs including /opt/zimbra/log/mailbox.log, /opt/zimbra/log/audit.log, /opt/zimbra/log/access_log.*, /opt/zimbra/log/nginx.access.log, and reverse-proxy or WAF logs for requests made shortly after suspicious message views, especially SOAP or Ajax operations that modify filters, forwarding, account preferences, identities, or delegates. Hunt for ModifyFilterRulesRequest and related filter updates that add redirect, redirectCopy, forward, discard, or external addresses. Compare mailbox filter creation and modification timestamps against delivery or open times for suspicious ICS emails. Examine each mailbox for unexpected rules that forward mail externally, delete or mark messages as read, hide messages from inboxes, or target security, password reset, finance, invoice, payroll, or MFA-related messages. Look for unusual authenticated web activity from new IP addresses, user agents, or geographies following the suspected XSS execution window, but note that the exploit action may originate from the victim’s legitimate browser and IP. If exploitation is suspected, preserve the original malicious email, full headers, ICS attachment, mailbox rule state, web logs, and audit logs before remediation actions overwrite evidence.

• <details
• ontoggle=
• <details ontoggle=
• BEGIN:VCALENDAR
• BEGIN:VEVENT
• text/calendar
• Content-Type: text/calendar
• filename="*.ics"
• ModifyFilterRulesRequest
• CreateFilterRulesRequest
• redirectCopy
• actionRedirect
• actionFileInto
• zimbraPrefMailForwardingAddress
• zimbraMailSieveScript
• /opt/zimbra/log/mailbox.log
• /opt/zimbra/log/audit.log
• /opt/zimbra/log/nginx.access.log
• /opt/zimbra/log/access_log
• /opt/zimbra/store/
• /service/soap
• /zimbra/h/
• /zimbra/m/

What your security team should do

• Treat this as an urgent remediation item because it is in CISA KEV, has active in-the-wild exploitation, and has a KEV due date of 2025-10-28.
• Inventory all Zimbra Collaboration deployments, especially ZCS 9.0, 10.0, and 10.1, and determine whether the Classic Web Client is enabled or externally reachable.
• Patch Zimbra to a vendor-fixed release or confirm inclusion of the fixed zm-build and zm-mailbox commits.
• Temporarily restrict access to Zimbra webmail and disable or limit Classic Web Client use until remediation is complete.
• Search mailboxes and mail gateway logs for suspicious ICS/calendar messages containing HTML tags, event handlers, or <details>/<ontoggle> constructs.
• Audit all user mail filters and forwarding rules for external redirection, newly created rules, hidden discard rules, and suspicious criteria created after likely exposure dates.
• Review Zimbra mailbox, audit, access, and proxy logs for filter modification requests or unusual authenticated activity following calendar-message views.
• Reset sessions for affected or suspicious accounts after patching and after malicious rules are removed.
• Notify high-risk users to report unexpected calendar invites, suspicious message behavior, or missing/forwarded emails.
• Create SIEM detections for inbound calendar content with active HTML event handlers and for Zimbra filter-modification operations that create external forwarding.