CVE-2026-56170: Remote Denial of Service via Resource Exhaustion in ASP.NET Core

CVE-2026-56170 represents a cluster of resource-management flaws classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The vulnerability resides in core components of the ASP.NET Core framework, specifically the SignalR transport subsystem, the Microsoft.AspNetCore.JsonPatch middleware, and the Kestrel HTTP/2 stream handler. Because these components run at the front line of incoming HTTP traffic, they expose a highly critical attack surface.

An unauthenticated remote attacker can leverage these flaws to induce resource exhaustion over a network. Depending on the targeted vector, the exploit results in either system-wide heap memory saturation, thread pool starvation, or immediate worker-process termination via an unhandled stack overflow. The vulnerability affects standard configurations of .NET 8.0, 9.0, and 10.0 deployments.

The impact is limited to system availability, but because the underlying processes are completely terminated or starved of execution context, recovery often requires administrator intervention or automated process-recycling mechanisms. No data disclosure or integrity loss has been identified in connection with this vulnerability.

The vulnerability is split into three primary technical vectors, each targeting a distinct resource-allocation weakness in ASP.NET Core.

Vector A: SignalR Stateful Reconnect Resource Saturation

The Stateful Reconnect feature, designed to preserve client sessions during transient network drops, stores outbound messages in an in-memory buffer (StatefulReconnectBufferSize). In affected versions, the SignalR transport manager does not enforce global limits on the cumulative memory allocated for all disconnected sessions or limit the total number of concurrently suspended connections. Consequently, an attacker can open numerous connections, trigger outbound traffic, drop the TCP connection, and force Kestrel to keep these active, pinned memory structures allocated on the heap.

Vector B: JSON Patch Type Confusion & Recursion

Inside the JSON Patch parser implementation (Microsoft.AspNetCore.JsonPatch.SystemTextJson), the TryTraverse method in ListAdapter.cs attempts to identify if a target deserialized object is an array by casting it using the non-generic IList interface. However, modern System.Text.Json collection nodes—such as JsonArray—implement the generic IList<JsonNode> interface but do not implement the legacy, non-generic IList interface. When encountering a JsonArray, this cast returns null, causing the parser to fall back to the generic ObjectAdapter.

The ObjectAdapter attempts to traverse the JsonArray properties using reflection. Because these JSON node structures contain cyclic parent-child node pointers, the reflective property traversal falls into an infinite loop, exhausting the thread's stack frame and triggering an unrecoverable StackOverflowException.

Vector C: Kestrel HTTP/2 Stream Lifetime Desynchronization

When handling an HTTP/2 stream abort via a RST_STREAM frame, a race condition exists between the application thread writing response headers and the Kestrel connection-processing thread. If the application delegate continues writing to the stream while the abort sequence is running, Kestrel fails to execute a timely connection-level teardown. This delay leaves connection-bound resources, such as SignalR message buffers, allocated in memory far longer than expected, compounding the heap exhaustion attack vectors.

The fix for the JSON Patch vulnerability (Vector B) directly resolves the type-confusion issue in ListAdapter.cs. Below is the comparison of the vulnerable logic versus the type-safe collection detection introduced in the official patch.

// VULNERABLE CODE
public virtual bool TryTraverse(object target, string segment, JsonSerializerOptions serializerOptions, out object value, out string errorMessage)
{
    // Non-generic IList cast fails on System.Text.Json.Nodes.JsonArray
    var list = target as IList;
    if (list == null)
    {
        value = null;
        errorMessage = null; // Forces fallback to ObjectAdapter (reflective traversal)
        return false;
    } 
    // ...
}

To remediate this, Microsoft replaced the legacy cast with a type-aware detection helper TryGetListTypeArgument and introduced a safe utility wrapper (GenericListOrJsonArrayUtilities) to access index elements without relying on standard reflection:

