CVE-2025-11371 is a files or directories accessible to external parties vulnerability in Gladinet CentreStack and Triofox. CISA added it to the Known Exploited Vulnerabilities catalogue on 4 November 2025, which means attackers have used it in real attacks. Gladinet CentreStack and Triofox contains a files or directories accessible to external parties vulnerability that allows unintended disclosure of system files.
What this vulnerability means in a file-sharing platform
This CVE is dangerous because it exposes files or directories to external parties in products that are often used to store internal documents, shared workspaces and application content. In practice, the security boundary is not just the web interface, but the data underneath it, including system files that should never be reachable by unauthorised users.
Because the issue is about unintended disclosure, the core failure is exposure, not modification. That makes it especially sensitive in products that bridge internal users, remote staff and outside collaborators, since a single access-control mistake can reveal far more than the intended shared content.
How organisations determine exposure
Exposure checks should start with a complete asset inventory, then confirm whether any CentreStack or Triofox instance is deployed, internet reachable, or integrated into workflows that handle sensitive file shares. The key question is whether the vulnerable service is present in a place where an attacker can reach the affected functionality before stronger access controls or network segmentation intervene.
After that, teams should compare deployed instances against vendor advisories and the CISA KEV catalogue rather than relying on generic vulnerability scans alone. For this CVE, the authoritative product and patch details belong with the vendor advisory and CISA, while vulnerability records such as NIST National Vulnerability Database and the official CVE Program help correlate the identifier with internal asset findings.
Remediation and compensating controls
The preferred response is to apply the vendor fix as soon as it is available for the affected deployment. If patching must be delayed, reduce exposure by restricting external access, tightening authentication paths, isolating the file-sharing service from less-trusted networks, and reviewing any sharing rules that may unintentionally widen reach to internal or public users.
Where file access has already been exposed, compensating controls should focus on limiting who can browse directories, how links are shared, and whether sensitive system paths are mounted or mapped into user-facing areas. General vulnerability management discipline also matters here, because KEV-listed flaws should be prioritised ahead of routine backlog items, especially when the product sits on a perimeter or handles regulated data. NHIMG’s Vulnerability Management Guide is useful for aligning asset scope, KEV prioritisation and remediation verification.
Detection and post-incident review
Detection should look for unusual access to directory listings, unexpected retrieval of system files, spikes in anonymous or external requests, and any evidence that content outside the intended share scope was enumerated or downloaded. If exploitation is suspected, the review should go beyond the CVE itself and confirm whether the attacker used the exposure to stage further access, steal configuration data, or collect credentials embedded in files.
After patching, organisations should inspect logs for suspicious requests before the fix was applied and verify that no additional footholds were left behind. In file-sharing incidents, the immediate exposure may be the first step in a broader compromise, so post-patch review should include data-access tracing and a search for follow-on activity, not just a scan for the original vulnerability.
Risk and Threat Considerations
The main risk is unauthorised disclosure of internal files through a system that is often trusted to broker collaboration. In a product that stores shared working data, an externally reachable exposure can quickly become a confidentiality incident, especially if sensitive configuration, scripts or operational documents are stored alongside ordinary content.
Failure mechanism: The application mishandles file- or directory-level access boundaries, allowing an external party to enumerate or retrieve material that should remain internal.
Impact: Attackers can extract sensitive documents, discover internal paths and metadata, and use the leaked material to support broader intrusion, persistence or extortion activity.
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, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest Protection | CVE exposes stored files, so protecting stored data directly applies. |
| DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Detecting unexpected file access requires active monitoring of the exposed service. | |
| RS.MA-01 — The incident is contained | Once exposure is suspected, containment is the immediate response objective. | |
| Recommendation — Protect stored file data with access controls and encryption where exposure is possible. Monitor file-sharing traffic and access logs for abnormal directory and file retrieval. Contain the exposed service and limit further file disclosure while remediation proceeds. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege limits who can reach shared files and directories. |
| SI-2 — Flaw Remediation | This CVE requires prompt remediation of the vulnerable software flaw. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Audit logs are needed to review suspicious file access before and after patching. | |
| Recommendation — Restrict file and directory access to the minimum required subjects and paths. Apply the vendor fix promptly and verify the vulnerable instance is no longer exposed. Review audit records for anomalous directory enumeration and file retrieval activity. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Exposure assessment starts with knowing where CentreStack and Triofox are deployed. |
| CIS-8 — Audit Log Management | Logs are central to detecting external file access and post-exploitation review. | |
| CIS-7 — Continuous Vulnerability Management | KEV-listed vulnerabilities should be prioritised and remediated quickly. | |
| Recommendation — Maintain an accurate asset inventory so vulnerable file-sharing instances are found quickly. Centralise and review logs for external access to directories and file content. Prioritise KEV-listed file-sharing vulnerabilities for accelerated remediation and verification. | ||
| OWASP ASVS | V4 — API and Web Service | The vulnerable exposure occurs through web-accessible file-sharing functionality. |
| Recommendation — Verify web-accessible file services enforce strong authorisation on every object and directory. | ||
Practitioner Guidance
Why practitioners should care: File-sharing platforms are often embedded into everyday business workflows, which means a seemingly narrow exposure can have outsized operational impact. Treat the issue as both a vulnerability-management priority and a data-exposure event when internal content may already have been reachable.
What to watch for: Confirm whether the affected service is internet exposed, whether external sharing is enabled, and whether logs show access to paths that should never have been published. If those signals exist, assume the exposure may have been active before remediation and review for collateral compromise of related accounts, tokens or shared content.