Gladinet exploited

Executive summary

Threat actors are actively exploiting a zero-day Local File Inclusion (LFI) vulnerability, tracked as CVE-2025-11371, in Gladinet CentreStack and Triofox. The flaw lets an unauthenticated local attacker read application files (notably Web.config), extract the machine key and chain that to a known ViewState deserialization bug to achieve remote code execution. Gladinet has no patch available yet; mitigations exist that reduce attack surface but can affect some platform features. This post explains the risk, the exploit chain and immediate technical steps.

What happened

• Affected products: Gladinet CentreStack and Triofox (all default installs and versions, including the most recent release).
• Vulnerability type: Local File Inclusion (LFI) allowing retrieval of server-side files without authentication.
• Exploit chain: LFI → read Web.config → extract hardcoded machine key → leverage previous ViewState deserialization vulnerability (CVE-2025-30406) → remote code execution (RCE).
• Real-world activity: Multiple organizations have been targeted; researchers observed attackers extracting machine keys and executing code.
• Vendor status: Gladinet aware; no vendor patch yet. Vendor has begun customer notifications and recommended temporary mitigations.

Technical breakdown (concise, non-encyclopedic)

• LFI root cause: Default installation exposes a temporary handler for the UploadDownloadProxy component that can be reached via crafted requests, allowing arbitrary file reads on the web application context.
• Why Web.config matters: Web.config frequently contains the machineKey element used by ASP.NET to sign/encrypt ViewState and other sensitive artifacts. With the machine key, attackers can forge or tamper with serialized data.
• Chaining the bugs: The attacker first uses LFI to retrieve the machine key, then uses a deserialization/ViewState flaw to run arbitrary code using a forged ViewState payload. The deserialization bug had been observed previously and remains exploitable because of the hardcoded or accessible machine key.
• Impact: Full system compromise of the application host; potential lateral movement if the same credentials or keys are used elsewhere.

Immediate technical actions (for IT teams, ops, and incident responders)

1. Isolate and inspect
   • If you run CentreStack/Triofox, assume compromise until proven otherwise. Isolate affected instances from network segments that hold sensitive data or corporate credentials.
   • Collect evidence: Web server logs, application logs, recent binaries, new scheduled tasks, unusual accounts or services. Preserve logs off-host for analysis.
2. Apply the vendor mitigation now
   • Disable the temp handler used by UploadDownloadProxy by editing the Web.config at: C:\Program Files (x86)\Gladinet Cloud Enterprise\UploadDownloadProxy\Web.config
   • Remove the line that defines the temp handler (it points to t.dn). Removing it disables the vulnerable functionality and prevents LFI exploitation.
   • Restart the service after editing and validate application function critical to users.
3. Hunt for indicators
   • Search for any access that read Web.config, unusual ViewState parameters, or POST requests with large serialized payloads.
   • Look for new files, web shells, unexpected scheduled tasks, or outbound connections to attacker-controlled domains.
4. Credentials and keys
   • Rotate any machineKey values if possible after confirming no active exploitation remains and after patching (or once vendor provides guidance).
   • Rotate service account passwords, API keys, and any credentials used by the affected host; treat them as potentially exposed.
5. Contain and recover
   • If you confirm compromise, rebuild hosts from known-good images; do not simply remove artifacts and leave the system running.
   • Restore data from backups taken before the suspected compromise timeline; validate integrity.
6. Monitoring
   • Increase logging and retention for web/app servers and network egress monitoring.
   • Add IDS/IPS rules to detect LFI patterns and suspicious ViewState deserialization attempts.

Longer-term recommendations and lessons learned

• Inventory and reduce blast radius
  • Maintain an accurate inventory of self-hosted SaaS and file-sharing platforms. Segregate them from domain controllers, identity providers, and critical storage via network segmentation and deny-by-default firewall rules.
• Harden application deployments
  • Avoid default installations and handlers exposed to the internet. Review web.config and equivalent files for unnecessary handlers or endpoints before production go-live.
• Secrets management
  • Do not keep long-lived hardcoded machine keys, encryption keys, or credentials in configuration files; use secret stores or managed key vaults with rotation policies.
• Defense in depth
  • Implement anti-tamper controls, Web Application Firewalls (WAFs) with LFI/Local File Read rules, and runtime application self-protection where practical.
• Incident readiness
  • Test containment and rebuild playbooks regularly. Maintain a forensics checklist and off-host log aggregation for rapid triage.
• Vendor management
  • Require vendors to commit to secure defaults, timely disclosure, and coordinated vulnerability response. Include SLA-backed patching timelines in contracts for critical software.

Key takeaway

If you operate Gladinet CentreStack or Triofox, act now: treat the environment as potentially compromised, apply the Web.config mitigation immediately, hunt for signs of exploitation, and prepare to rebuild affected hosts. This is a classic example of how a small misconfiguration or default handler can cascade into full remote compromise when combined with serialization flaws; the defence is proactive configuration management, secrets hygiene, and tested incident response.