CVE-2026-111497 / GHSA-p3jp-9v83-76w9: Out-of-Bounds Heap Write in Microsoft .NET Brotli Decoder

The Microsoft .NET runtime embeds the native C implementation of Google's Brotli compression library (src/native/external/brotli/c/dec/decode.c) to support high-performance stream decompression. Managed applications interface with this native code via the System.IO.Compression.BrotliStream and System.IO.Compression.BrotliDecoder classes. These APIs are utilized across the .NET ecosystem, including within ASP.NET Core request decompression middleware and HttpClient automatic response decompression handlers.

A vulnerability identified as CVE-2026-111497 (and tracked in the GitHub Advisory Database as GHSA-p3jp-9v83-76w9) exists in Brotli versions prior to 1.1.1, which are bundled across .NET 8, .NET 9, .NET 10, and .NET 11 Preview runtimes. The flaw is classified as an Out-of-bounds Write (CWE-787) and a Classic Buffer Overflow (CWE-120). It stems from improper error handling during the decoding of block-type switch commands within a Brotli meta-block.

When the native decoder processes a compressed stream with sufficient input and output buffer margins, it enters an optimized execution path that fails to verify the return value of block-switch decoding functions. If a bitstream declares a maximum of one block type for literals, insert/copy commands, or distances, any subsequent block-switch command is invalid. Because the error status is ignored in the optimized path, the decoder continues execution with inconsistent state variables and uninitialized ring buffer offsets.

An unauthenticated attacker who can submit crafted Brotli payloads to a .NET service or client that decompresses untrusted streams can trigger an out-of-bounds heap write. Depending on heap layout and application architecture, this memory corruption leads to immediate process termination (denial of service), unauthorized memory disclosure, or arbitrary code execution within the context of the .NET host process.

Brotli compressed streams are organized into meta-blocks that encapsulate three distinct symbol categories: literals, insert-and-copy commands, and backward distances. Each category within a meta-block can be partitioned into up to 256 distinct block types, allowing the compressor to adapt Huffman trees to localized data characteristics. During decompression, the BrotliDecoderState structure maintains ring buffers (s->block_type_rb) to track the current and previous block types for each category, alongside arrays of Huffman trees (s->htree_command) and context map slices (s->dist_context_map_slice).

When the remaining length of the current block for a specific category reaches zero (s->block_length[i] == 0), the decoder invokes a block-switch routine (DecodeLiteralBlockSwitch, DecodeCommandBlockSwitch, or DecodeDistanceBlockSwitch) to determine the next block type and its corresponding length. Internally, these routines delegate to DecodeBlockTypeAndLength(), which begins by reading the total number of block types declared for that category in the current meta-block header (s->num_block_types[tree_type]). If max_block_type <= 1, a block switch is semantically invalid because no alternative block types exist, and DecodeBlockTypeAndLength() returns BROTLI_FALSE.

The root cause of CVE-2026-111497 lies in how the main decompression loop, ProcessCommandsInternal(), invokes these block-switch routines using the BROTLI_SAFE preprocessor macro. To maximize throughput, ProcessCommandsInternal() is compiled into two variants controlled by the safe parameter: a bounds-checked slow path (safe != 0) used when input or output buffers are near depletion, and an unchecked fast path (safe == 0) used when sufficient buffer margins are guaranteed.

In the vulnerable implementation, the BROTLI_SAFE(METHOD) macro only checked the boolean return value of METHOD when safe != 0. Even in that slow path, a BROTLI_FALSE return value caused the macro to set result = BROTLI_DECODER_NEEDS_MORE_INPUT and suspend decoding, misinterpreting a fatal bitstream format error as a transient buffer underflow. Worse, when executing in the fast path (safe == 0), the macro expanded directly to METHOD; without inspecting the return value at all.

Consequently, when an attacker supplies a crafted meta-block declaring num_block_types <= 1 alongside a short initial block length and sufficient trailing padding to trigger the fast path (safe == 0), DecodeBlockTypeAndLength() aborts early and returns BROTLI_FALSE. The caller (DecodeLiteralBlockSwitchInternal, DecodeCommandBlockSwitchInternal, or DecodeDistanceBlockSwitchInternal) exits immediately without updating the active Huffman tree pointers, context modes, or resetting the block length counter. Execution resumes in ProcessCommandsInternal(), where subsequent literal insertions and LZ77 dictionary copy operations read from invalid tree structures and write decompressed bytes past the boundaries of the allocated output window or ring buffer.

The vulnerability was remediated in the .NET runtime via Pull Request #136471 (commit f3d8b2f230bc7c9899df6eef2d41e2748107cffa), which upgraded the bundled upstream Google Brotli source to version 1.1.1 (upstream commit db0631dfea829194206d269bc7b25d0908cdb97d). The patch modifies both the error reporting granularity in decode.h and the macro execution semantics in decode.c.

First, in src/native/external/brotli/c/include/brotli/decode.h, the previously reserved error code -17 was allocated to explicitly signal invalid block-switch sequences:

