CVE-2026-114150: Remote Information Disclosure via Uninitialized Pooled Memory in ASP.NET Core Response Buffering

CVE-2026-114150 is an information disclosure vulnerability in Microsoft ASP.NET Core affecting .NET 11.0 preview releases (from 11.0.0-preview.1 up to, but excluding, 11.0.0 GA) across Linux, macOS, and Windows platforms, as well as Microsoft Visual Studio 2026 versions prior to 18.12.0. The vulnerability resides in the HTTP response body buffering infrastructure, specifically within stream wrapper classes such as ResponseBufferingStream. These abstractions are invoked when applications configure built-in middleware that inspects, caches, or logs outgoing HTTP payloads, primarily Microsoft.AspNetCore.HttpLogging and Microsoft.AspNetCore.OutputCaching.

In modern high-throughput web servers, allocating and garbage-collecting large byte arrays for every HTTP response introduces severe memory pressure and latency overhead. To optimize throughput, ASP.NET Core relies on shared memory pooling mechanisms provided by the runtime, notably ArrayPool<byte>.Shared and MemoryPool<byte>. When a middleware component needs to buffer a response body in memory before transmitting it over the network or writing it to a diagnostic sink, it rents fixed-size or bucketed byte segments from these shared pools rather than allocating fresh heap arrays.

Classified under CWE-908 (Use of Uninitialized Resource), this vulnerability occurs because pooled byte arrays retain the exact byte patterns written during previous lease lifecycles unless explicitly zeroed out. When ResponseBufferingStream processes an HTTP response that is smaller than the total capacity of the rented buffer segment, and fails to strictly clamp the reader view to the exact count of newly written bytes, the unwritten tail of the buffer remains accessible. Consequently, downstream stream consumers and HTTP logging facilities read past the logical end of the current response and ingest stale memory remnants left behind by prior, unrelated HTTP transactions.

> [!NOTE] > While the .NET runtime automatically zeroes newly allocated managed heap objects to uphold memory safety, rented buffers from ArrayPool<byte> bypass initialization by design for performance reasons. Applications using pooled memory are responsible for tracking exact data boundaries or explicitly requesting zeroed memory upon return.

The root cause of CVE-2026-114150 is an interaction between non-zeroed memory pool recycling and improper slice boundary tracking within ASP.NET Core's response buffering streams. When HttpLoggingMiddleware or OutputCachingMiddleware intercepts an HTTP request, it replaces the default IHttpResponseBodyFeature stream with an intermediate buffering stream (ResponseBufferingStream). As the application pipeline writes response data, the buffering stream leases underlying byte[] segments from ArrayPool<byte>.Shared or MemoryPool<byte> to stage the payload.

Because ArrayPool<byte> organizes buffers into power-of-two size buckets (for example, 4,096 bytes, 8,192 bytes, or 16,384 bytes), a request for a buffer almost always yields an array whose physical capacity (byte[].Length) exceeds the actual number of bytes written during a given HTTP response. When Request $A$ completes, its rented buffer segment—populated with up to $N$ bytes of potentially sensitive response data—is returned to the pool via ArrayPool<byte>.Shared.Return(buffer, clearArray: false). Leaving clearArray set to false avoids the CPU cost of zeroing memory, which is safe only if all subsequent consumers strictly obey the high-water mark of their own write operations.

The vulnerability triggers during a subsequent Request $B$ that leases the exact same memory segment from the pool and writes a smaller payload of $M$ bytes, where $M < N$. Within the vulnerable preview builds of ASP.NET Core 11.0, the boundary tracking logic inside the buffering and logging pipeline fails to constrain the read window strictly to the range [0..M). Instead of exposing a tightly bounded slice (ReadOnlyMemory<byte>.Slice(0, actualBytesWritten)), the stream exposes the broader underlying segment or fails to reset internal offset state across stream reuse cycles.

When the downstream consumer—such as the HTTP Logging sink or W3C Logger—iterates over the buffered response body to record telemetry, it reads past index $M$ up to the segment's previous watermark $N$ or full buffer capacity. The residual bytes in the interval [M..N) contain the uninitialized tail of Request $A$'s response body, resulting in cross-request memory disclosure.

