
Hackers are actively exploiting a zero-day vulnerability to compromise secure Gladinet CentreStack file-sharing servers. According to a security advisory from Gladinet, the flaw stems from improper handling of cryptographic keys responsible for maintaining the integrity of ASP.NET ViewState data. When misconfigured—or when a static machineKey
is used in the web.config
file—there exists the potential for ViewState tampering, enabling unauthorized actions impersonating legitimate users, and in some cases, leading to remote code execution (RCE) on the server.
Designated as CVE-2025-30406 and carrying a CVSS score of 9.8, the vulnerability lies in the ability of attackers to predict or extract the machineKey
used to sign ViewState. Once obtained, an attacker can craft a malicious ViewState payload that passes authentication checks and is interpreted by the server as valid. Under certain IIS and ASP.NET configurations, this can trigger deserialization, allowing arbitrary code execution on the host system.
Threat actors have already begun leveraging this zero-day in live attacks. Gladinet strongly advises users to update to the secure CentreStack build 16.4.10315.56368, which introduces automatic generation of a unique machineKey
during installation—eliminating the risk of predictable or reused keys. The installation package is available via direct download and is fully compatible with existing deployments.
For those unable to apply the patch immediately, a temporary mitigation is available: manual rotation of the machineKey
. This involves using IIS Manager to generate a new key, updating the web.config
files accordingly, and synchronizing the new key across all nodes in clustered environments. Additionally, the legacy machineKey
entry in the portal\web.config
file must be removed to prevent configuration conflicts. The procedure concludes with a restart of IIS to apply the new settings.
Gladinet has also published an official guide outlining best practices for securing CentreStack deployments. This includes key generation instructions and recommendations to avoid storing sensitive data in plain text, thereby minimizing potential risks even in unpatched environments.
For multi-server configurations, it is critical that all nodes share an identical cryptographic key. Once generated on the primary node, the key must be manually copied to the corresponding configuration files on all other nodes. Failure to do so may result in ViewState authentication errors and overall application instability.