CVE-2026-62899

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 request smuggling vulnerability (CVE-2026-62899) has been identified in the managed HttpListener implementation of the System.Net.HttpListener component, which allows an unauthorized attacker to bypass a security feature over a network. The managed listener accepted Content-Length values that the Windows HTTP.sys parser rejects, and silently coerced some out-of-range values to zero.

Per CWE-444: Inconsistent Interpretation of HTTP Requests, when a product acts as an intermediary between an upstream and downstream component, and the two components interpret the same HTTP request differently, an attacker can craft a request that is parsed inconsistently — allowing them to smuggle a second request past a security control.

This issue affects .NET 6. System.Net.HttpListener ships in-box as part of the Microsoft.NETCore.App shared framework. Note that the managed implementation is used on non-Windows platforms only — on Windows, HttpListener is backed by HTTP.sys, whose parser already rejected these values. Exposure is therefore limited to applications hosting HttpListener on Linux and macOS.

‍

Details

Module Info

• Product: .NET
• Affected packages: System.Net.HttpListener (ships in the Microsoft.NETCore.App shared framework)
• Affected versions: Microsoft.NETCore.App >= 6.0.0 <= 6.0.43
• 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.44

Vulnerability Info

This Medium-severity vulnerability is found in the managed HttpListener as shipped in the .NET 6 shared framework. When a request header is added, the listener parsed the Content-Length value permissively: signs, surrounding whitespace and digit separators were tolerated, and a value that overflowed the signed 64-bit range was coerced rather than rejected.

The practical consequence is a body-boundary disagreement. A Content-Length between long.MaxValue + 1 and ulong.MaxValue parsed to 0, so a request declaring an enormous body was processed as having no body at all. Any bytes the attacker appended after the headers were then interpreted by the listener as the start of a new request, while an upstream proxy or load balancer — parsing the same header correctly — treated them as body content belonging to the first. That divergence is the classic request-smuggling primitive: a second, attacker-controlled request crosses a boundary that front-end security controls believe they have already inspected.

The fixed release parses strictly and fails closed:

long.TryParse(headerValue, NumberStyles.None, CultureInfo.InvariantCulture, out long parsedContentLength)

NumberStyles.None rejects leading signs, whitespace and group separators outright, and a parse failure now rejects the request instead of falling through to a default. Because a leading '-' can no longer parse at all, the subsequent parsedContentLength < 0 check became unreachable and was removed.

Applicability to .NET 6 was confirmed directly against the 6.0.43 source, which carried the pre-fix parser verbatim.

‍

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.30
  • .NET >= 9.0.19
  • .NET >= 10.0.11
• Leverage a commercial support partner like HeroDevs for post-EOL security support, including NES for .NET 6.0.44 or later.

‍

Credits

Microsoft credits Miha Zupan with Microsoft for reporting this vulnerability.