The affected components center around response body buffering and logging tests and implementations tracked in the dotnet/aspnetcore repository, specifically involving src/Middleware/OutputCaching/test/CachedResponseBodyTests.cs (tracked under issue #61053), src/Middleware/HttpLogging/test/W3CLoggerTests.cs (issue #61052), and src/Servers/HttpSys/test/FunctionalTests/ResponseBodyTests.cs (issue #63532). While the vulnerability manifests in the core buffering streams utilized by these components, examining the buffer leasing and slicing mechanics illustrates the exact programmatic flaw and its remediation in the .NET 11.0.0 GA release.

In the vulnerable pattern, a response buffering stream rents a segment from the pool and copies or writes outgoing response bytes into it. When the buffered content is later extracted for logging or caching, passing the raw segment without slicing to the active write count exposes the uninitialized tail:

// VULNERABLE PATTERN: Under-constrained buffer exposure and unzeroed pool return
public sealed class ResponseBufferingStream : Stream
{
    private byte[]? _rentedBuffer;
    private int _bytesWritten;
 
    public override void Write(ReadOnlySpan<byte> buffer)
    {
        if (_rentedBuffer == null)
        {
            // Rents a bucketed array (e.g., 4096 bytes) containing stale data from prior requests
            _rentedBuffer = ArrayPool<byte>.Shared.Rent(Math.Max(buffer.Length, 4096));
        }
 
        buffer.CopyTo(_rentedBuffer.AsSpan(_bytesWritten));
        _bytesWritten += buffer.Length;
    }
 
    // FLAW: Exposes the entire rented buffer or improperly tracked segment length
    // rather than clamping strictly to _bytesWritten.
    public ReadOnlyMemory<byte> GetBufferedData()
    {
        if (_rentedBuffer == null)
        {
            return ReadOnlyMemory<byte>.Empty;
        }
 
        // Returning the un-sliced buffer exposes [0 .. _rentedBuffer.Length]
        // where [_bytesWritten .. _rentedBuffer.Length] contains prior request data.
        return new ReadOnlyMemory<byte>(_rentedBuffer);
    }
 
    protected override void Dispose(bool disposing)
    {
        if (_rentedBuffer != null)
        {
            // Returning without clearing leaves sensitive payloads in the shared pool
            ArrayPool<byte>.Shared.Return(_rentedBuffer, clearArray: false);
            _rentedBuffer = null;
            // If _bytesWritten is not deterministically reset in IResettable paths, state leaks
        }
        base.Dispose(disposing);
    }
}

To remediate CWE-908 in high-performance .NET streams, the patch in v11.0.0 enforces strict boundary slicing on all read paths and ensures deterministic state cleanup during buffer return and object reset routines:

// PATCHED PATTERN: Strict boundary clamping and sanitized pool management
public sealed class ResponseBufferingStream : Stream, IResettable
{
    private byte[]? _rentedBuffer;
    private int _bytesWritten;
 
    public override void Write(ReadOnlySpan<byte> buffer)
    {
        if (_rentedBuffer == null)
        {
            _rentedBuffer = ArrayPool<byte>.Shared.Rent(Math.Max(buffer.Length, 4096));
            _bytesWritten = 0;
        }
 
        buffer.CopyTo(_rentedBuffer.AsSpan(_bytesWritten));
        _bytesWritten += buffer.Length;
    }
 
    // FIX 1: Strictly clamp the exposed ReadOnlyMemory slice to [0 .. _bytesWritten]
    public ReadOnlyMemory<byte> GetBufferedData()
    {
        if (_rentedBuffer == null || _bytesWritten == 0)
        {
            return ReadOnlyMemory<byte>.Empty;
        }
 
        // Prevents downstream loggers or stream consumers from reading residual tail bytes
        return new ReadOnlyMemory<byte>(_rentedBuffer, 0, _bytesWritten);
    }
 
    public void Reset()
    {
        if (_rentedBuffer != null)
        {
            // FIX 2: Clear the active region or set clearArray: true to prevent cross-request residue
            ArrayPool<byte>.Shared.Return(_rentedBuffer, clearArray: true);
            _rentedBuffer = null;
        }
        // FIX 3: Deterministically reset length trackers
        _bytesWritten = 0;
    }
}

Fix Completeness Assessment

The remediation applied in .NET 11.0.0 is comprehensive for built-in ASP.NET Core buffering middleware. By enforcing invariant slicing (Slice(0, actualBytesWritten)) before passing memory blocks to HttpLoggingMiddleware or OutputCachingMiddleware, downstream readers cannot access uninitialized indices even if the underlying ArrayPool<byte> contains non-zero bytes. However, third-party developers implementing custom IHttpResponseBodyFeature wrappers or custom MemoryPool<byte> managers remain susceptible to variant bugs if they expose raw array references rather than bounded Span<byte> or Memory<byte> slices.

Exploiting CVE-2026-114150 over the network requires specific environmental conditions and timing alignment, reflected in its High Attack Complexity (AC:H) CVSS metric. No authentication (PR:N) or user interaction (UI:N) is required to trigger the buggy code path, provided the target application exposes endpoints routed through response buffering middleware.

Prerequisites

1. Vulnerable Runtime: The target web server must run an affected build of ASP.NET Core (>= 11.0.0-preview.1 and < 11.0.0).
2. Middleware Configuration: The application must have response body buffering active, such as HttpLoggingMiddleware configured with HttpLoggingFields.ResponseBody or OutputCachingMiddleware buffering dynamic responses.
3. Observable Output Channel: The attacker must either receive the over-read buffer directly via a downstream stream consumer that reflects the buffered stream length, or have read access to the diagnostic log sinks (such as shared log aggregators, exposed telemetry endpoints, or multi-tenant log views) where HttpLoggingMiddleware writes the un-truncated buffer.

Attack Sequence

1. Pool Priming: Legitimate authenticated users interact with the application, requesting endpoints that return sizeable sensitive payloads (for example, GET /api/v1/account/tokens returning OAuth Bearer tokens, session cookies, or PII). When these responses complete, their underlying byte[] segments are returned to ArrayPool<byte>.Shared containing the cleartext response bodies.
2. Concurrency & Timing Alignment: Because ArrayPool<byte>.Shared uses per-core thread-local slots backed by shared buckets, buffers returned on a specific processor core are immediately prioritized for the next allocation request of the same size bucket on that same core.
3. Triggering Short Responses: The attacker transmits high-frequency, unauthenticated HTTP requests to lightweight endpoints that still pass through the buffering middleware but yield minimal response bodies (e.g., a 2-byte {} JSON response or a short 404 Not Found message).
4. Tail Capture: When the buffering stream leases the recently freed segment to handle the attacker's short response, only the first few bytes of the buffer are overwritten. As the middleware flushes the buffered content to the logging sink or downstream response consumer without clamping the length, the trailing bytes from the victim's prior response are appended directly after the short payload.

Currently, no public Proof-of-Concept (PoC) scripts or automated exploitation modules exist in Exploit-DB, Metasploit, or GitHub (Exploit Code Maturity: Unproven).

CVE-2026-114150 is rated Medium Severity with a CVSS v3.1 base score of 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N). The impact is strictly confined to Confidentiality (C:H), with no direct capability to modify server state (I:N) or degrade service availability (A:N).

