CVE-2025-30406: Gladinet CentreStack hard-coded machineKey RCE, exploited as a zero-day
The short version: Gladinet CentreStack (and Triofox) shipped a hard-coded machineKey (CVE-2025-30406). Anyone who knows that key can craft a serialized payload the portal will deserialize — yielding remote code execution. It was exploited as a zero-day in March 2025 and it's in CISA's KEV catalog. Patch and verify. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — unauthenticated RCE, exploited pre-patch |
| CVSS v3.1 (NVD) | 9.0 — Critical · AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H |
| EPSS | ~93.84% · 99th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediate by 2025-04-29 |
| Known exploited? | Yes — exploited in the wild as a zero-day (March 2025) |
| Vulnerability type | CWE-321 / CWE-798 hard-coded cryptographic key → server-side deserialization → remote code execution |
| Requires authenticated session? | No — pre-authentication (attacker needs only the hard-coded key) |
| Affected | CentreStack through 16.1.10296.56315 (Triofox also affected) |
| Fixed in | 16.4.10315.56368 |
What you need to know
ASP.NET applications use a machineKey to sign and protect serialized state such as ViewState. CentreStack shipped the same machineKey in the product, so it's identical across deployments. An attacker who knows that key can forge a validly-signed, malicious serialized object; when the CentreStack portal deserializes it, the attacker's payload runs — remote code execution on the server.
Why it's about as bad as external exposure gets:
- It's the file-server host. Code execution on a CentreStack server reaches the documents and remote-access it brokers, not just one machine.
- It's pre-authentication in effect. The secret that was supposed to gate this is public knowledge, so no login is needed.
- It was live before the fix. Exploitation was observed in the wild in March 2025, before patches were broadly applied.
How serious we see it
Critical.
Unauthenticated, network-reachable code execution on an internet-facing file-access server, confirmed exploited as a zero-day and KEV-listed, is top-of-queue. The bounded, reassuring part is that it's narrow and fixable — specific CentreStack builds, a published fix, and quick to confirm. The catch is the pre-patch window: being patched and being clean are separate questions.
Recommendations
Straight from Gladinet's advisory and CISA:
- Patch now. Upgrade CentreStack to 16.4.10315.56368 or later (and update Triofox to a fixed build).
- Rotate the machineKey. If your version's guidance allows, replace the hard-coded key so a known secret can no longer be abused; rotate other secrets on the host.
- Assume nothing given the zero-day window — hunt. Review for deserialization exploitation and unexpected process execution around and before your patch date.
- If you find indicators, respond fully. Rebuild where warranted and rotate all credentials and keys on the device.
- Confirm your exposure first. Verify whether you run an affected CentreStack/Triofox build.
How BreachRisk sees it
BreachRisk discovers internet-facing CentreStack and Triofox portals from little more than your domain, fingerprints the build, and flags exposure tied to this KEV-listed, actively exploited CVE — surfaced at the top of your results. We detect and flag the exposed, affected version; the value is that a zero-day RCE on a file server is already mapped when it breaks.
That outside-in, continuous view is exactly what you want when a hard-coded-key RCE goes public: you skip the inventory hunt and go straight to patch-and-verify.