CVE-2025-26646
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
The .NET SDK is the set of libraries and tools used to build and run .NET applications. It bundles MSBuild, the build engine that executes project files and the tasks they invoke.
A Spoofing vulnerability (CVE-2025-26646) has been identified in MSBuild's DownloadFile task, which allows an attacker who controls the responding server to choose the name of the file written to disk. The task took the output filename from the response's Content-Disposition header rather than from the address the project requested.
Per CWE-73: External Control of File Name or Path, the product allows user input to control or influence paths or file names that are used in filesystem operations.
This issue affects the .NET 6 SDK. It is a build-time issue and does not affect the runtime that applications execute on: only projects that use the DownloadFile task are exposed, and the attacker must control or be able to impersonate the server that project downloads from.
Details
Module Info
- Product: .NET SDK
- Affected packages:
Microsoft.Build.Tasks.Core(bundled in the .NET SDK) - Affected versions: Microsoft.Build.Tasks.Core >= 17.0.0 <= 17.8.3, shipped as 17.3.4 in the .NET 6 SDK
- GitHub repository: https://github.com/dotnet/msbuild
- Published packages: Microsoft.Build.Tasks.Core on NuGet
- Package manager: NuGet
- Fixed in: NES for .NET 6.0.45, which bundles
Microsoft.Build.*17.3.4.1 from the HeroDevs feed
Vulnerability Info
This High-severity vulnerability is found in the DownloadFile task's TryGetFileName helper. When the project did not set DestinationFileName explicitly, the task derived the name from the response, preferring the Content-Disposition header's filename and only falling back to the requested address. The header is attacker-controlled data, so the responding server decided the name of the file written into DestinationFolder.
The practical effect is not a traversal out of the destination folder: on .NET 6 an unquoted ../ value is rejected by the header parser, and a quoted one keeps its quote characters and produces an invalid path. What the server can do is rename the download, and so overwrite an existing file in the destination folder. On a build machine that is enough to replace a file the build itself consumes, such as an imported .targets file, which turns a download into build-time code execution on the next run.
The fixed release changes the helper to derive the name from the requested address and removes the Content-Disposition read entirely, so the project rather than the server determines the output name.
Applicability to .NET 6 was established from source and confirmed against the shipped artifact: on the 6.0.44 SDK, a server answering a request for one filename with a Content-Disposition naming another overwrote an existing file in the destination folder.
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 the .NET SDK to one bundling a fixed MSBuild, such as
Microsoft.Build.Tasks.Core>= 17.8.29 or >= 17.10.29. - Set
DestinationFileNameexplicitly on everyDownloadFileinvocation, which takes the choice away from the server. - 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.