Concrete Security Consequences

Because ArrayPool<byte>.Shared is a process-wide singleton within the .NET runtime, every component within the ASP.NET Core worker process shares the same underlying memory buckets. Consequently, the residual memory leaked from an uninitialized buffer segment is not restricted to a single endpoint or controller. Any data serialized into a buffered HTTP response across the entire application lifecycle is subject to disclosure, including:

• Authentication Material: JWTs, OAuth2 access and refresh tokens, session identifiers, and API keys returned in login or token-refresh response bodies.
• Personally Identifiable Information (PII): Usernames, email addresses, financial records, and healthcare data returned by REST or GraphQL APIs.
• Internal Application State: Detailed stack traces, internal microservice responses, or cached fragments processed by the same worker process.

Cross-Boundary Log Contamination

In enterprise environments where HttpLoggingMiddleware is enabled to satisfy audit and compliance requirements, this vulnerability creates a severe secondary exposure vector: log contamination. Security analysts, support engineers, and external log-processing pipelines normally granted access to sanitized or non-sensitive endpoint logs will inadvertently receive cleartext sensitive payloads spliced onto benign health-check or status log entries. Furthermore, if an attacker subsequently compromises an exposed session token harvested from the leaked tail buffer, they can pivot to full account takeover and privilege escalation within the target application.

Microsoft has resolved CVE-2026-114150 in the general availability (GA) release of .NET 11.0.0 and Microsoft Visual Studio 2026 version 18.12.0. Organizations running preview builds of .NET 11.0 must upgrade their SDKs, runtimes, and hosting bundles immediately.

Primary Remediation: Runtime & IDE Upgrade

Upgrade all target deployment environments, build agents, and container base images from .NET 11.0.0-preview.* to .NET 11.0.0 (GA) or later:

• Linux / macOS / Windows (.NET Runtime & SDK): Update to 11.0.0.
• Container Images: Update Dockerfile references from mcr.microsoft.com/dotnet/aspnet:11.0-preview to mcr.microsoft.com/dotnet/aspnet:11.0.
• Visual Studio 2026: Update via the Visual Studio Installer to version 18.12.0 or later.

Configuration Workarounds

If immediate runtime upgrading is blocked by deployment freezes, operators can neutralize the primary vulnerable code path by disabling response body buffering in HttpLoggingMiddleware. Modify the service registration in Program.cs to exclude HttpLoggingFields.ResponseBody:

using Microsoft.AspNetCore.HttpLogging;
 
var builder = WebApplication.CreateBuilder(args);
 
builder.Services.AddHttpLogging(logging =>
{
    // WORKAROUND: Explicitly omit HttpLoggingFields.ResponseBody
    // to prevent ResponseBufferingStream from leasing pooled body buffers.
    logging.LoggingFields = HttpLoggingFields.RequestPropertiesAndHeaders 
                          | HttpLoggingFields.ResponsePropertiesAndHeaders;
});
 
var app = builder.Build();
app.UseHttpLogging();
app.Run();

> [!WARNING] > Ensure HttpLoggingFields.All is not used in HttpLoggingOptions, as All implicitly includes HttpLoggingFields.ResponseBody and activates response stream buffering.

Detection & Auditing

Security teams should audit existing log storage and SIEM indices collected from .NET 11.0 preview environments for signs of buffer tail leakage:

1. Malformed Payload Detection: Search HTTP response body logs for valid JSON or XML payloads that are immediately followed by unparsed trailing characters, truncated JSON fragments, or binary null bytes (\u0000).
2. Length Mismatch Analysis: Compare the logged HTTP Content-Length response header against the actual character/byte length recorded in the ResponseBody log field. Any entry where length(LoggedResponseBody) > Content-Length indicates that uninitialized buffer tail data was emitted.