CVE-2026-118750: Uncontrolled Resource Allocation in ASP.NET Core FileBufferingReadStream

The Microsoft.AspNetCore.WebUtilities package provides core utilities for ASP.NET Core applications, including helpers for parsing multipart form data, handling query strings, and buffering incoming HTTP request streams. A critical component within this package is FileBufferingReadStream, a stream wrapper designed to enable seekable reads over non-seekable network streams. It achieves this by caching incoming data in memory up to a specified threshold (memoryThreshold) before spilling excess payload data to a temporary file on disk.

In versions of Microsoft.AspNetCore.WebUtilities prior to 2.3.14, FileBufferingReadStream exhibits a flaw classified under CWE-770 (Allocation of Resources Without Limits or Throttling). When an endpoint processes a buffered request or multipart form submission, the framework instantiates FileBufferingReadStream. During instantiation, the constructor immediately rents a byte array equal in size to the full memoryThreshold (commonly 30 KB or higher) from the application's shared ArrayPool<byte>.

Because this allocation occurs eagerly inside the constructor rather than lazily during stream read operations, the memory reservation happens before the server verifies whether the client has transmitted any payload bytes. An unauthenticated remote attacker can exploit this design over the network (AV:N) by initiating a high volume of concurrent HTTP requests targeting endpoints that utilize request buffering.

By holding these connections open while transmitting zero bytes or trickling data at an artificially slow rate, the attacker forces the server to lock up large segments of the ArrayPool<byte>. Once the shared pool is depleted, subsequent allocations fall back to standard heap allocations, inducing severe Garbage Collection (GC) thrashing, memory starvation, and a complete Denial of Service (DoS) for legitimate application users.

The root cause of CVE-2026-118750 lies in the memory management lifecycle of FileBufferingReadStream. In high-performance .NET web servers, ArrayPool<byte> is used to rent and return large byte arrays to avoid frequent allocations on the Large Object Heap (LOH) and reduce garbage collection overhead. However, the efficacy of object pooling depends on minimizing both the size of the rented buffer and the duration for which it is held.

Prior to commit 9a26c7414a4fbff45535c0830253c1b4479b0073, both constructor overloads of FileBufferingReadStream contained logic that checked whether the configured memoryThreshold was less than _maxRentedBufferSize (typically 1 MB). When this condition evaluated to true, the constructor immediately executed _bytePool.Rent(memoryThreshold) and wrapped the resulting array in a standard System.IO.MemoryStream.

This implementation introduces two distinct resource management defects. First, it performs eager pre-allocation: the buffer is reserved at object creation time rather than when data actually arrives on the wire. If an HTTP request contains a Content-Length of zero, or if the client delays sending the request body after transmitting the HTTP headers, the rented buffer sits idle in memory.

Second, the constructor forces fixed maximum sizing for all in-memory buffers. Even if a client sends a tiny 16-byte form field, the stream rents a buffer sized to memoryThreshold (defaulting to 30,720 bytes in standard multipart readers). Because ArrayPool<byte>.Rent rounds requests up to the nearest power of two, a 30 KB request actually rents a 32,768-byte array. Under concurrent connection floods, this 2000x amplification factor between actual payload data and reserved memory rapidly exhausts the memory pool buckets.

The vulnerability was remediated in commit 9a26c7414a4fbff45535c0830253c1b4479b0073 by removing the direct _rentedBuffer management from FileBufferingReadStream and delegating in-memory buffering to a newly introduced internal stream implementation: PooledMemoryStream.

In the vulnerable implementation, the constructor directly rented the buffer and initialized a MemoryStream over the raw array:

// VULNERABLE CODE: src/Http/WebUtilities/src/FileBufferingReadStream.cs
private Stream _buffer;
private byte[] _rentedBuffer;
 
public FileBufferingReadStream(
    Stream inner,
    int memoryThreshold,
    long? bufferLimit,
    Func<string> tempFileDirectoryAccessor,
    ArrayPool<byte> bytePool)
{
    // ... validation omitted ...
    _bytePool = bytePool;
    if (memoryThreshold < _maxRentedBufferSize)
    {
        // Defect: Immediately rents the full threshold size before any I/O occurs
        _rentedBuffer = bytePool.Rent(memoryThreshold);
        _buffer = new MemoryStream(_rentedBuffer);
        _buffer.SetLength(0);
    }
    else
    {
        _buffer = new MemoryStream();
    }
}

The patch replaces the eager bytePool.Rent call and the _rentedBuffer field with an instance of PooledMemoryStream:

// PATCHED CODE: src/Http/WebUtilities/src/FileBufferingReadStream.cs
private Stream _buffer;
// _rentedBuffer field removed
 
public FileBufferingReadStream(
    Stream inner,
    int memoryThreshold,
    long? bufferLimit,
    Func<string> tempFileDirectoryAccessor,
    ArrayPool<byte> bytePool)
{
    // ... validation omitted ...
    _bytePool = bytePool;
    if (memoryThreshold < _maxRentedBufferSize)
    {
        // Fix: Instantiates PooledMemoryStream without renting from bytePool yet
        _buffer = new PooledMemoryStream(bytePool, memoryThreshold);
    }
    else
    {
        _buffer = new MemoryStream();
    }
}

PooledMemoryStream alters the allocation behavior by keeping its internal _buffer reference as null upon construction. When Write or WriteAsync is invoked as actual bytes are read from the underlying network stream, PooledMemoryStream.EnsureCapacity calculates the required capacity and rents a minimally sized buffer (starting at _initialCapacity of 256 bytes or the incoming write size). As additional data arrives, it grows the buffer geometrically (doubling capacity up to _maxCapacity, which is set to memoryThreshold) and returns the smaller buffer to the ArrayPool<byte>.

