The year in .NET Security

At .NET Conf this year I got the opportunity to breakdown the year in .NET CVEs, including the code that caused the vulnerability, the fixes, and links to the GitHub PRs or commits that fixed the issues.

If you don't want to watch the video, I've detailed everything here.

This year (we take a year in .NET as from November to November as that's our release cadence) saw 84 potential vulnerability reports to MSRC, which culminated in 12 CVEs and a total bounty payout for the year of $93,000.

We had a total of 9 CVEs for .NET and 3 for ASP.NET. These broke down to 4 Remote Code Execution vulnerabilities, 3 Elevation of Privilege vulnerabilities, 2 Denial-of-Service vulnerabilities, 1 Spoofing vulnerability, 1 Information Disclosure vulnerability and 1 Security Feature Bypass vulnerability. In terms of scoring we had 1 medium CVSS score, 9 high and 2 critical.

Note that the commit author in the fixes linked below cannot, and should not, be assumed to be the vulnerability author.

.NET CVEs

CVE-2025-55248 was an information disclosure vulnerability in .NET's SMTP client where, even if you had set UseSSL to true .NET would allow connections to SMTP servers which did not support TLS. The fix added a check for the UseSSL setting in the fallback back for servers not supporting EHLO.

CVE-2025-55247 was a potential Denial-of-Service against MSBuild on Linux. This was due to the use of a predictable temp directory, where an attacker could create the directory in advance, setting permissions to block access, at which point MSBuild would exit. This is possible due to the difference in temp directory permissions on Linux, where the temp directory is world writeable, unlike on Windows where the temp directory is a per user directory. The fix switched the API used to build the temp path from File.GetTempPath() to Directory.CreateTempSubdirectory() which creates a subdirectory under the temp directory which is ACLed to the process user alone.

CVE-2025-30399 was a Remote Code Execution attack due to a fallback code path in how the CLR loads assemblies when it's hosted by non-.NET applications. If there was no deps.json file present the CLR would attempt to itself using the application working directory rather than the trusted install directories, so an attacker could drop an assembly alongside application code, with suitable entry points and gain code execution as the user. What made this a remote code execution vulnerability is the potential for applications to be stored on, and started from, network shares. The fix removed the fallback path.

CVE-2025-26646 was a Spoofing Vulnerability in MSBuild's DownloadFile task. Typically, a user of MSBuild specifies the file name they want the DownloadFile task to save the downloaded file as, however MSBuild used the Content-Disposition header to specify the file name, so a server under an attacker's control could specify a file name which MSBuild would use. The fix was to ignore the Content-Disposition header, and if a filename was not specified it would be derived from the URL to the file, which is always specified by the developer.

CVE-2025-211713 was an Elevation of Privilege attack in NuGet restore, again due to the use of temporary directories on Linux. This time an attacker on the machine could watch and wait for the creation of a deps.json file in the temp directory and add their own paths to dependencies in the file, which would get restored in place of packages from a configured source server. Once again, the fix was to switch to use Directory.CreateTempSubdirectory().

CVE-2025-21172 was a remote code execution in a dependency we take from our partners in the debugging team. The Microsoft Debug Interface Access SDK (MSDIA) is used by .NET to enhance stack traces. MSDIA had an RCE (it's closed source, so no fix link here) and the fix, for us, was to take an updated dependency.

CVE-2025-21771 was a buffer overflow in Convert.ToHexString(). Convert.ToHexString() uses unsafe code and calculated a buffer length incorrectly, leading to an attacker having the ability to cause an application to access code it shouldn't be able to access. The fix, provided by a community member who discovered the problem was correcting the length calculation.

CVE-2024-43498 and CVE-2024-43498 were Remote Code Execution and Denial-of-Service vulnerabilities in the .NET Remoting Binary Format reader. CVE-2024-43498 was a type confusion bug in its multi-dimensional array reader, where a bad assumption around the types that could be present lead to a memory access violation. CVE-20240-43499 was a denial-of-service attack not unlike the "Billion Laughs" attack, where an attacker could specify a jagged array in a document passed to the NRBF reader, and with a 90-byte payload cause the reader to allocate 50Gb of memory. The fixes here removed the type assumption and replaced it with a type check and rewrote the jagged array handling.

ASP.NET Core CVEs

CVE-2025-24070 was an Elevation of Privilege vulnerability. We had made the design decision that when we sent an email change confirmation link we wouldn't require an ASP.NET Identity user to login, rather we'd do it for them. This meant that if an attacker had access to a victim's email, and the victim changed their email address, causing the confirmation link to be sent, an attacker could use the link to authenticate as the user once. The fix changed that design decision to require a user authenticate first before the email change link was processed.

CVE-2025-26682 was a Denial-of-Service attack in the style of a Slowloris attack. In our parsing of HTTP/3 frame data we didn't process the frame until it was completely sent, meaning an attacker could, for example, start multiple frames saying they were going to send 100Mb, and never complete the frame, meaning the 100Mb would allocate and remain allocated. The fix added better support for partial frames, allocating memory as frame information arrived.

CVE-2025-55315 was a Security Feature Bypass due to an HTTP Request Smuggling attack in the HTTP parser's handling of chunk extensions. The actual effect of the attack would be application dependent, and Microsoft's policy is to score against the worst possible case scenario, giving this CVE a 9.9 score. The fix was to tighten the parsing of chunk extensions, rejecting non-compliant requests.

Wrapping up

Hopefully this gives you some insight into what caused our CVEs this year. Some take aways for you as a .NET developer would be

• If you're writing .NET applications that run on Linux review your code for File.GetTempPath() use and replacing it with Directory.CreateTempSubdirectory().
• If you're using unsafe code evaluate if you still need it, .NET gets a lot of performance improvements every year, and the reasons you originally needed it for may no longer hold true.
• Treat your inputs as untrusted.

Please remember .NET has a bug bounty, which includes docs and samples. However, I cannot make a bounty payment if you report the vulnerability via GitHub issues, instead please send your reports to MSRC.