// PATCHED CODE (Commit: 73c3f2518a77f716685c6ba8e694fce2199b1df0)
public virtual bool TryTraverse(object target, string segment, JsonSerializerOptions serializerOptions, out object value, out string errorMessage)
{
    // Correctly inspects if target is a generic IList<T> or JsonArray
    if (!TryGetListTypeArgument(target, out _, out errorMessage))
    {
        value = null;
        return false;
    }
 
    if (!int.TryParse(segment, out var index))
    {
        value = null;
        errorMessage = Resources.FormatInvalidIndexValue(segment);
        return false;
    }
 
    // Retrieve counts safely via a specialized utility
    var count = GenericListOrJsonArrayUtilities.GetCount(target);
    if (index < 0 || index >= count)
    {
        value = null;
        errorMessage = Resources.FormatIndexOutOfBounds(segment);
        return false;
    }
 
    // Extract element using generic access, avoiding infinite reflective loops
    value = GenericListOrJsonArrayUtilities.GetElementAt(target, index);
    errorMessage = null;
    return true;
}

This fix completely prevents the code from falling back to reflection-based traversal on standard JSON nodes, thereby eliminating the infinite loop and the resulting stack overflow condition.

An attacker can exploit these issues using two distinct approaches depending on the configured application endpoints.

Scenario A: SignalR Heap Saturation

1. The attacker establishes 5,000 to 10,000 parallel WebSocket or HTTP transport connections to a vulnerable SignalR hub.
2. The attacker triggers actions that prompt the server to queue outbound responses to the clients.
3. The attacker terminates the socket TCP connection abruptly (using TCP RST packets), preventing normal session closure handshakes.
4. Kestrel transitions the connections to a Suspended state, allocating tracking buffers and retaining outbound queues on the heap.
5. The attacker repeats the sequence. Because global limits are not enforced, cumulative allocations consume the server's available virtual memory, causing an OutOfMemoryException.

Scenario B: JSON Patch Stack Overflow

1. The attacker targets an HTTP endpoint that accepts JsonPatchDocument input parameters.
2. The attacker sends a PATCH request targeting a parameter backed by a JsonArray structures containing recursive properties.
3. The payload contains a traversal path designed to force index evaluation.
4. The server-side JSON Patch processor runs the vulnerable TryTraverse path, fails the IList cast, falls back to property-reflection on the cyclic array nodes, and overflows the stack.

The overall security impact of CVE-2026-56170 is rated as High (CVSS Base Score 7.5). Successful exploitation results in a complete Denial of Service on the affected application hosting process.

In the case of Vector B, the exploitation leads to a native StackOverflowException. Within the .NET CLR, a stack overflow is an unrecoverable runtime exception that immediately terminates the worker process. Unlike standard exceptions, it cannot be caught or handled within user code. This results in immediate downtime for all users sharing the application pool.

In the case of Vector A, memory exhaustion degrades application performance before culminating in an OutOfMemoryException. This crash degrades the availability of any other application instances hosted on the same container, VM, or IIS application pool, representing a high-impact infrastructure vulnerability.

To address this vulnerability, security teams must deploy official Microsoft updates to the .NET runtime and SDK, or apply configuration-level mitigations to reduce the attack surface.

Upgrade Paths:

Deploy the patched runtime versions according to the channel in use:

• .NET 8.0: Upgrade to version 8.0.29 or newer.
• .NET 9.0: Upgrade to version 9.0.18 or newer.
• .NET 10.0: Upgrade to version 10.0.6 or newer.

Workaround - Hardening SignalR Configurations:

If upgrading the runtime is delayed, you can mitigate Vector A by disabling the Stateful Reconnect feature or restricting the connection-buffer size in Program.cs:

builder.Services.AddSignalR(options =>
{
    // Set buffer size to 0 to disable Stateful Reconnect globally
    options.StatefulReconnectBufferSize = 0;
});

Workaround - Request Size Limitations:

Enforce strict maximum limits on the request body sizes handled by Kestrel to prevent processing exceptionally large or deeply nested JSON Patch requests:

builder.WebHost.ConfigureKestrel(options =>
{
    options.Limits.MaxRequestBodySize = 1048576; // Cap request sizes at 1MB
});