CVE-2026-109478: Algorithmic Complexity Denial of Service in ASP.NET Core Header Parsing

ASP.NET Core provides a structured abstraction layer for inspecting and manipulating incoming HTTP request data via the Microsoft.AspNetCore.Http.Abstractions namespace. Within this subsystem, HTTP request headers are exposed through the IHeaderDictionary interface, which offers extension methods to normalize and parse complex header formats. A commonly invoked utility method is HeaderDictionaryExtensions.GetCommaSeparatedValues, which extracts and splits multi-value HTTP headers (such as Accept, Accept-Encoding, Cache-Control, Forwarded, or custom application headers) into individual string tokens.

Under the hood, GetCommaSeparatedValues delegates the tokenization and extraction workload to the internal helper method ParsingHelpers.GetHeaderSplit. Because HTTP request headers represent untrusted network input processed early in the request lifecycle—often within authentication, routing, CORS, or telemetry middleware—the computational efficiency of GetHeaderSplit directly dictates the server's resilience against malformed or adversarial traffic.

CVE-2026-109478 is an Inefficient Algorithmic Complexity vulnerability (CWE-407) residing within ParsingHelpers.GetHeaderSplit. When parsing an HTTP header containing $N$ comma-separated values, the unpatched implementation exhibits quadratic time and memory allocation complexity, scaling at $O(N^2)$.

An unauthenticated, remote attacker can exploit this flaw by transmitting standard HTTP requests containing headers densely populated with single-character, comma-separated tokens. Processing even a single 30 KB header crafted in this manner forces the .NET runtime to execute millions of array copy operations and allocate hundreds of megabytes of transient heap memory, starving worker threads and triggering continuous Garbage Collection (GC) pauses that result in a full application Denial of Service (DoS).

The root cause of CVE-2026-109478 lies in the misuse of the Microsoft.Extensions.Primitives.StringValues data structure as a dynamic accumulator inside an iterative parsing loop. StringValues is an immutable value type (readonly struct) designed to efficiently represent zero, one, or multiple string values without allocating an array when only a single string is present. Internally, it stores a single object? reference that points either to a string instance or a string[] array.

Because StringValues is designed as an immutable wrapper rather than a dynamic collection builder like List<T>, it does not maintain spare capacity or geometric growth buffers. When StringValues.Concat(in StringValues values, string value) is invoked on an instance already holding an array of $k$ elements, the method must allocate a brand-new string[k + 1] array on the managed heap, copy all $k$ object references from the source array to the destination array via Array.Copy, and write the new string reference at index $k$.

In the unpatched version of ParsingHelpers.GetHeaderSplit, the method iterates over every token yielded by HeaderSegmentCollection and appends each valid token to a local StringValues variable using StringValues.Concat:

As the loop progresses from $k = 1$ to $N$ tokens, the cumulative number of array reference copy operations follows an arithmetic progression:

$$\text{Total Reference Copies} = \sum_{k=1}^{N} (k - 1) = \frac{N(N - 1)}{2} = O(N^2)$$

Similarly, the total volume of intermediate array allocations on the managed heap grows quadratically. On a 64-bit runtime where each object reference occupies 8 bytes (plus a 24-byte array object header), parsing $N$ tokens allocates $N - 1$ distinct arrays of linearly increasing size. For $N = 15,000$ tokens—which easily fits inside Kestrel's default 32 KB maximum header size (a,a,a,...)—a single call to GetHeaderSplit performs approximately $1.125 \times 10^8$ reference copies and allocates roughly $900\text{ MB}$ of ephemeral heap memory.

> [!WARNING] > Arrays exceeding 85,000 bytes in size (which occurs once $k \ge 10,622$ on 64-bit platforms) are allocated directly on the .NET Large Object Heap (LOH). Consequently, tokens $10,622$ through $15,000$ trigger over 4,300 separate LOH allocations per request. LOH allocations are only reclaimed during full Generation 2 Garbage Collections, which require expensive stop-the-world thread suspensions.