/* src/native/external/brotli/c/include/brotli/decode.h */
-  /* -17 code is reserved */                                               \
+  BROTLI_ERROR_CODE(_ERROR_FORMAT_, BLOCK_SWITCH, -17) SEPARATOR           \

In src/native/external/brotli/c/dec/decode.c, the Vulnerable BROTLI_SAFE macro previously ignored return values during fast-path (safe == 0) execution and conflated all BROTLI_FALSE outcomes with BROTLI_DECODER_NEEDS_MORE_INPUT. The patch introduces a new macro, BROTLI_SAFE_WITH_STATUS, which captures a BrotliDecoderErrorCode in both execution branches and immediately halts decoding if the status diverges from BROTLI_DECODER_SUCCESS:

/* Vulnerable Macro in src/native/external/brotli/c/dec/decode.c */
#define BROTLI_SAFE(METHOD)                       \
  {                                               \
    if (safe) {                                   \
      if (!METHOD) {                              \
        result = BROTLI_DECODER_NEEDS_MORE_INPUT; \
        goto saveStateAndReturn;                  \
      }                                           \
    } else {                                      \
      METHOD; /* BUG: Return value discarded */   \
    }                                             \
  }
 
/* Patched Macro in src/native/external/brotli/c/dec/decode.c */
#define BROTLI_SAFE_WITH_STATUS(METHOD)         \
  {                                             \
    BrotliDecoderErrorCode status;              \
    if (safe) {                                 \
      status = Safe##METHOD;                    \
    } else {                                    \
      status = METHOD;                          \
    }                                           \
    if (status != BROTLI_DECODER_SUCCESS) {     \
      result = status;                          \
      goto saveStateAndReturn;                  \
    }                                           \
  }

To support BROTLI_SAFE_WITH_STATUS, the return types of DecodeBlockTypeAndLength() and the internal block-switch wrappers (DecodeLiteralBlockSwitchInternal, DecodeCommandBlockSwitchInternal, and DecodeDistanceBlockSwitchInternal) were changed from BROTLI_BOOL to BrotliDecoderErrorCode. When max_block_type <= 1 is encountered, DecodeBlockTypeAndLength() now returns the fatal BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH code instead of BROTLI_FALSE:

