Active Exploitation of Gladinet CentreStack and Triofox Local File Inclusion Flaw (CVE-2025-11371)

Update #1: 10/15/25 @ 1pm ET

On October 14, Gladinet released version 16.10.10408.56683 of CentreStack, which includes a fix for the local file inclusion vulnerability outlined below. Huntress recommends that impacted organizations update to the latest build number as soon as possible.

As a patch has now been issued, we are also releasing further analysis of the vulnerability and exploitation activity, as detailed below. The below also includes parts of the original blog, published 10/9/25. 

----------------------------------------------------------------------

TL;DR: Huntress has discovered in-the-wild exploitation of an unauthenticated Local File Inclusion flaw (CVE-2025-11371) in Gladinet CentreStack and Triofox products. As of the initial writing of this blog, a patch was not available in the latest versions of CentreStack and Triofox.

Background

In April 2025, Huntress published its findings on the exploitation of CVE-2025-30406, a critical-severity flaw in Gladinet CentreStack and Triofox products. 

On September 27, 2025, the Huntress SOC received an alert from an internal detector for successful exploitation of Gladinet CentreStack software. However, the version of the software running was later than 16.4.10315.56368, which was no longer vulnerable to CVE-2025-30406. In earlier versions of CentreStack and Triofox vulnerable to CVE-2025-30406, a hardcoded machine key would allow a threat actor to perform remote code execution via a ViewState deserialization vulnerability.

After subsequent analysis, Huntress discovered exploitation of an unauthenticated local file inclusion vulnerability (CVE-2025-11371) that allowed a threat actor to retrieve the machine key from the application Web.config file to perform remote code execution via the aforementioned ViewState deserialization vulnerability.

During our investigation, we saw evidence that Gladinet had engaged with a mutual customer to implement a mitigation. Huntress reached out to Gladinet shortly after this discovery to disclose the flaw, per our standard vulnerability disclosure policy; Gladinet confirmed that it was aware of the vulnerability and was in the process of notifying customers of an immediate workaround. 

Huntress has also notified its own impacted customers of the workaround. We have observed in-the-wild exploitation of this vulnerability impacting three customers so far. As of the initial writing of this blog, a patch was not available in the latest versions of CentreStack and Triofox.

Huntress observations

At 2025-09-26 20:48:37 UTC, the Huntress SOC responded to an internal detector written to detect post-exploitative activity for CVE-2025-30406. As soon as the threat was confirmed, the analyst contained the host, preventing further malicious activity. The detection was based around an irregular base64 payload being executed as a child of a web server process.

Figure 1: Detection timeline for observed exploitation activity

This prompted an investigation into the external communication to the host. From the web servers logs, we were able to tell that the attacker accessed the website via a referrer of hxxps[://]en[.]fofa[.]info/.

FOFA is an internet mapping search engine that provides data on public-facing assets of networks.

The attacker then sent a GET request to the login page /portal/loginpage.aspx, which returned a code 200, as we would expect under normal browsing.

Figure 2: GET requests referred by FOFA as shown in the webserver logs

The attacker then made a post request to the server. This would be how a legitimate user would send credentials to the server. This would result in either a response code of 200 indicating the page has refreshed (wrong password/username) or a code 302 indicating the now logged in user has been redirected to another page.

Figure 3: POST request as shown in the logs

Here is where it gets interesting. The attacker then made an unusual GET request:

GET /storage/t.dn s=..\..\..\Program+Files+(x86)\Gladinet+Cloud+Enterprise\root\Web.config&sid=1

The server responded providing a copy of web.config. This was supported by the code 200 and 1497 bytes of data which is the approximate size of web.config minus the expected overheads.

What happened? Well, the requests to /storage/t.dn are handled by the GladinetStorage.TempDownload function of GSUploadDownloadProxy.dll. This is designed to retrieve files from the temp directory for authenticated users. 

This is unfortunately vulnerable to a Local File Inclusion vulnerability and is exposed externally.

Figure 4: GET request showing exploitation 

Now that the attacker had a copy of the Web.config file containing the machine key, they were able to perform a deserialization attack and begin reconnoitering the host. This was achieved by two sets of base64 encoded payloads containing the ipconfig /all command, which were captured by the application logs Event ID 1316. As the commands were executed blindly, the command output was directed to a text document then the output retrieved by the Local File Inclusion vulnerability.

Decoded base64: ipconfig /all > "C:\programdata\CentreStac_log.txt"

GET /storage/t.dn s=..\..\..\programdata\CentreStac_log.txt&sid=1

Figure 5: More evidence of exploitation in the webserver logs

The attacker was unable to abuse this further as the host was quickly contained.

Figure 6: Event ID 1316 showing the ViewState deserialization attack

Figure 7: Base64 encoded payload contained within the post requests

Vulnerability analysis

The Huntress Hunt and Response team looked into the endpoint with the Local File Inclusion vulnerability and found the vulnerable code inside the class GladinetStorage.TempDownload located within C:\Program Files (x86)\Gladinet Cloud Enterprise\UploadDownloadProxy\bin\GSUploadDownloadProxy.dll.

Figure 8: A view of the ProcessRequest() function within the TempDownload class in GSUploadDownloadProxy.dll

In the above, TempRoot is defined by the function GladPDF.GetTempRoot(). This function retrieves a temporary path and attempts to ensure the folder glad_temp is present.

Figure 9: Code for the GetTempRoot()function

Because Gladinet Cloud Enterprise is running as the NT AUTHORITY\SYSTEM user account, the user’s temporary directory will generally be present at C:\Windows\Temp. This means that including directory traversal characters ..\ will allow the application to retrieve any file relative to C:\Windows\Temp\glad_temp. So for example retrieving the file ..\..\explorer.exe would retrieve the file from C:\Windows\explorer.exe.

Proof of concept

Whilst Huntress is still inclined not to release the proof of concept code for exploiting the original CVE-2025-30406, the below is a 1-liner PowerShell request to retrieve the Web.config file using the above unauthenticated endpoint.

Invoke-WebRequest "http://<IP_ADDRESS_OR_URL>/storage/t.dn?s=..\..\..\Program+Files+(x86)\Gladinet+Cloud+Enterprise\root\Web.config&sid=1"|Select-Object -exp RawContent

Mitigation guidance / What should I do?

We recommend disabling the temp handler within the Web.config file for UploadDownloadProxy located at:

C:\Program Files (x86)\Gladinet Cloud Enterprise\UploadDownloadProxy\Web.config

This will impact some functionality of the platform; however, it will ensure that this vulnerability cannot be exploited until the patch has been applied. 

Figure 10: A visual of the temp handler pointing to t.dn, which can be disabled as a mitigation

Removing the line highlighted above will mitigate the vulnerability.

IOCs