CVE-2025-30406

What it actually does

Gladinet CentreStack through 16.1.10296.56315 uses a hardcoded ASP.NET machineKey in the CentreStack portal configuration. Because the key is shared and knowable, an attacker can generate a validly signed serialized ASP.NET payload, commonly through ViewState or related server-side deserialization paths, and submit it to the portal. The server trusts the payload, deserializes it, and can execute attacker-controlled code in the context of the IIS application pool account. Successful exploitation can lead to remote code execution, web shell deployment, credential theft, file access, lateral movement, and full compromise of the CentreStack server.

Why it matters to the business

This vulnerability allows unauthenticated remote compromise of an internet-facing file-sharing and collaboration platform and is confirmed to have been exploited in the wild. Organizations using affected CentreStack versions face a high likelihood of server takeover, data theft, disruption of file access services, and use of the compromised system as a foothold into the broader network. Because it is listed in CISA KEV with a remediation due date of 2025-04-29 and has a very high EPSS score, remediation should be treated as urgent even if no compromise is currently known.

How an attack unfolds

An attacker first identifies an exposed CentreStack portal running a vulnerable version. Because vulnerable releases used a hardcoded machineKey, the attacker can craft an ASP.NET serialized payload that is correctly protected with the expected cryptographic key. The attacker sends the malicious payload to the portal, often as part of an HTTP POST containing ASP.NET state parameters. The application accepts the payload as trusted and deserializes it server-side, triggering code execution under the IIS worker process. After gaining execution, the attacker may run command interpreters, PowerShell, or living-off-the-land utilities; write a web shell into a web-accessible directory; harvest configuration secrets; dump credentials; enumerate files; and pivot to additional internal systems. Public reporting indicates this vulnerability was exploited in the wild in March 2025, so exposed servers should be investigated for prior compromise, not only patched.

How to fix it

Upgrade Gladinet CentreStack to version 16.4.10315.56368 or later. For systems that cannot be upgraded immediately, remove the hardcoded machineKey from portal\web.config as advised by the vendor so ASP.NET generates unique cryptographic material, then restart IIS/application services and verify the portal functions correctly. Restrict internet exposure to the CentreStack portal wherever possible using VPN, allowlisting, reverse proxy access controls, or web application firewall rules. Rotate secrets that may have been accessible to the CentreStack application, including service account credentials, storage credentials, database credentials, API keys, and integration tokens. Because exploitation is active in the wild, treat patching as necessary but not sufficient: perform compromise assessment before returning systems to normal trust.

How to confirm the fix worked

Confirm the installed CentreStack version is 16.4.10315.56368 or later. Review portal\web.config and verify that a static hardcoded machineKey from vulnerable releases is no longer present; if a machineKey is intentionally configured, ensure it is unique to the deployment and has been rotated after remediation. Restart IIS and validate that the CentreStack portal operates normally after the configuration change. From an external vantage point, verify that the portal is no longer reachable from untrusted networks unless explicitly required. Review IIS access logs for suspicious POST requests containing ASP.NET ViewState fields before and after remediation, and use endpoint telemetry to confirm that IIS worker processes are not spawning shells or administrative utilities.

Typical attack path

1. Scan the internet or target ranges for exposed Gladinet CentreStack portals.
2. Fingerprint the portal version or infer vulnerability from behavior and configuration exposure.
3. Craft a malicious ASP.NET serialized payload using the known hardcoded machineKey.
4. Submit the payload to the CentreStack portal over HTTP or HTTPS, commonly via a POST request containing ASP.NET state fields.
5. Trigger server-side deserialization and execute commands under the IIS application pool identity.
6. Establish persistence by dropping a web shell, scheduled task, service, or startup artifact.
7. Access CentreStack configuration files and stored secrets to expand privileges or access data.
8. Exfiltrate files, credentials, tokens, or configuration data and attempt lateral movement.

How to detect it

Investigate both network and host telemetry. Review IIS access logs for unusual POST requests to CentreStack portal endpoints, especially requests containing ASP.NET state parameters such as __VIEWSTATE or __VIEWSTATEGENERATOR, unusually large form bodies, abnormal user agents, repeated 500 errors, or requests from unfamiliar internet sources shortly before process execution alerts. Review Windows Security, Sysmon, PowerShell, and EDR logs for w3wp.exe spawning command interpreters or administrative tools. Inspect CentreStack web directories for recently created or modified .aspx, .ashx, .asmx, .config, .dll, or script files that do not match the vendor installation. Examine portal\web.config and nearby configuration files for unauthorized changes, added handlers, modified machineKey values, or credential access. Check for evidence of post-exploitation: new local users, new services, scheduled tasks, remote access tools, archive utilities, credential dumping tools, outbound connections to unfamiliar hosts, and large file transfers. Because exploitation was observed in the wild in March 2025, hunting should cover the full period of exposure, not only the time after public disclosure.

• __VIEWSTATE=
• __VIEWSTATEGENERATOR
• __EVENTVALIDATION
• portal\web.config
• <machineKey
• w3wp.exe
• w3wp.exe -> cmd.exe
• w3wp.exe -> powershell.exe
• w3wp.exe -> pwsh.exe
• w3wp.exe -> certutil.exe
• w3wp.exe -> bitsadmin.exe
• w3wp.exe -> mshta.exe
• w3wp.exe -> rundll32.exe
• powershell.exe -enc
• powershell.exe -EncodedCommand
• cmd.exe /c
• certutil.exe -urlcache
• App_Web_*.dll
• .aspx
• .ashx
• System.Web.UI.LosFormatter
• System.Web.UI.ObjectStateFormatter

What your security team should do

• Immediately upgrade all CentreStack deployments to 16.4.10315.56368 or later, prioritizing internet-facing systems.
• If immediate upgrade is not possible, remove the hardcoded machineKey from portal\web.config, restart IIS, and place the portal behind strict network access controls until upgraded.
• Assume exposed vulnerable systems may have been compromised and initiate incident response scoping for activity since at least March 2025.
• Search IIS, Windows Event, EDR, and file system telemetry for web shell creation, suspicious ASP.NET ViewState POSTs, and child processes spawned by w3wp.exe.
• Rotate credentials and secrets accessible to the CentreStack application, including database, storage, service account, and API credentials.
• Hunt for persistence mechanisms such as newly created scheduled tasks, services, startup items, modified web content, and unusual local accounts.
• Add SIEM detections for IIS worker processes launching cmd.exe, powershell.exe, certutil.exe, bitsadmin.exe, mshta.exe, rundll32.exe, or encoded PowerShell commands.
• Restrict CentreStack administrative and portal access to trusted source networks wherever business operations allow.
• Preserve forensic evidence before rebuilding or cleaning compromised servers, including IIS logs, Windows event logs, web directories, configuration files, and EDR process telemetry.
• Track CISA KEV remediation obligations; the listed due date for this issue was 2025-04-29.