/* src/native/external/brotli/c/dec/decode.c */
-static BROTLI_INLINE BROTLI_BOOL DecodeBlockTypeAndLength(
+static BROTLI_INLINE BrotliDecoderErrorCode DecodeBlockTypeAndLength(
     int safe, BrotliDecoderState* s, int tree_type) {
   brotli_reg_t max_block_type = s->num_block_types[tree_type];
   int tree_offset = tree_type * BROTLI_HUFFMAN_MAX_TABLE_SIZE;
   const HuffmanCode* type_tree = &s->block_type_trees[tree_offset];
   const HuffmanCode* len_tree = &s->block_len_trees[tree_offset];
   BrotliBitReader* br = &s->br;
   brotli_reg_t* ringbuffer = &s->block_type_rb[tree_type * 2];
   brotli_reg_t block_type;
   if (max_block_type <= 1) {
-    return BROTLI_FALSE;
+    return BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH;
   }
   if (safe) {
     BrotliBitReaderState memento;
     BrotliBitReaderSaveState(br, &memento);
     if (!SafeReadBlockSwitch(s, tree_type, &block_type)) {
-      return BROTLI_FALSE;
+      return BROTLI_DECODER_NEEDS_MORE_INPUT;
     }

Finally, all three block-switch call sites inside ProcessCommandsInternal() were migrated from BROTLI_SAFE to BROTLI_SAFE_WITH_STATUS, and a defensive runtime assertion (BROTLI_DCHECK(s->meta_block_remaining_len <= (int)BROTLI_BLOCK_SIZE_CAP);) was added to BrotliDecoderDecompressStream(). This fix completely eliminates the state desynchronization across all three block-switch categories by guaranteeing that neither the safe nor the unsafe loop continues processing commands after an invalid block-switch attempt.

Exploiting CVE-2026-111497 requires the target .NET application to actively process untrusted input streams using the native Brotli decoder. While .NET runtimes include the vulnerable library by default, standard ASP.NET Core servers and HttpClient instances do not enable automatic Brotli decompression in their out-of-the-box configurations. Therefore, an attacker must target an application where a developer has explicitly enabled Brotli support.

Three primary attack vectors expose an application to exploitation:

1. ASP.NET Core Request Decompression (T1190): A web server or API endpoint registers the RequestDecompressionMiddleware via app.UseRequestDecompression(), which includes the BrotliDecompressionProvider (Content-Encoding: br) by default when enabled. An unauthenticated remote attacker can send an HTTP POST or PUT request containing a crafted Brotli bitstream in the request body.
2. HttpClient Response Decompression (T1203): A client application configures SocketsHttpHandler.AutomaticDecompression or HttpClientHandler.AutomaticDecompression with DecompressionMethods.Brotli or DecompressionMethods.All. If the client connects to an attacker-controlled HTTP server or is subject to a machine-in-the-middle (MitM) position, the server can return an HTTP response with Content-Encoding: br containing the malicious payload.
3. Direct Stream/Buffer Processing: The application directly passes user-supplied files, network payloads, or archive entries into System.IO.Compression.BrotliStream or System.IO.Compression.BrotliDecoder.Decompress().

To trigger the vulnerable fast path (safe == 0), the attacker constructs a valid Brotli stream header followed by a meta-block header where num_block_types for literals, commands, or distances is set to 1. However, in a standard bitstream, when num_block_types == 1, the initial block_length is not read from the header and defaults to the maximum block size cap (1 << 24). To force s->block_length[i] to reach zero while num_block_types == 1, the attacker crafts a sequence of commands or meta-block transitions that exhausts the block length counter while keeping enough trailing bytes in the input buffer so the bit reader checks pass and ProcessCommandsInternal() enters the safe == 0 loop.

> [!NOTE] > As of publication, no public Proof-of-Concept (PoC) exploits or weaponized modules exist in ExploitDB, PacketStorm, or GitHub repositories, and CISA has not listed CVE-2026-111497 in the Known Exploited Vulnerabilities (KEV) catalog. Converting the out-of-bounds heap write into reliable remote code execution requires precise manipulation of the unmanaged heap layout in the .NET host process, contributing to the High Attack Complexity (AC:H) rating in the CVSS assessment.

CVE-2026-111497 carries a CVSS v3.1 Base Score of 8.1 (High) and a Temporal Score of 7.1, defined by the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C. Because the vulnerability resides in unmanaged C code (libbrotlidec / System.IO.Compression.Native), memory safety guarantees provided by the .NET Common Language Runtime (CLR) do not prevent or contain the out-of-bounds write.

The immediate and most reliable impact of exploitation is a Denial of Service (High Availability Impact). When the decoder writes decompressed data outside the bounds of the allocated ring buffer or output window, it corrupts adjacent unmanaged heap metadata or hits unmapped memory pages. This triggers an unhandled access violation (SIGSEGV on Linux/macOS or STATUS_ACCESS_VIOLATION on Windows), immediately terminating the entire .NET worker process and dropping all active requests handled by that host.

Beyond process crashes, the flaw presents High Confidentiality and Integrity Impacts. If an attacker grooms the unmanaged heap prior to triggering the bug, the out-of-bounds write can overwrite adjacent data structures, function pointers, or managed object headers pinned in memory for interop. Corrupting internal decoder state or adjacent buffers can cause subsequent compression or network operations to leak unintended memory contents back to the caller, or allow the attacker to hijack control flow and achieve arbitrary code execution under the service account running the .NET application.

The scope of affected targets spans all modern cross-platform .NET releases: .NET 8 (< 8.0.33), .NET 9 (< 9.0.22), .NET 10 (< 10.0.14), and .NET 11 Previews (< 11.0.0-rc.3.26522.148). It affects standard JIT runtimes (Microsoft.NETCore.App.Runtime.*), Mono runtimes (Microsoft.NETCore.App.Runtime.Mono.*), and Ahead-of-Time compiled binaries (Microsoft.DotNet.ILCompiler and Microsoft.NETCore.App.Runtime.NativeAOT.*) across Windows, Linux (glibc and musl), macOS, Android, iOS, and WebAssembly. Legacy .NET Framework versions (e.g., 4.8.x) are unaffected as they do not bundle the vulnerable native Brotli implementation.

The primary remediation is to update the .NET Runtime and SDK to the official patched releases containing Brotli v1.1.1. Administrators and developers should upgrade to .NET 8.0.33 (SDK 8.0.133 / 8.0.427), .NET 9.0.22 (SDK 9.0.123 / 9.0.320), .NET 10.0.14 (SDK 10.0.114 / 10.0.403), or .NET 11.0.0-rc.3.26522.148.

Deployment mechanics dictate how the patch must be applied:

• Framework-Dependent Deployments: Install the updated .NET Runtime or ASP.NET Core Shared Framework on the host machine and restart the application processes or IIS application pools.
• Self-Contained Deployments: Because the native System.IO.Compression.Native binary is bundled directly with the application publish output, developers must rebuild and republish the application using a patched SDK and redeploy the artifacts.
• NativeAOT Applications: NativeAOT statically links the native Brotli decoder into the final machine binary. Developers must update their Microsoft.DotNet.ILCompiler and Microsoft.NETCore.App.Runtime.NativeAOT.* NuGet package references to the patched versions, recompile, and redeploy.

> [!IMPORTANT] > If immediate runtime patching or recompilation is not operationally feasible, teams can neutralize the attack vector via configuration changes that disable Brotli processing while retaining gzip and deflate support.

For ASP.NET Core servers utilizing request decompression middleware, explicitly remove the br provider during service registration:

builder.Services.AddRequestDecompression(options =>
{
    // Mitigate CVE-2026-111497 by removing the Brotli decompression provider
    options.DecompressionProviders.Remove("br");
});

For .NET client applications using HttpClient with automatic response decompression, restrict the AutomaticDecompression flags on the underlying handler to exclude DecompressionMethods.Brotli:

var handler = new SocketsHttpHandler
{
    // Allow only GZip and Deflate; do not use DecompressionMethods.All or Brotli
    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
};
using var httpClient = new HttpClient(handler);