CVE-2026-62901
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
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 Denial of Service (DoS) vulnerability (CVE-2026-62901) has been identified in the WebSocket compression implementation of the System.Net.WebSockets component, which allows a remote, unauthenticated attacker to hang an application's WebSocket receive loop indefinitely. A crafted permessage-deflate message can terminate its DEFLATE stream with a BFINAL=1 final block while leaving compressed bytes unconsumed, after which the inflater makes no further forward progress.
Per CWE-606: Unchecked Input for Loop Condition, the product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.
This issue affects .NET 6. Unlike some other components covered in this release, System.Net.WebSockets is not an opt-in NuGet package on .NET 6 — it ships in-box as part of the Microsoft.NETCore.App shared framework, so any application that accepts WebSocket connections with permessage-deflate negotiated is exposed without adding any package reference. WebSocket permessage-deflate support was introduced in .NET 6, which makes 6.0.0 the earliest affected version.
Details
Module Info
- Product: .NET
- Affected packages: System.Net.WebSockets (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 High-severity vulnerability is found in the System.Net.WebSockets library as shipped in the .NET 6 shared framework. When permessage-deflate is negotiated on a WebSocket connection, WebSocketInflater feeds received bytes to zlib and loops until the message is fully decompressed. The loop's continuation depends on the inflater reporting forward progress, but the end-of-stream condition reported by zlib was never checked:
written = Inflate(_stream, output, FlushCode.NoFlush);
consumed = _available - (int)_stream.AvailIn;
A message whose DEFLATE stream ends with a BFINAL=1 final block, but which still carries compressed bytes after that block, drives zlib to return StreamEnd while bytes remain in the input buffer. zlib will never consume those trailing bytes, so the inflater returns empty results indefinitely: written stays at zero, _available never drains, and the caller's receive loop spins without ever completing the message or surfacing an error. No privileges, no user interaction, and no valid application-level message are required — only a WebSocket connection on which permessage-deflate has been negotiated.
The fixed release threads zlib's end-of-stream signal out of the private Inflate helper and rejects the message when the stream has ended while compressed bytes remain, throwing WebSocketException with the new net_WebSockets_DataAfterBFinal resource string:
if (streamEnded && _available > 0)
{
// zlib reached the end of the DEFLATE stream (a BFINAL=1 final block) while
// compressed bytes still remain that it will never consume.
throw new WebSocketException(SR.net_WebSockets_DataAfterBFinal);
}
This vulnerability has been present since .NET 6.0, the release in which WebSocket permessage-deflate support was introduced.
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 Kevin Gosse and hamayanhamayan for reporting this vulnerability.