Is CVE-2025-68645 (Synacor Zimbra Collaboration Suite (ZCS) PHP Remote File Inclusion) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2025-68645 to its Known Exploited Vulnerabilities catalogue on 22 January 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 PHP remote file inclusion vulnerability that could allow for remote attackers to craft requests to the /h/rest endpoint to influence internal request dispatching, allowing inclusion of arbitrary files from the WebRoot directory.

What “being exploited in the wild” means for a CVE like this

For a CVE question, the key signal is not just that a flaw exists, but that it has moved from theoretical exposure to confirmed attacker use. CISA’s KEV listing is the strongest operational indicator you have here, because it reflects evidence of active exploitation and turns the issue into an urgent exposure-management problem, not a watchlist item.

That matters because remote file inclusion flaws often give an attacker a practical way to control server-side request handling or load unintended server files. Once exploitation is confirmed, the question shifts from “is this real?” to “where is it reachable, what did it expose, and what evidence should we preserve?”

For broader context on actively exploited CVEs, the response model in Zero-Day and Exploited Vulnerabilities Guide is the right operational lens: treat KEV placement as a trigger for emergency validation, mitigation, and post-patch hunting rather than ordinary patch scheduling.

How to confirm exposure and scope impact

Start by confirming whether any internet-facing or internally reachable Zimbra Collaboration Suite instances are present in your estate, including test, legacy, and delegated-managed systems. Then verify whether the vulnerable /h/rest path is exposed through direct service access, reverse proxies, WAF exceptions, or unusual routing rules that might bypass normal perimeter filtering.

If the product is present, look for request patterns consistent with malicious probing against file-inclusion paths, especially unexpected parameters, unusual file references, or repeated attempts to influence request dispatching. Because this is a server-side inclusion issue, exposure can be broader than a single endpoint and may include configuration drift, custom routing, or relaxed file-access controls.

Use the official vulnerability records to confirm the authoritative product and exploitation status. The CISA Known Exploited Vulnerabilities Catalog establishes whether the flaw is in the active exploitation set, while the NIST National Vulnerability Database and the CVE Program provide the canonical record for the identifier and vulnerability description.

What to do if patching or vendor remediation is delayed

If you cannot remediate immediately, focus on containment and visibility. Restrict exposure to the smallest possible set of networks, tighten proxy and firewall rules, and review whether the affected service can be temporarily isolated from untrusted access until the vendor fix is applied.

At the same time, inspect logs for signs of earlier compromise. For a file-inclusion issue, that means looking beyond simple blocked-request counts and searching for suspicious server responses, abnormal file reads, unexpected child processes, webroot changes, or follow-on activity that suggests the attacker used the flaw as an initial foothold.

Where the vulnerable system handles mail, user sessions, or administrative workflows, preserve relevant logs before any reboot or cleanup. If you detect abuse, treat credentials, sessions, and adjacent secrets as potentially exposed and rotate only the material that the investigation shows could have been reached, rather than rotating everything blindly.

Risk and Threat Considerations

Confirmed exploitation of a remote file inclusion flaw is dangerous because it can convert a single exposed web endpoint into unauthorized server-side file access. Once an attacker can influence internal request dispatching, the risk expands from reconnaissance to local file exposure, code execution chains, or persistence mechanisms depending on the surrounding application layout.

Failure mechanism: The attacker sends crafted requests that manipulate the application’s request handling so the server includes or processes unintended files from the webroot or adjacent paths.

Impact: This can expose sensitive configuration, enable deeper intrusion paths, and create a reliable foothold for further compromise if the system is reachable and insufficiently monitored.

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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM-01 — Monitoring for Anomalies and Events	Actively exploited CVEs require monitoring for malicious request patterns and compromise signals.
	RS.MA-01 — Mitigation is Executed	KEV-listed exploitation calls for rapid mitigation and containment of the affected service.
Recommendation — Monitor the exposed ZCS service for anomalous requests and follow-on compromise indicators. Execute containment and remediation for the vulnerable ZCS instance without delay.
NIST SP 800-53 Rev 5	SI-4 — System Monitoring	Exploited web vulnerabilities require telemetry to detect probing, abuse, and post-exploitation activity.
	IR-4 — Incident Handling	Confirmed in-the-wild exploitation changes the issue from patching to incident response and hunting.
Recommendation — Use system monitoring to detect exploitation attempts and abnormal server-side behavior. Invoke incident handling procedures when evidence shows the ZCS flaw has been exploited.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV status makes prioritised vulnerability management essential for this CVE.
Recommendation — Prioritise and remediate the ZCS vulnerability through continuous vulnerability management.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as a remediation priority even if you have not yet observed obvious damage. The first decision is whether the instance is still exposed, because that determines whether you need emergency containment before normal patching workflows.

What to verify: Validate reachability of the vulnerable endpoint, then check for pre-remediation indicators of compromise in web, application, and host telemetry. If the system hosts mail or collaboration data, assume the blast radius may include sensitive content and administrative context.

Decision rule: If the instance is internet-facing or cannot be confidently scoped, move it into an expedited response path with focused hunting and containment. If the instance is internally reachable only, do not downgrade the risk automatically, because lateral exposure can still make exploitation material.

Practitioner takeaway: For a KEV-listed Zimbra RFI flaw, the important question is not whether exploitation is possible, but whether you can still reach, observe, and contain the affected service before an attacker uses it again.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org