CVE-2025-68645

What it actually does

This vulnerability is an unauthenticated local file inclusion issue in the Zimbra Collaboration Webmail Classic UI affecting ZCS 10.0 and 10.1. Improper validation of user-controlled parameters handled by the RestFilter servlet allows a remote attacker to send crafted requests to the /h/rest endpoint and manipulate internal request dispatching. The practical result is that files located under the Zimbra WebRoot can be included or exposed through the web application without authentication. Depending on what files are reachable in the WebRoot, this can disclose application resources, configuration-like artifacts, JSPs, static assets, metadata, or other files that may help an attacker chain follow-on attacks.

Why it matters to the business

Successful exploitation can expose sensitive application files from a mail collaboration platform that often holds high-value communications and authentication workflows. Even if the flaw is limited to WebRoot file inclusion, disclosed files can accelerate credential theft, phishing, session abuse, privilege escalation, or development of a more reliable exploit chain. The vulnerability is listed in CISA KEV, has active in-the-wild exploitation, and has a remediation due date of 2026-02-12, so internet-facing Zimbra systems should be treated as urgent patching targets. The EPSS score of 0.31769 indicates meaningful probability of exploitation activity, and the issue has been public for 231 days, increasing the likelihood that exploit patterns are widely known.

How an attack unfolds

An attacker first identifies an internet-accessible Zimbra Collaboration server running the affected Webmail Classic UI on ZCS 10.0 or 10.1. Without logging in, the attacker sends crafted HTTP requests to the /h/rest endpoint with manipulated request parameters intended to influence RestFilter servlet dispatch behavior. If vulnerable, the server processes the attacker-controlled routing or inclusion target and returns content from files under the application WebRoot that should not be directly exposed. The attacker then reviews the disclosed content for application internals, paths, version details, hidden resources, configuration references, or tokens that can support additional exploitation. Because exploitation has been observed in the wild and the vulnerability is in KEV, defenders should assume that exposed systems may have been probed or exploited even if no obvious service disruption occurred.

How to fix it

Upgrade Zimbra Collaboration to a vendor-fixed release for the affected 10.0 and 10.1 branches as soon as possible, prioritizing internet-facing systems. Where building from source or tracking upstream components, ensure zm-mailbox includes commit 6f001741160336733794f909939fcb0b9e59f107, zm-zcs-lib includes commit 42bcab6250f9084ac05d771550755f9401403f65, and zm-build includes commit 1884e94c76d9602c75dff36c9ff9a5ec2224c582. If using distribution packages listed in the advisory data, ensure Debian 12 packages are at least 6.1.37-1 and Debian 13 or 14 packages are at least 6.3.7-1 where applicable. If immediate patching is not possible, restrict access to Zimbra web interfaces through VPN or trusted networks, block suspicious /h/rest request patterns at the reverse proxy or WAF, disable or limit exposure of the Classic UI if operationally feasible, and increase monitoring of Zimbra HTTP access logs. Mitigations should be treated as temporary because the vulnerability is actively exploited and included in KEV.

How to confirm the fix worked

Confirm the installed Zimbra Collaboration version is no longer an affected ZCS 10.0 or 10.1 build and verify vendor patch levels or component commits match the fixed versions. Review package manager output, Zimbra release information, and deployed application artifacts to ensure the patched RestFilter behavior is present across all mailbox nodes. From an unauthenticated test client, verify that crafted requests to /h/rest cannot cause inclusion or disclosure of unintended WebRoot files and return only expected errors or normal application responses. Check reverse proxy, load balancer, and application logs after patching to ensure the server is no longer returning HTTP 200 responses or file contents for suspicious /h/rest requests. In clustered deployments, validate every node rather than relying on a single front-end test.

Typical attack path

1. Scan for externally reachable Zimbra Collaboration web interfaces, especially Webmail Classic UI on ZCS 10.0 or 10.1.
2. Send unauthenticated HTTP requests to /h/rest to determine whether the RestFilter servlet behavior is vulnerable.
3. Manipulate request parameters or path components to trigger internal dispatching to unintended WebRoot files.
4. Retrieve exposed application files or metadata returned by the server.
5. Analyze disclosed files for version information, internal paths, application structure, secrets, or chainable weaknesses.
6. Use the gathered information for follow-on attacks such as targeted credential attacks, session abuse, exploit chaining, or persistence attempts.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs from Zimbra, reverse proxies, load balancers, CDN/WAF layers, and any centralized SIEM for unauthenticated requests to /h/rest. Focus on requests containing path traversal sequences, encoded traversal, WEB-INF, META-INF, .jsp, .xml, .properties, unusual semicolon path parameters, double-encoded characters, or parameters that appear to control dispatching or file inclusion. Prioritize events with HTTP 200, 206, or unusually large response sizes, especially from unknown external IPs, scanners, or repeated sources. On Zimbra hosts, examine /opt/zimbra/log/nginx.access.log, /opt/zimbra/log/mailbox.log, /opt/zimbra/log/audit.log, and reverse proxy logs for RestFilter errors, unexpected file names, or repeated failed and successful /h/rest probes. Correlate suspicious requests with subsequent authentication events, administrator logins, mailbox exports, new web files, abnormal Java or mailboxd behavior, and unexpected outbound network connections. If exploitation is suspected, preserve logs and affected web application directories before remediation, compare WebRoot contents against known-good baselines, and investigate whether disclosed files contained secrets or information useful for lateral movement.

• /h/rest
• GET /h/rest
• POST /h/rest
• /h/rest/..
• /h/rest/%2e%2e
• %2e%2e%2f
• %252e%252e%252f
• ../
• ..%2f
• %2f..%2f
• WEB-INF
• WEB-INF/web.xml
• META-INF
• .jsp
• .properties
• .xml
• RestFilter
• /opt/zimbra/log/nginx.access.log
• /opt/zimbra/log/mailbox.log
• /opt/zimbra/log/audit.log

What your security team should do

• Immediately inventory all internet-facing Zimbra Collaboration servers and identify any ZCS 10.0 or 10.1 deployments using Webmail Classic UI.
• Patch or upgrade affected systems before the KEV due date of 2026-02-12, with emergency priority for externally reachable servers.
• Run retrospective threat hunting for /h/rest exploitation attempts across Zimbra access logs, reverse proxy logs, WAF logs, and EDR telemetry.
• Temporarily restrict external access to Zimbra web endpoints to trusted networks or VPN until patching is complete.
• Deploy WAF or reverse-proxy detections for suspicious /h/rest requests containing traversal, encoded traversal, WEB-INF, META-INF, JSP, properties, XML, or unusual dispatch-like parameters.
• After patching, rotate any credentials, tokens, or secrets that may have been exposed if logs show successful suspicious file retrieval.
• Monitor for follow-on activity including abnormal mailbox access, new administrative sessions, unexpected web files, suspicious child processes, or outbound connections from Zimbra servers.