CVE-2025-30399

Overview

.NET is a free, open-source, cross-platform framework for building modern apps and powerful cloud services. It consists of a runtime and a developer platform made up of tools, programming languages, and libraries for building many different types of applications.

A Remote Code Execution vulnerability (CVE-2025-30399) has been identified in the .NET native host, which allows an unauthorized attacker to execute code. In component hosting scenarios the host could resolve the runtime library through the platform loader's ambient search order, including the current working directory, rather than from an absolute framework path.

Per CWE-426: Untrusted Search Path, the product searches for critical resources using an externally supplied search path that can point to resources that are not under the product's direct control.

This issue affects .NET 6. The native host ships in-box as part of the Microsoft.NETCore.App shared framework. Exposure is limited to component hosting, through the COM host, the C++/CLI host or the custom component host. Applications launched normally are unaffected, because their host paths are already absolute.

‍

Details

Module Info

• Product: .NET
• Affected packages: .NET native host, hostfxr, hostpolicy and coreclr resolution (ships in the Microsoft.NETCore.App shared framework)
• Affected versions: Microsoft.NETCore.App >= 6.0.0 <= 6.0.44
• GitHub repository: https://github.com/dotnet/runtime
• Published packages: Download .NET (Linux, macOS, and Windows)
• Package manager: NuGet
• Fixed in: NES for .NET 6.0.45

Vulnerability Info

This High-severity vulnerability is found in deps_resolver, the component of hostpolicy that decides where the runtime's own libraries are loaded from. When an application carries no .deps.json, the resolver adds the application directory to the probe set and looks there for coreclr. That fallback also ran under host_mode_t::libhost, the mode used by the COM host, the C++/CLI host and the custom component host, where there is no application and therefore no application directory. The member holding that directory was empty, so the composed library path was relative rather than absolute.

A relative library name is resolved by the platform loader through its ambient search order, which is what turns a missing file into an attacker-controlled one. A user who can write to the working directory of such a process can place a file named as the runtime library and have it loaded into the host process.

The fixed release closes both the specific path and the general class:

• the no-.deps.json fallback is now gated so it does not run in libhost mode, and asserts that an application directory is present when it does
• each of the four sites that loads hostfxr, hostpolicy or coreclr now verifies the path is rooted before loading, and fails with CoreHostLibMissingFailure if it is not

Applicability to .NET 6 was established from source and confirmed against the shipped artifact: the 6.0.44 tree carried the ungated fallback and none of the four rooted-path checks. Microsoft's published affected-version list names only .NET 8 and 9.

‍

Mitigation

.NET 6 is End-of-Life and will not receive any updates to address this issue. For more information see .NET and .NET Core official support policy.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to one of:
  
  • .NET >= 8.0.17
  • .NET >= 9.0.6
• Leverage a commercial support partner like HeroDevs for post-EOL security support, including NES for .NET 6.0.45 or later.

‍

Credits

Microsoft did not publicly credit an individual finder for this vulnerability in its security advisory.