Microsoft addressed CVE-2026-109478 in commits effb34d85fdc5137ee4bd87d52560433c3df02e7 (main branch) and 2523887d4cca7013afa2737e20cb7f6ba1eed8ff (.NET 8.0 release branch). The patch modifies three files: ParsingHelpers.cs, HeaderDictionaryExtensions.cs, and introduces the internal ValueListBuilder<T> structure in ValueListBuilder.cs.

Vulnerable Implementation

Prior to the patch, ParsingHelpers.GetHeaderSplit accumulated parsed segments into a StringValues struct, and HeaderDictionaryExtensions.GetCommaSeparatedValues subsequently converted that struct into a string[]:

// File: src/Http/Http.Abstractions/src/Extensions/HeaderDictionaryExtensions.cs
public static string[] GetCommaSeparatedValues(this IHeaderDictionary headers, string key)
{
    // Redundant .ToArray() call after O(N^2) StringValues accumulation
    return ParsingHelpers.GetHeaderSplit(headers, key).ToArray();
}
 
// File: src/Http/Http.Abstractions/src/Internal/ParsingHelpers.cs
public static StringValues GetHeaderSplit(IHeaderDictionary headers, string key)
{
    var values = GetHeaderUnmodified(headers, key);
 
    StringValues result = default;
 
    foreach (var segment in new HeaderSegmentCollection(values))
    {
        if (segment.Data.HasValue)
        {
            var value = DeQuote(segment.Data.Value);
            if (!string.IsNullOrEmpty(value))
            {
                // FLAW: Allocates a new array of size (k + 1) and copies all k elements on every iteration
                result = StringValues.Concat(in result, value);
            }
        }
    }
 
    return result;
}

Patched Implementation

The fix replaces StringValues accumulation with ValueListBuilder<string>, a stack-allocated ref struct backed by an inline 4-element buffer and ArrayPool<string>.Shared for larger payloads:

// File: src/Http/Http.Abstractions/src/Extensions/HeaderDictionaryExtensions.cs
public static string[] GetCommaSeparatedValues(this IHeaderDictionary headers, string key)
{
    // GetHeaderSplit now directly returns the finalized string[]
    return ParsingHelpers.GetHeaderSplit(headers, key);
}
 
// File: src/Http/Http.Abstractions/src/Internal/ParsingHelpers.cs
public static string[] GetHeaderSplit(IHeaderDictionary headers, string key)
{
    var values = GetHeaderUnmodified(headers, key);
 
    // Initialize ValueListBuilder with a 4-element inline Span to avoid heap allocation for common small headers
    ValueListBuilder<string> strings = new([null!, null!, null!, null!]);
 
    foreach (var segment in new HeaderSegmentCollection(values))
    {
        if (segment.Data.HasValue)
        {
            var value = DeQuote(segment.Data.Value);
            if (!string.IsNullOrEmpty(value))
            {
                // Amortized O(1) insertion via geometric capacity doubling
                strings.Add(value);
            }
        }
    }
 
    // Allocate exact-sized destination array once in O(N) time
    string[] result = strings.AsSpan().ToArray();
    
    // Return any rented intermediate buffer back to ArrayPool<string>.Shared
    strings.Dispose();
 
    return result;
}

Supporting Structure: ValueListBuilder<T>

The newly added ValueListBuilder<T> guarantees $O(1)$ amortized insertion and zero LOH churn by renting buffers from ArrayPool<T>.Shared and doubling capacity whenever the underlying span is exhausted:

