CISOs running Gladinet’s CentreStack file server or Triofox file sharing server should update the applications as soon as possible because of a hard-coded key vulnerability which is being exploited now, say researchers at Huntress.
“Immediate action is essential.” John Hammond, principal security researcher at Huntress, said in an email to CSO.
“If left unpatched, it opens the door to data breaches and system compromise with minimal effort.”
The vulnerability, CVE-2025-30406, is so bad that it was added to the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities Catalog on April 8. Since then, Huntress has seen seven organizations compromised through this hole.
According to MITRE, the vulnerability has been exploited since March.
CVE-2025-30406 ranks as a critical severity vulnerability, Hammond added. “Simply, the server being accessible is the only requirement for it to be exploited. Vulnerable Gladinet CentreStack or Triofox instances are susceptible to this via their own sensitive cryptographic keys, which are hardcoded in the application and unchanged by default. These keys are trivial to obtain, and once an adversary knows what the values are, it is ‘point and shoot’ open season for exposed servers.”
“There are a few hundred vulnerable servers exposed to the public internet, according to Shodan,” Hammond wrote in a blog earlier this week. “While this may be a relatively small number, the risk of immediate compromise is still severe.”
The bulk of those servers are in the US and Canada.
Vulnerable are Gladinet CentreStack versions up to 16.1.10296.56315; the hole has been fixed in version 16.4.10315.56368. All versions of Triofox below 16.4.10317.56372 are vulnerable. And, said the blog, “If a Gladinet CentreStack or Triofox server is exposed to the internet with these hardcoded keys, it is in immediate danger and needs to be patched or have the machineKey values changed as soon as possible.”
According to Hammond, the CentreStack web portal is an ASPX application and uses the typical web.config file in this installation path: C:Program Files (x86)Gladinet Cloud Enterpriserootweb.config, although it has also been seen in this path as well: C:Program Files (x86)Gladinet Cloud Enterpriseportalweb.config.
Similarly, Triofox web.config files could be in two locations: C:Program Files (x86)Triofoxrootweb.config and C:Program Files (x86)Triofoxportalweb.config.
The weakness can be leveraged to abuse the ASPX ViewState, a mechanism used to preserve the state of a web page and its controls between multiple HTTP requests, says the Huntress blog. The hardcoded keys open the door for a very standard and well-researched attack technique with ViewState deserialization.
“To be clear,” the blog added, “there may be two web.config files (one in root and one in portal directories) as this is a very common setup in ASP.NET applications. There is a root web app, and nested sub-applications.”
To patch or mitigate the risk, says Huntress, “if both web.config files are present, both must have updated machineKey values, or the portalweb.config machineKey can be removed. The official Gladinet updates the rootweb.config file but removes the machineKey entry from portalweb.config. “This is a very important nuance because all configuration files must make sure they do not use the default hardcoded key value in order to be fully protected,” said the blog.
Gladinet’s security advisories for CentreStack and Triofox provide further remediation guidance.
Hard to defend against attacks
Roger Grimes, data driven defense analyst at KnowBe4, said in an email that hard-coded credential vulnerabilities are hard to build a defense around unless the vendor can release a fix, although, he added, an IT admin can might be able to remove the device from their network until it is fixed, or block remote access to the impacted device until it is remediated.
“What frustrates me is that hard-coded credentials are probably the easiest type of code vulnerability that anyone could think of. It’s very basic and easy to see that it’s wrong and an accident just waiting to happen. Yet I’ve seen a few of them announced in the last week or two.
Programmers not properly trained
How can programmers make this type of basic mistake?
For starters, Grimes said, they aren’t trained not to do it. “Almost no programming curriculum in the world (for example, university, technical school, online, etc.) teaches secure programming,” he said. “And if we don’t teach our programmers about common vulnerabilities and how to avoid them, how can we magically expect them not to put them in their code? If you look at how we taught our programmers, you would expect to see the result we are getting today… which is over 40,200 separate vulnerabilities a year and growing. And the source reason of why we don’t teach programmers to code more securely is that almost no employer asks their programmers to have secure programming skills to get hired. If employers aren’t requiring it, schools aren’t going to teach it.”
“If you don’t like the sheer number of hard-coded credentials still happening today, just relax,” he added. “There are, for sure, 1,000 programmers also putting hard-coded credentials into their apps every day and we will only find out about a very small percentage of them over time. The rest will live without being discovered, or it will be discovered that the attacker using them isn’t announcing it to the world anytime soon.”
No Responses