CVE-2026-26130: Unauthenticated Denial of Service in ASP.NET Core SignalR via Resource Exhaustion

ASP.NET Core SignalR facilitates real-time web functionality, enabling servers to push content to connected clients instantly. The framework supports multiple underlying transports, including WebSockets, Server-Sent Events (SSE), and Long Polling, relying on framed protocols to process incoming JSON or MessagePack payloads. These protocols require precise resource management to handle high-concurrency connections safely.

CVE-2026-26130 identifies a critical flaw in how SignalR allocates memory during the initial parsing phase of these framed messages. The vulnerability classifies as CWE-770 (Allocation of Resources Without Limits or Throttling), permitting an unauthenticated remote attacker to dictate server-side memory allocations via user-controlled input.

Exploitation results in an immediate Denial of Service (DoS) condition. An attacker abuses the protocol framing logic to force the application to exceed available heap limits. This triggers an unhandled OutOfMemoryException, abruptly terminating the host process and severing all legitimate client connections.

SignalR utilizes a length-prefixed framing mechanism to delineate discrete messages over continuous network streams. When a client transmits a message, the server-side protocol handler reads the initial bytes to determine the total payload length. The parser logic relies on this length integer to allocate a continuous memory buffer for the upcoming payload.

In vulnerable ASP.NET Core versions, the protocol handler reads the length prefix and immediately requests buffer space from the underlying memory pool. The application executes calls to methods such as ArrayPool<byte>.Rent or PipeWriter.GetMemory using the unsanitized integer provided by the client's network frame.

The critical sequencing error occurs because this memory reservation happens strictly before the application evaluates the requested size against the configured HubOptions.MaximumReceiveMessageSize security policy. The framework blindly trusts the client-provided length header, allowing an attacker to request multi-gigabyte allocations regardless of the actual payload size transmitted over the wire.

Secondary failure modes further exacerbate the denial of service surface within the same patch cycle. These include unbounded parallel orchestration tasks generating resource contention, and a race condition in the HttpSys module. Specifically, RequestQueue.Dispose improperly sequenced native handle closures, generating leaked buffers and handle exhaustion during high-concurrency connection resets.

The vulnerability resides in the sequence of operations within the SignalR message reading loop. The flawed implementation retrieves the requested frame size and immediately prepares the buffer environment.

// VULNERABLE PATTERN
public async Task ReadMessageAsync(PipeReader reader)
{
    var lengthPrefix = await ReadLengthHeaderAsync(reader);
    
    // Allocates memory based on unverified attacker input
    var buffer = ArrayPool<byte>.Shared.Rent((int)lengthPrefix);
    
    if (lengthPrefix > _options.MaximumReceiveMessageSize)
    {
        // Validation happens too late; memory is already requested
        throw new InvalidDataException("Message exceeds maximum size");
    }
}

The patched code fundamentally alters this sequence. The framework now mandates strict validation of the length header against the configured policy limits before authorizing any interaction with the memory pooling system.

// PATCHED PATTERN
public async Task ReadMessageAsync(PipeReader reader)
{
    var lengthPrefix = await ReadLengthHeaderAsync(reader);
    
    // Immediate policy validation aborts the connection safely
    if (lengthPrefix > _options.MaximumReceiveMessageSize)
    {
        throw new InvalidDataException("Message exceeds maximum size");
    }
    
    // Memory allocation only occurs for validated payload sizes
    var buffer = ArrayPool<byte>.Shared.Rent((int)lengthPrefix);
}

Additionally, the patch addressing the HttpSys handle lifecycle replaces direct calls to Handle.Dispose() with Handle.SetHandleAsInvalid(). This modification guarantees that handle invalidation executes atomically, preventing the double-close race condition during abrupt connection terminations.

Exploitation requires minimal prerequisites. The attacker only needs network routing to the target ASP.NET Core application exposing a SignalR endpoint. Authentication is entirely bypassed, as the vulnerability resides at the network framing layer prior to application-level routing or authorization checks.

The attack sequence begins with the adversary initiating a standard connection using WebSockets or Server-Sent Events. Once the transport establishes successfully, the attacker constructs a minimal, malformed protocol frame. This frame contains a valid preamble but specifies an exceptionally large integer in the length-prefix field, such as 2,147,483,647 bytes (2GB).

Upon receiving the header, the SignalR parser attempts to reserve the requested 2GB of continuous memory from the heap. By concurrently opening multiple connections and transmitting identical malformed frames, the attacker rapidly depletes the physical memory available to the application process.

The host operating system fails to fulfill these allocation requests, forcing the .NET runtime to throw an uncatchable OutOfMemoryException. The application process subsequently crashes, resulting in a total denial of service. The attacker can sustain the outage by repeatedly executing the exploit payload as the host system attempts to restart the application pool.

Successful exploitation yields a complete loss of service availability. The CVSS vector designates this impact as High (A:H), reflecting the definitive process termination caused by memory exhaustion. Legitimate users experience immediate disconnection and persistent inability to interact with the application.

Depending on the specific deployment architecture, the blast radius extends beyond the vulnerable application. In containerized environments lacking strict resource quotas (such as Docker or Kubernetes Pods without memory limits), the unconstrained allocation triggers node-level memory pressure. This condition causes the kernel OOM killer to arbitrarily terminate neighboring services running on the same host.

The exploitability profile presents a significant risk to unpatched environments. The CVSS base score of 7.5 highlights the network-based attack vector (AV:N), low attack complexity (AC:L), and zero required privileges (PR:N). While the current EPSS score (0.01273) indicates low observed weaponization in the wild, the technical barrier to constructing a working proof-of-concept is trivial.

Organizations must prioritize updating the ASP.NET Core runtime and SDK to the fixed versions issued during the March 2026 Patch Tuesday release. The secured versions are 8.0.25, 9.0.14, and 10.0.4. Applying these updates replaces the vulnerable protocol parsing libraries with the corrected sequencing logic.

Deploying the binaries alone does not mitigate the vulnerability. Administrators must completely restart all applications utilizing the SignalR framework. This action unloads the vulnerable assemblies from system memory and initializes the application pool with the patched resource management controls.

For environments where immediate patching is unfeasible, security teams can implement network-level detection strategies. Web Application Firewalls (WAF) or Intrusion Detection Systems (IDS) can monitor incoming WebSocket and SSE traffic. Operators should configure rules to identify and drop MessagePack or JSON frames exhibiting abnormally large length prefixes, thereby blocking the exploit payload before it reaches the ASP.NET Core application layer.