CVE-2026-50651: Denial of Service via Uncontrolled Resource Allocation in .NET System.Net.Http

The System.Net.Http namespace handles the core outbound network communication libraries within the .NET runtime, facilitating robust protocol exchanges including HTTP/1.1 and HTTP/2. The HTTP/2 implementation uses state machines to track concurrent, multiplexed logical streams over a single TCP connection. This complex design shifts a heavy resource-management burden onto the client application.

Under CVE-2026-50651, the .NET client application exposes an attack surface when establishing connection sequences with untrusted or compromised external servers. This vulnerability belongs to the CWE-770 class, representing uncontrolled resource allocation without limits or throttling.

When a client connects to an adversarial server, the server can exploit this implementation flaw to force boundless allocation of heap memory. The lack of strict containment limits inside the connection handling module results in process-level resource exhaustion, causing the client application to crash.

The vulnerability stems from the absence of global and cumulative resource constraints within the Http2Connection and Http2Stream components of System.Net.Http. When an application initiates a session, the connection manager handles several asynchronous streams, decompressing headers and queuing control frames dynamically.

The first critical flaw lies in the handling of outbound response queues for HTTP/2 control frames. Certain frames, such as PING and SETTINGS, require immediate ACK responses. If a server floods the client with these control frames and simultaneously throttles the TCP connection, the client continues to allocate memory to append outgoing ACK responses to its internal write queue, leading to unbounded memory inflation.

The second major vulnerability vector relates to HPACK decompressor state management and header processing. When parsing incoming HEADER and CONTINUATION frames, the decompressor processes instructions to dynamically adjust the HPACK table state. In vulnerable .NET versions, the client does not enforce strict cumulative length restrictions on split continuation frame sequences, which allows an attacker to stream an endless series of CONTINUATION frames that consume increasingly larger buffers on the heap.

Finally, the connection parser handles canceled or reset streams inefficiently. If a request is aborted, the socket reader must still consume trailing data sent by the server. Instead of reading and discarding this data directly from the network stream, the parser allocates intermediate buffers to parse the discarded bytes, placing extreme pressure on the Garbage Collector.

The resolution of CVE-2026-50651 involved implementing strict thresholds inside the frame processing loop of Http2Connection.cs and Http2Stream.cs in the .NET runtime repository.

To prevent outbound control frame accumulation, the patch limits the queue depth for pending ACK responses. When processing control frames like PING, the connection state now validates the active length of the outbound write queue before accepting additional data:

// Conceptual representation of the fixed queue tracking
private void QueueAckFrame(Http2Frame frame)
{
    // Check if pending control frame ACK queue has reached safety threshold
    if (_pendingAckQueue.Count >= MaxPendingControlAckQueueDepth)
    {
        // Abort the connection immediately to prevent OOM
        throw new Http2ConnectionException(
            Http2Error.ProtocolError, 
            'Excessive pending control ACKs queued'
        );
    }
    
    _pendingAckQueue.Enqueue(frame);
    TriggerWriteLoop();
}

Additionally, HPACK decompression and continuation sequence processing was reinforced with rigid size limits. The reader loop now validates the total cumulative payload size for any continuous block of CONTINUATION frames that does not terminate with an END_HEADERS flag. If the limits are crossed, the stream is aborted with a protocol error exception.

To optimize handling of closed streams, the socket reader was refactored to perform direct socket-level flushing. Instead of allocating memory buffers to ingest unwanted data from cancelled streams, the runtime calls a Zero-Allocation discard loop that drains the TCP socket directly, bypassing heap allocation entirely.

Exploitation of CVE-2026-50651 requires the victim client to initiate an HTTP/2 connection to an attacker-controlled endpoint. This is commonly achieved through vectors such as Server-Side Request Forgery (SSRF) vulnerabilities, standard web-scraping activities, or consuming compromised third-party APIs.

Once the TCP connection is established and HTTP/2 is negotiated, the attacker server begins an asymmetric protocol flood. The server does not need to send high volumes of bandwidth. Instead, it can continuously transmit structured control frames or small, highly fragmented CONTINUATION frames while artificially throttling the TCP stream.

Because the client lacks defensive throttling on its dynamic structures, it repeatedly allocates memory to maintain the HPACK state and queue response ACKs. The application memory footprint increases exponentially until the process exhausts available virtual memory, causing the .NET host to execute an unhandled OutOfMemoryException crash.

The primary impact of CVE-2026-50651 is client-side denial of service via system resource exhaustion. Because the memory exhaustion occurs within the host .NET runtime process, any critical service or containerized microservice utilizing HttpClient to interact with external systems can be terminated abruptly.

This vulnerability has been assigned a CVSS v3.1 base score of 7.5, reflecting its remote exploitability and high availability impact. Crucially, the exploit requires no privileges and zero user interaction once the outbound request is triggered, elevating the risk profile for server-side .NET applications handling untrusted URLs.

At present, there is no evidence of active exploitation in the wild, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. However, the ease with which a proof-of-concept can be designed makes rapid mitigation essential for systems processing third-party webhook requests or scraping external resources.

Remediation requires updating the .NET hosting environment, SDK, and IDE installations to the patched versions released on July 14, 2026.

For .NET 10.0 environments, systems must run version 10.0.6 or higher. For .NET 9.0 environments, upgrade to 9.0.18 or higher, and for .NET 8.0, upgrade to 8.0.29 or higher. On Linux deployments, run package manager updates to pull the latest runtime binaries.

# Example update command for Ubuntu/Debian hosts
sudo apt-get update && sudo apt-get install --only-upgrade dotnet-runtime-8.0

If immediate patching is unfeasible, developers should enforce HTTP/1.1 fallback policies for HttpClient interactions with external endpoints. This forces the application to bypass the vulnerable HTTP/2 state machine entirely:

var client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Get, 'https://untrusted-domain.com/endpoint')
{
    Version = HttpVersion.Version11,
    VersionPolicy = HttpVersionPolicy.RequestVersionExact
};
var response = await client.SendAsync(request);