// File: src/Shared/ValueStringBuilder/ValueListBuilder.cs
private void Grow(int additionalCapacityRequired = 1)
{
    const int ArrayMaxLength = 0x7FFFFFC7;
    // Geometric growth: double the current capacity (minimum 4)
    int nextCapacity = Math.Max(_span.Length != 0 ? _span.Length * 2 : 4, _span.Length + additionalCapacityRequired);
    if ((uint)nextCapacity > ArrayMaxLength)
    {
        nextCapacity = Math.Max(Math.Max(_span.Length + 1, ArrayMaxLength), _span.Length);
    }
 
    // Rent from shared pool instead of allocating new arrays on the GC heap
    T[] array = ArrayPool<T>.Shared.Rent(nextCapacity);
    _span.CopyTo(array);
 
    T[]? toReturn = _arrayFromPool;
    _span = _arrayFromPool = array;
    if (toReturn != null)
    {
        // Return the previous buffer immediately to the pool
        ArrayPool<T>.Shared.Return(toReturn);
    }
}

Fix Completeness Assessment

The remediation is complete and structurally sound for this code path. By changing the return signature of the internal ParsingHelpers.GetHeaderSplit method from StringValues to string[] and using geometric capacity doubling with pooled arrays, time complexity is strictly bounded to $O(N)$ and unpooled heap allocations are reduced from $N$ arrays to exactly 1 final string[] array. Furthermore, changing GetHeaderSplit to return string[] eliminated a redundant .ToArray() conversion previously present in HeaderDictionaryExtensions.GetCommaSeparatedValues. No exception paths exist inside the foreach loop (DeQuote operates on StringSegment slices without throwing), ensuring strings.Dispose() is reliably reached during standard execution.

Exploiting CVE-2026-109478 requires no authentication, special privileges, or complex state synchronization. The sole prerequisite is that the target ASP.NET Core application—or any middleware, framework component, or third-party library in its request pipeline—invokes IHeaderDictionary.GetCommaSeparatedValues on an attacker-controllable HTTP header.

Attack Surface Identification

Within the ASP.NET Core ecosystem and common web application architectures, GetCommaSeparatedValues is frequently called on standard HTTP headers during request pre-processing:

• Content Negotiation & Compression: Parsing Accept, Accept-Encoding, or Accept-Language headers.
• Reverse Proxy & Forwarding Middleware: Inspecting X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host, or Forwarded headers.
• CORS & Caching: Evaluating Access-Control-Request-Headers, Origin, Vary, or Cache-Control directives.
• Custom Application Logic: Reading multi-value API keys, feature flags, or routing tags passed via custom headers.

Proof-of-Concept Mechanics

To maximize the ratio of token count ($N$) to byte length ($L$), an attacker alternates single-byte characters with comma delimiters (a,a,a,...). Under Kestrel's default configuration, the maximum permitted total size for all request headers (MaxRequestHeadersTotalSize) and for any single header field (MaxRequestHeaderFieldSize) is 32,768 bytes (32 KB).

1. Payload Construction: The attacker constructs an HTTP request containing a header of approximately 30,000 bytes consisting of 15,000 single-character tokens separated by commas:

GET / HTTP/1.1
Host: vulnerable-target.example.com
Accept-Encoding: a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,... [15,000 tokens (~30 KB)]
Connection: keep-alive
 

2. Server-Side Execution: When the request reaches the middleware or controller calling request.Headers.GetCommaSeparatedValues("Accept-Encoding"), ParsingHelpers.GetHeaderSplit iterates 15,000 times:

   • Iterations $1$ through $10,621$ allocate increasingly large arrays in Generation 0 of the Small Object Heap (SOH), totaling $\approx 451\text{ MB}$ of allocations.
   • Iterations $10,622$ through $15,000$ exceed the 85,000-byte LOH threshold, allocating 4,379 distinct arrays directly on the Large Object Heap, totaling $\approx 449\text{ MB}$ of LOH allocations.
   • Across all 15,000 iterations, the CPU executes $\approx 112.5\text{ million}$ element copy operations.

