Is CVE-2025-66376 (Synacor Zimbra Collaboration Suite (ZCS) Cross-Site Scripting) being exploited in the wild?

Yes. CISA added CVE-2025-66376 to its Known Exploited Vulnerabilities catalogue on 18 March 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Synacor Zimbra Collaboration Suite (ZCS) contains a cross-site scripting vulnerability in the Classic UI where attackers could abuse Cascading Style Sheets (CSS) @import directives in email HTML.

How this XSS becomes an exploitation concern, not just a bug

CVE-2025-66376 matters because the vulnerable surface is the Classic UI rendering path for email HTML, which sits close to user trust, session state, and browser execution. The practical question is not only whether the issue exists, but whether your Zimbra deployment still exposes the Classic UI and whether users can be driven into a malicious email path that executes script-like behavior in a trusted webmail context.

When an XSS flaw is tied to email content, the impact depends on where the browser session lands and what the authenticated user can access after execution. That makes exposure assessment more important than a simple patch-or-not answer, because the same flaw can have very different blast radius across help desks, executives, shared mailboxes, and admin workflows. For email-facing teams, the right first step is to confirm whether the Classic UI is enabled and reachable in production.

The most useful verification is operational: identify the ZCS version in use, review whether the vulnerable UI path is still available, and inspect whether any mail filtering, sanitisation, or content rewriting controls are in place before rendering HTML to end users. If you need the broader response model for vulnerable email and web content paths, the Email Security Guide is the right place to anchor that review, while the Cross-Site Scripting (XSS) Prevention Guide covers the browser-side controls that reduce the chance of successful execution.

What to do if you cannot patch immediately

If patching or upgrading must wait, treat the issue as an exposure management problem, not just a web bug. Restrict access to the Classic UI as tightly as possible, reduce who can open untrusted HTML mail in that interface, and remove avoidable attack surface such as legacy access paths that are no longer required. In parallel, strengthen mail hygiene so malicious content is less likely to reach the vulnerable rendering path.

Because this is an actively exploited vulnerability class, compensating controls should be judged by how much they reduce the chance of a user ever loading the harmful content in a session that matters. That means content filtering, attachment and link scrutiny, and rapid user-facing warning paths are more useful than generic awareness messaging alone. If the environment includes layered mail security, the Web Application Attacks Guide provides useful context on how browser-delivered attacks chain through normal application behavior, and the CISA Known Exploited Vulnerabilities Catalog is the authoritative place to track the remediation expectation attached to a KEV-listed issue.

After any temporary mitigation, verify whether users still need the exposed interface at all. In many ZCS environments, the safest short-term decision is to reduce access to the minimum audience that genuinely requires it, then watch for business exceptions rather than allowing broad exposure by default.

What to check for signs of earlier compromise

For a KEV-listed XSS issue, the concern is not only future exploitation. If the flaw was reachable, review for abnormal mailbox behavior, unexpected session activity, suspicious forwarding rules, unusual changes to preferences, and browser-side symptoms that align with account takeover or script-driven action abuse. XSS often leaves little server-side noise, so you need to combine application logs with user-impact checks.

Look for evidence that a trusted webmail session was used to trigger secondary actions, especially where the attacker could act as the victim without needing a separate password theft step. If you find indicators of misuse, preserve the relevant mail, session, and proxy logs before they roll over, then determine whether the affected account had access to delegated mailboxes, admin functions, or sensitive correspondence that increases the value of the session.

The practical lesson from prior exploited webmail issues is that compromise assessment should focus on post-execution behavior, not only on whether the payload was delivered. That is why the Zero-Day and Exploited Vulnerabilities Guide is useful here, because it frames the need for emergency mitigation and post-patch hunting when exploitation has already moved beyond theory, and the Vulnerability Management Guide helps structure the verification, prioritisation, and remediation evidence you should retain.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events	Monitoring helps detect suspicious webmail activity and post-exploitation behavior.
	PR.PS-01 — Configuration management is performed	Reducing legacy UI exposure and hardening the deployment are configuration controls.
Recommendation — Monitor ZCS web and mail traffic for anomalous rendering, forwarding, and session behavior. Disable unnecessary Classic UI access and harden the exposed mail interface.
OWASP ASVS	V1 Encoding and Sanitization — Encoding and Sanitization	XSS exploitation depends on unsafe handling of attacker-controlled HTML/CSS input.
Recommendation — Apply strict output encoding and HTML sanitization to email-rendered content.
CIS Controls v8	CIS-16 — Application Software Security	Webmail XSS is an application security issue requiring secure design and remediation.
Recommendation — Prioritise remediation of the vulnerable web application path and verify the fix.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Validating and constraining HTML/CSS input reduces XSS opportunities in mail rendering.
Recommendation — Validate and constrain email content before rendering it in the browser.

Practitioner Guidance

What to prioritise: Treat exposure to the Classic UI as the immediate decision point. If that interface is still broadly reachable, your response should assume that exploitation value is already present, even before you prove abuse.

What to verify: Confirm whether any affected mailbox paths are internet-facing, whether users can render attacker-controlled HTML, and whether mail security controls can block or rewrite risky content before it reaches the browser.

Decision rule: If patching is delayed, reduce exposure first, then hunt for compromise. Do not wait for a confirmed malicious message before tightening access, because a KEV listing already raises the operational urgency.

Practitioner takeaway: For this class of flaw, the real question is how much trust the vulnerable webmail path still receives in your environment, because active exploitation turns a rendering bug into a session-abuse and account-risk problem.