Is CVE-2025-11371 (Gladinet CentreStack and Triofox Files or Directories Accessible to External Parties) being exploited in the wild?

Yes. CISA added CVE-2025-11371 to its Known Exploited Vulnerabilities catalogue on 4 November 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Gladinet CentreStack and Triofox contains a files or directories accessible to external parties vulnerability that allows unintended disclosure of system files.

What “exploited in the wild” means for this CVE

For this question, the practical answer is already established by the KEV listing: CISA treats CVE-2025-11371 as an actively exploited vulnerability, which means defenders should respond as if exploitation is possible now, not only in theory. The key operational question is whether any internet-facing CentreStack or Triofox instance is still exposed and whether the vulnerable file access path was reachable before remediation.

That makes validation more important than debate. If the product is deployed anywhere in your environment, confirm whether it is externally reachable, whether proxy or gateway rules expose the affected functionality, and whether any backups, clones or adjacent environments still run the same code path. Exposure can persist even after a visible fix if an older instance remains in a forgotten segment or a partner-managed installation is still online.

CISA Known Exploited Vulnerabilities Catalog is the authoritative place to confirm KEV status and track remediation expectations, while the vendor advisory should be used for product-specific exposure checks and fix instructions.

Why file or directory disclosure matters operationally

A files or directories accessible to external parties flaw is not just a confidentiality issue in the abstract. When an externally reachable application can disclose system files, attackers may obtain configuration material, internal paths, metadata, deployment details or other content that helps them move from recon to exploitation. In practice, that often turns a single disclosure bug into a broader attack path.

The risk is especially meaningful in products that sit on the edge of file sharing or remote access workflows. If an attacker can read files they should not see, they may identify admin interfaces, service endpoints, hard-coded references, logs, tokens, backup locations or other details that reduce the cost of follow-on compromise. That is why actively exploited exposure bugs often warrant incident-level handling, not routine patch scheduling.

NIST National Vulnerability Database is useful for record-level lookup and product context, while CVE Program gives the canonical identifier and record structure for tracking the flaw across tools and advisories.

How to respond before and after remediation

Assume exposure until you have evidence otherwise. Start by identifying every CentreStack or Triofox deployment, then verify whether it is patched, externally reachable, and logging the relevant requests. If you cannot patch immediately, reduce exposure by removing public access where possible, restricting source IPs, and placing heightened monitoring on the affected service and its logs.

Because disclosure bugs can be chained, also check for signs that the system was accessed before remediation. Look for unusual file retrieval patterns, unexpected downloads, strange directory enumeration, new admin activity, changed configuration files, and any evidence that internal paths or secrets were harvested. If the product stored credentials, session material or configuration secrets in files that may have been exposed, rotate those values as part of the response.

FIRST EPSS can help prioritise follow-up when you are deciding which exposed systems to verify first, especially if multiple internet-facing services are in scope.

Risk and Threat Considerations

Actively exploited disclosure flaws create a two-stage problem: first the vulnerable application reveals something it should not, then that information can support a larger intrusion path. Even if the initial bug does not execute code, it can still materially raise the odds of credential theft, service abuse, lateral movement or targeted follow-on exploitation.

Failure mechanism: The application exposes files or directories to external parties, allowing an unauthorised requester to retrieve system content that should have remained internal. That content may be enough to reveal configuration, identity material, internal structure or other details that reduce the attacker’s effort.

Impact: The organisation may face information disclosure, accelerated exploitation, and a wider compromise path if the exposed material helps attackers identify trusted connections, stored secrets or weakly protected administrative surfaces.

Standards & Framework Alignment

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

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

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require rapid identification and remediation of exposed assets.
Recommendation — Prioritise and verify remediation for every exposed CentreStack or Triofox instance.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This question is about confirming exposure and exploiting a known vulnerability in production.
	SI-2 — Flaw Remediation	The subject is an exploited software flaw that must be remediated promptly.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-exploitation checks depend on log review and anomaly detection.
Recommendation — Scan for affected deployments and validate remediation status before exposure is assumed closed. Apply the vendor fix or mitigation as soon as possible and document the change. Review logs for abnormal file access, directory enumeration, or data retrieval before closing the case.
OWASP ASVS	V14 — Data Protection	The flaw exposes files or directories and may reveal sensitive stored data.
Recommendation — Verify that sensitive files and secrets are not exposed through application paths or download endpoints.

Practitioner Guidance

What to prioritise: Patch or isolate the product first, then verify whether the vulnerable service was reachable from untrusted networks. If the answer is yes, treat the environment as requiring compromise assessment rather than simple maintenance.

What to verify: Confirm whether logs exist for the relevant period, whether anomalous downloads or directory probes occurred, and whether any exposed files could have contained configuration data, secrets or authentication material.

Decision rule: If patching must wait, reduce exposure immediately and increase monitoring; if you find evidence of file access outside normal patterns, escalate to incident response and rotate any material that may have been disclosed.

Practitioner takeaway: For KEV-listed disclosure bugs, the right question is not only whether the CVE is real, but whether it has already changed your trust boundary and your assumptions about what attackers may have learned.