Three confirmed-exploited vulnerabilities across Gladinet CentreStack and Triofox — file-sharing and remote-access platforms built on a shared codebase — show how a hardcoded cryptographic key, an exposed setup page, and an unauthenticated local file inclusion flaw combine into a stepwise path toward full system compromise.
| CVE | CVSS | Product | Issue | Added to KEV |
|---|---|---|---|---|
| CVE-2025-14611 | 9.8 | CentreStack and Triofox | Hardcoded AES cryptographic keys | 15 Dec 2025 |
| CVE-2025-12480 | 9.1 | Triofox | Initial setup pages accessible after setup completes | 12 Nov 2025 |
| CVE-2025-11371 | 7.5 | CentreStack and Triofox | Unauthenticated local file inclusion | 4 Nov 2025 |
Why NVD's own language ties these three together
NVD's description of CVE-2025-14611 does something unusual for a hardcoded-key finding: it states outright that this vulnerability "can be leveraged with previous vulnerabilities to gain a full system compromise." That is a vendor and researcher community explicitly documenting a chain, not three unrelated findings that happen to share a codebase. Read in sequence, the chain makes sense. CVE-2025-11371 is the entry point — an unauthenticated local file inclusion flaw present in the default installation and configuration, letting an attacker read arbitrary system files without any credentials at all, and NVD confirms exploitation of this specific flaw has been observed in the wild. CVE-2025-14611's hardcoded AES keys are exactly the kind of secret an LFI flaw is positioned to expose: if the cryptographic implementation uses the same static key across every deployment, reading it once from any instance means an attacker holds the master key to every instance running the same version. CVE-2025-12480 then supplies a second avenue into the same territory — Triofox's initial setup pages remaining accessible after setup is already complete, which is precisely the kind of administrative surface a hardcoded-key attacker would want reachable.
Why "degrades security for public exposed endpoints" undersells the risk
The KEV description for CVE-2025-14611 uses notably careful, almost understated language — it "degrades security for public exposed endpoints" and "may offer arbitrary local file inclusion." That phrasing reflects genuine uncertainty about the exact exploitation mechanics of a hardcoded-key flaw in isolation. But uncertainty about the standalone impact is different from uncertainty about the combined impact, and the combined impact is stated plainly: full system compromise. Huntress's public research on active exploitation of this vulnerability, cited directly in the CISA references, indicates this is not theoretical chaining risk — it reflects what defenders were actually observing when they added it to KEV within three days of NVD publication, one of the shorter KEV-lag windows in this entire dataset.
What to check this week
- Patch CentreStack and Triofox to version 16.12.10420.56791 or later, which NVD identifies as the fixed version for the hardcoded key issue and supersedes the fix versions for the other two CVEs in this cluster.
- Confirm initial setup pages are inaccessible on any Triofox instance that has completed onboarding — CVE-2025-12480 specifically describes this access persisting after setup, which is not something administrators would typically think to verify post-deployment.
- Review Gladinet hardening guidance directly, including the CentreStack cluster-hardening documentation Gladinet published alongside these disclosures, rather than relying solely on the version bump.
- Treat any internet-facing CentreStack or Triofox instance running a pre-16.12.10420.56791 build as compromised until proven otherwise, given Huntress's documented active exploitation and the short KEV-lag window on the most critical of the three findings.
A closing note on shared-codebase products and shared vulnerability exposure
CentreStack and Triofox share enough underlying code that two of these three CVEs — the hardcoded key and the LFI flaw — affect both product names simultaneously, while the third affects only Triofox. Organizations sometimes treat differently branded products from the same vendor as independent risk surfaces requiring separate tracking, but a shared codebase means a vulnerability discovered against one product name frequently applies to the other under a different label. Asset inventories that track "Triofox" and "CentreStack" as unrelated entries risk missing that a single underlying flaw touches both.
A final consideration on remote-access and file-sharing platforms as ransomware staging ground
File-sharing and remote-access platforms like CentreStack and Triofox sit at a particularly sensitive point in enterprise networks — they are explicitly designed to move files between internal systems and external users, which means a compromise of the platform itself often comes pre-loaded with legitimate-looking pathways for data exfiltration and lateral movement that a more isolated application wouldn't offer. That structural position is worth weighing independently of any single CVE's severity score when deciding how urgently to prioritize this cluster's remediation.
How Safeguard helps
Safeguard's continuous inventory maps CentreStack and Triofox deployments as the shared-codebase risk surface they actually are, correlating version and exposure data across both product names so a chained finding like this one — hardcoded keys plus an unauthenticated LFI plus an exposed setup page — surfaces as one prioritized remediation path rather than three separately scored tickets.
