CVE-2025-30406: Investigating a CVSS Score That Didn’t Add Up

TLDR

CVE-2025-30406 is a very serious vulnerability. If you are running Gladinet CentreStack version 16.4.10315.56368 or lower, or Gladinet Triofox below 16.4.10317.56372 you should update immediately. Thanks to Huntress, whose defensive research identified that Triofox was also vulnerable - this wasn't mentioned in the original disclosure!

Intro

A vulnerability in a Gladinet file transfer application CentreStack, CVE-2025-30406, appeared on our radar recently as it was added to CISA's KEV catalog. This means that it has been seen actively exploited by attackers.

The NVD description for the vulnerability contained an interesting line:

This enables threat actors (who know the machineKey) to serialize a payload for server-side deserialization

This is… confusing. The wording 'who know the machineKey' could imply that some secret knowledge is required to exploit this vulnerability - and yet, an attacker has exploited it.

Our security team decided to investigate further to determine how they obtained the keys and what the real impact is to our customers. We also wanted to determine why the vendor report has a CVSS of 9.0, while NVD rated it a 9.8, and we wanted to deploy a reliable vulnerability check for this weakness as soon as possible, so Intruder customers can check if they are vulnerable.

Obtaining The Machine Keys

Thankfully, Gladinet make it fairly simple to install older versions of the software. From the release history we downloaded a vulnerable version, 16.1.10296.56315. This consists of a GUI installation tool which will set up the application on a clean Windows server, along with all the dependencies it needs.

Once this is complete, in the directory C:\Program Files (x86)\Gladinet Cloud Enterprise we can find directories for the various applications that make up the suite, most of which being ASP.Net web applications that have been deployed using IIS.

Many of these directories contain web.config which is the IIS & ASP.Net configuration file. For instance, within the portal directory, which holds the main web portal, we can see the following:

And... there is our hardcoded key. Rather than generate a new key for each customer (which the fixed version now does), the installer is using the key from this configuration file for every instance. But what can an attacker do with this?

Exploitation

These keys are used to encrypt and/or sign the ViewState, which is a mechanism ASP.Net uses to keep track of information between pages. Since HTTP is a stateless protocol, when changing pages, information entered into form fields would be lost. The ViewState keeps track of this information in a hidden field that is posted back to the server when the form is submitted.

As the ViewState stores serialized objects, this can be used to gain control over the application unless the application protects the user from editing it and submitting a malicious object. This is a well-researched attack that is usually prevented by signing the ViewState - the server won't accept one that has been modified outside the application. With the keys, however, an attacker can sign any object they want using a tool such as ysoserial.net.

We tested this with the following ysoserial.net command, creating a ViewState which will call back to a server we control with a shell when it is unserialized:

.\ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "<PAYLOAD HERE>" --decryptionalg="AES" --decryptionkey="<REDACTED>" --validationalg="HMACSHA256" --validationkey="<REDACTED>" --generator="154E5B92"

And then, after capturing a valid forgotten password request from the application, replaced the ViewState with our malicious payload:

And so confirming that this indeed does cause the server to connect back with a shell as the “iis appool\portal” user:

There are some additional challenges to overcome, to ensure that the exploit isn't flagged by Defender, and making sure the correct generator, gadget and algorithm is correct, and using a working version of ysoserial - but including those would take away the fun of figuring this out for yourself!

Conclusion

This is a very serious vulnerability that should have been rated 9.8 (as NVD did) rather than 9.0. The cynical reader might assume that the vendor downplayed the vulnerability by unfairly abusing the attack complexity vector to reduce the CVSS, paired with adding to the description some doubt over how obtainable the machine keys were - but we haven't seen evidence that would prove that is what happened.

It is trivial for an attacker to gain a remote shell, and the 'secret' that is required is easily available in public releases of the software. If you haven't updated already, you should consider that your host is likely already compromised, and alongside patching, use the information provided by Huntress in their post to investigate further.

At Intruder, we deployed an active check for this weakness on April 15th, which uses a benign payload to determine whether the server will accept the hardcoded keys without executing code.

Users on our Enterprise plan were scanned for this as soon as it was available, and notified if vulnerable. We also have a check for this weakness available on our Cloud plan, which uses the Project Discovery check. This check is publicly available and uses a different detection method.

If you're unsure whether you're affected, start a free trial of our Cloud plan and scan your environment today.