3. Resource Exhaustion Amplification: By pipelining or multiplexing these requests over persistent HTTP/1.1 (keep-alive), HTTP/2, or HTTP/3 connections, a single client with minimal outbound bandwidth (e.g., 10–20 requests per second, requiring less than 5 Mbps) forces the server to allocate over $9\text{ GB/sec}$ on the managed heap, half of which lands directly on the LOH. The .NET runtime immediately enters continuous blocking Generation 2 GC cycles, freezing all Kestrel worker threads and dropping legitimate client connections.

CVE-2026-109478 is rated High severity with a CVSS v3.1 base score of 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

CVSS v3.1 Metric Breakdown

• Attack Vector (AV:N): The vulnerable component is bound to the network stack and processes untrusted HTTP headers directly from remote clients.
• Attack Complexity (AC:L): Exploitation requires no specialized conditions, cryptographic bypasses, or race conditions; sending standard HTTP requests with comma-dense headers deterministically triggers the quadratic loop.
• Privileges Required (PR:N): Header parsing frequently occurs in pre-authentication middleware (e.g., routing, CORS, forwarding, or content negotiation), requiring zero prior authentication.
• User Interaction (UI:N): The attack is executed entirely against the server daemon without involving any human user.
• Confidentiality & Integrity (C:N / I:N): The flaw does not permit out-of-bounds memory reads, memory corruption, or unauthorized data modification.
• Availability Impact (A:H): Sustained exploitation completely exhausts CPU time and managed heap capacity, resulting in full service unavailability for all co-hosted endpoints within the same .NET process.

Operational & Infrastructure Consequences

Beyond immediate request timeouts, the severe LOH allocation pressure introduced by this vulnerability can cause cascading failures in containerized and cloud-native environments:

1. OOM Kills and Container Restarts: If the rate of LOH allocation outpaces the background/blocking Gen 2 garbage collector's ability to compact or sweep memory within cgroup memory limits, the Linux kernel Out-Of-Memory (OOM) killer will terminate the dotnet host process (SIGKILL / exit code 137).
2. Thread Pool Starvation: Because Kestrel worker threads are blocked in tight synchronous loops copying array references and paused during stop-the-world GC phases, the .NET ThreadPool cannot schedule asynchronous I/O completions, health check responses, or database keep-alives, causing upstream load balancers (such as Kubernetes liveness probes or AWS ALB health checks) to mark instances as unhealthy and cycle them repeatedly.

The primary and definitive remediation for CVE-2026-109478 is to upgrade the .NET Runtime, ASP.NET Core Shared Framework, and associated development tooling to the patched versions released by Microsoft.

Official Patched Versions

> [!NOTE] > For self-contained ASP.NET Core deployments (where the .NET runtime and Microsoft.AspNetCore.Http.Abstractions.dll are bundled directly with the application executable), updating the host server's shared runtime is insufficient. You must rebuild and redeploy the application using the updated .NET SDK.

Workarounds and Defense-in-Depth Mitigations

If immediate patching is not feasible, security engineers can substantially reduce the quadratic amplification factor by constraining header lengths and filtering excessive comma counts at the network edge or within Kestrel:

1. Restrict Kestrel Header Size Limits: Reduce MaxRequestHeaderFieldSize and MaxRequestHeadersTotalSize from the default 32 KB down to the minimum threshold required by your application (e.g., 4 KB or 8 KB). Because the algorithmic complexity is $O(N^2)$, reducing maximum header length by a factor of $8\times$ reduces worst-case CPU and memory work by a factor of $64\times$:

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.Limits.MaxRequestHeaderFieldSize = 4096; // 4 KB max per single header
    serverOptions.Limits.MaxRequestHeadersTotalSize = 8192; // 8 KB max across all headers
});

2. Edge WAF / Reverse Proxy Filtering: Configure upstream Web Application Firewalls (such as ModSecurity, AWS WAF, Cloudflare, or NGINX) to reject HTTP requests containing an abnormally high number of commas (e.g., $> 64$ commas) within any single request header.