CVE-2024-27443

What it actually does

The vulnerability is a reflected/stored cross-site scripting issue in the Zimbra Collaboration webmail classic user interface CalendarInvite handling path. A crafted email containing a malicious calendar header can bypass input validation and cause attacker-supplied JavaScript to execute when a user views the invitation in the classic webmail interface. The script runs in the victim user’s authenticated browser context, allowing theft or misuse of session-accessible data, unauthorized mailbox actions, message forwarding rule changes, phishing prompts, or further requests to Zimbra endpoints as that user. The flaw requires user interaction but no attacker authentication, has low exploitation complexity, and is known to be exploited in the wild.

Why it matters to the business

Successful exploitation can compromise email accounts, expose sensitive messages and contacts, enable business email compromise activity, and allow attackers to persist through mailbox rules or session abuse. Because this issue is listed in CISA KEV with a remediation due date of 2025-06-09 and has active in-the-wild exploitation, organizations running affected Zimbra webmail deployments should treat it as urgent even though the CVSS score is moderate. The supplied package metadata also references Debian 11 chromium fixed in 108.0.5359.71-2~deb11u1; teams should verify asset inventory because the vulnerability description is for Zimbra Collaboration, while the package data appears browser-related.

How an attack unfolds

An attacker prepares an email invitation containing a specially crafted calendar header with embedded script content. The message is delivered to a target mailbox through normal email delivery paths. When the recipient opens or previews the message in the Zimbra classic webmail interface, the CalendarInvite rendering logic processes the malformed header without sufficient sanitization. The embedded JavaScript executes inside the authenticated Zimbra browser session. From there, the attacker-controlled script can read page-accessible content, issue authenticated requests, alter user settings, create mail filters or forwarding rules, exfiltrate data to an external endpoint, or present credential/session theft prompts. Follow-on activity may resemble legitimate user behavior because requests originate from the victim’s browser session.

How to fix it

Patch affected Zimbra Collaboration deployments to the vendor-fixed release or security patch level that corrects CalendarInvite header sanitization for ZCS 9.0 and 10.0. If immediate patching is not possible, reduce exposure by disabling or restricting the classic webmail interface where feasible, enforcing strong Content Security Policy controls, filtering or sanitizing inbound calendar invites at the mail gateway, blocking active script patterns in text/calendar content, and increasing monitoring for suspicious mailbox rule or preference changes. Validate that internet-facing Zimbra services are not running vulnerable builds. If the affected package data is relevant to a Debian 11 browser fleet rather than the Zimbra service, upgrade chromium to 108.0.5359.71-2~deb11u1 or later; however, do not treat that browser package update as a substitute for applying the applicable Zimbra server-side fix.

How to confirm the fix worked

Confirm the running Zimbra Collaboration version and patch level from administrative tooling and compare it with the vendor advisory for the fixed ZCS 9.0 and 10.0 releases. Verify whether the classic webmail interface remains enabled and reachable. Send a benign test calendar invite containing harmless encoded script-like markers to a non-production or controlled mailbox and confirm the content is rendered inert rather than executed. Review mail gateway and mailbox logs to ensure malicious calendar headers are rejected, sanitized, or safely displayed. For Debian 11 chromium assets, confirm the installed package version is 108.0.5359.71-2~deb11u1 or newer using package inventory or apt policy output. After remediation, retest from an unauthenticated external mail sender path and confirm no JavaScript execution occurs in the webmail session.

Typical attack path

1. Identify an organization using affected Zimbra Collaboration webmail, particularly the classic user interface.
2. Craft a calendar invitation email with a malicious calendar header containing an XSS payload.
3. Send the crafted invite to one or more target users.
4. Wait for a victim to view or preview the invite in the Zimbra classic webmail interface.
5. Execute JavaScript in the victim’s authenticated browser session.
6. Use the victim session to read mailbox data, perform actions through Zimbra web endpoints, change account preferences, or create forwarding/filter rules.
7. Exfiltrate captured data or use the compromised mailbox for further phishing, internal reconnaissance, or business email compromise.

How to detect it

To determine whether exploitation already occurred, review inbound mail logs, raw message stores, Zimbra mailbox logs, audit logs, proxy/access logs, and web server logs for calendar invite messages containing script-like content or encoded HTML in calendar fields. Focus on messages with Content-Type text/calendar, BEGIN:VCALENDAR blocks, and suspicious content in fields such as SUMMARY, DESCRIPTION, LOCATION, ORGANIZER, ATTENDEE, or calendar headers. Correlate delivery and message-view timestamps with subsequent authenticated requests from the recipient’s browser session, especially requests that change preferences, add filters, create forwarding rules, access large volumes of mail, download attachments, or contact unusual external domains. Review /opt/zimbra/log/mailbox.log, /opt/zimbra/log/audit.log, /opt/zimbra/log/access_log*, /opt/zimbra/log/nginx.access.log*, and MTA logs for anomalous activity. Inspect affected mailboxes for unexpected filters, forwarding addresses, delegated access, signatures, auto-replies, sent messages, and recently accessed sensitive messages. Because XSS payloads may be obfuscated, search for URL-encoded, HTML entity-encoded, base64-like, or mixed-case variants of script tags, JavaScript URLs, and browser event-handler attributes. If threat intelligence identifies exploitation of Zimbra CalendarInvite XSS in your telemetry, treat any matching crafted invite plus suspicious post-view account activity as a likely compromise.

• /opt/zimbra/log/mailbox.log
• /opt/zimbra/log/audit.log
• /opt/zimbra/log/access_log
• /opt/zimbra/log/nginx.access.log
• /var/log/zimbra.log
• Content-Type: text/calendar
• BEGIN:VCALENDAR
• CalendarInvite
• <script
• </script>
• javascript:
• onerror=
• onload=
• onclick=
• document.cookie
• window.location
• eval(
• atob(
• ZmCsfeCommand
• ModifyFilterRequest
• CreateMountpointRequest
• ModifyPrefsRequest
• zimbraPrefMailForwardingAddress
• zimbraPrefMailForwardingAddress

What your security team should do

• Prioritize remediation because the vulnerability is in CISA KEV, has active in-the-wild exploitation, and has a KEV due date of 2025-06-09.
• Inventory externally accessible Zimbra Collaboration deployments and identify any ZCS 9.0 or 10.0 instances using the classic webmail interface.
• Apply the vendor Zimbra security update that fixes CalendarInvite header sanitization; separately verify any Debian 11 chromium assets are at 108.0.5359.71-2~deb11u1 or later if that package data applies.
• Temporarily disable or restrict classic webmail access until patching is complete if business operations allow.
• Search historical mail, mailbox, proxy, audit, and access logs for crafted calendar invites and suspicious authenticated actions following invite views.
• Hunt for newly created mailbox forwarding rules, filters, delegated access, changed signatures, OAuth/application tokens, or account preference changes around suspected viewing times.
• Increase mail gateway inspection for text/calendar content containing script tags, event-handler attributes, javascript: URLs, encoded HTML, or external exfiltration URLs.
• Force session invalidation and password reset for accounts with evidence of exploitation or suspicious mailbox changes.
• Treat post-exploitation as potential business email compromise: review sent mail, forwarding, impersonation activity, and external recipient communications.