Furthermore, the patch updates the disk spill-over logic inside Read and ReadAsync. When the stream length exceeds memoryThreshold and transitions to a temporary FileStream, the patched code uses a using (oldBuffer) block. If oldBuffer is a PooledMemoryStream, it copies the data directly from pooledBuffer.Buffer to the file stream and disposes of oldBuffer, which automatically returns the rented array to _bytePool. For the else branch (used when memoryThreshold >= _maxRentedBufferSize), the patch also wraps the temporary copy buffer in a try/finally block to guarantee _bytePool.Return(rentedBuffer) is executed even if an I/O exception occurs during file writing.

> [!NOTE] > Fix Completeness Assessment: The introduction of PooledMemoryStream completely resolves the pre-allocation issue for zero-byte and small payloads. Additionally, adding the try/finally block around the fallback MemoryStream copy routine fixes a secondary potential pool leak during disk I/O failures.

Exploiting CVE-2026-118750 does not require authentication, special privileges, or complex payload crafting. The attack surface includes any public-facing ASP.NET Core endpoint that invokes FileBufferingReadStream directly or indirectly—most commonly endpoints accepting IFormFile, processing MultipartReader, or using middleware that invokes HttpRequestRewindExtensions.EnableBuffering().

An attacker executes the exploitation methodology through the following steps:

1. Target Identification: The attacker locates an HTTP endpoint on the target ASP.NET Core application that processes multipart form submissions or enables request body buffering.
2. Connection Establishment: The attacker initiates thousands of concurrent TCP connections (or multiplexed HTTP/2 streams) to the target web server.
3. Header Transmission: Over each connection or stream, the attacker sends valid HTTP POST headers specifying a Content-Type: multipart/form-data; boundary=... and a valid Content-Length header, prompting the ASP.NET Core routing and model binding pipeline (or custom middleware) to initialize FileBufferingReadStream.
4. Resource Locking (Slowloris Pattern): Immediately upon entering the stream constructor, the server rents a 32 KB (or larger, depending on configuration) byte array per request. The attacker thenwithholds the HTTP request body or transmits single bytes at intervals just frequent enough to bypass the server's minimum data rate timeout.
5. Pool Exhaustion: Because ArrayPool<byte>.Shared maintains a bounded number of arrays per size bucket, holding thousands of 32 KB buffers simultaneously empties the bucket. Subsequent requests (including legitimate traffic across unrelated parts of the application that rely on ArrayPool<byte>.Shared) force the runtime to allocate brand-new byte arrays on the managed heap.

As the attacker cycles or maintains these stalled connections, the application experiences rapid heap growth and continuous Generation 2 garbage collection pauses, degrading throughput until the process becomes unresponsive or terminates with an OutOfMemoryException.

The primary impact of CVE-2026-118750 is a high-severity loss of service availability, reflected in its CVSS v3.1 score of 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Because the vulnerability affects ArrayPool<byte>.Shared—which is a process-wide singleton in .NET—exhausting the pool in one vulnerable endpoint degrades performance across the entire ASP.NET Core worker process, including Kestrel's internal I/O pipelines and serialization routines.

Even when PooledMemoryStream is not present in older builds, the vulnerability does not expose uninitialized memory from the ArrayPool<byte> to the caller because FileBufferingReadStream previously called _buffer.SetLength(0) after wrapping _rentedBuffer in a MemoryStream. Consequently, there is no Confidentiality (C:N) or Integrity (I:N) impact.

As of publication, CVE-2026-118750 is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and its Exploit Code Maturity is classified as Unproven (E:U). However, because the mechanics required to trigger the flaw are identical to standard Slowloris or concurrent POST flood attacks, existing load-testing tools and HTTP stress scripts can trigger the condition without modification.

To remediate CVE-2026-118750, development and operations teams must upgrade the Microsoft.AspNetCore.WebUtilities NuGet package to version 2.3.14 or later. This version incorporates PooledMemoryStream, ensuring that memory buffers are rented lazily and sized proportionally to the actual incoming payload.

Update the package reference in your project file (.csproj):

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.WebUtilities" Version="2.3.14" />
</ItemGroup>

If immediate package upgrading is not feasible, administrators can apply defense-in-depth mitigations at both the Kestrel web server layer and the perimeter reverse proxy layer to restrict the number and duration of concurrent stalled requests.

First, configure Kestrel's request limits to enforce strict concurrent connection bounds and minimum request body data rates. This ensures that clients holding connections open without transmitting payload data are disconnected rapidly, freeing the FileBufferingReadStream and returning its rented buffer to the ArrayPool<byte>:

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    // Cap maximum concurrent connections to prevent unbounded pool exhaustion
    serverOptions.Limits.MaxConcurrentConnections = 1000;
 
    // Terminate requests that fail to transmit body data at an acceptable rate
    serverOptions.Limits.MinRequestBodyDataRate = new MinDataRate(
        bytesPerSecond: 240,
        gracePeriod: TimeSpan.FromSeconds(5));
});

Second, configure upstream reverse proxies (such as NGINX, HAProxy, Envoy, or cloud load balancers) to buffer incoming request bodies before forwarding them to the backend ASP.NET Core Kestrel server, and enforce strict per-IP rate limiting and client body timeouts (e.g., client_body_timeout 10s; in NGINX). When a reverse proxy buffers the entire request before forwarding it to Kestrel, FileBufferingReadStream receives the payload immediately at local network speeds, minimizing the time window during which buffers remain rented from the pool.