CVE-2026-111497 in .NET: Brotli Fix Leaves .NET 6 Exposed

On October 25, 2026, Microsoft released out-of-band security updates for .NET 8.0.33, 9.0.22, 10.0.14 and 11 RC3. Microsoft does not ship .NET updates between Patch Tuesdays without a reason, and the reason here is CVE-2026-111497, the out-of-bounds write in Google's Brotli decoder that the industry has been calling Node2Shell since Node.js patched it on October 21 and HTTP2Shell since it surfaced in Python, Bun, Envoy and now the .NET runtime.

.NET bundles its own copy of that decoder. It is compiled into the shared runtime behind BrotliStream, BrotliDecoder, HttpClient's automatic response decompression and ASP.NET Core's request decompression middleware. A crafted Brotli stream reaching any of those paths can corrupt process memory. Microsoft rates the .NET exposure High, 8.1 on CVSS 3.1, and lists information disclosure, denial of service and elevation of privilege as outcomes; Google, as the CVE's numbering authority, scores the underlying library flaw 9.2 Critical on CVSS 4.0.

Microsoft's advisory covers .NET 8 and later. It says nothing about .NET 6, and Microsoft advisories never do: end-of-life versions are not enumerated. HeroDevs read the vendored decoder source at the final .NET 6 release tag and confirmed it is the same affected code. There will be no .NET 6 fix from Microsoft, and on November 10, 2026, .NET 8 and .NET 9 reach end of support as well, making this one of the last public patches those runtimes will ever receive. NES for .NET, HeroDevs' Never-Ending Support, is the remediation path for every one of those lines.

TL;DR: CVE-2026-111497 in .NET 6

Who is affected: .NET version matrix

The decoder ships inside the runtime, so every application on an affected runtime carries it. Whether it can be reached depends on configuration, covered below. Framework-dependent apps get the fix from the installed shared runtime; self-contained and NativeAOT apps carry their own copy and must be rebuilt against the patched runtime packs.

HeroDevs verified the .NET 6 and 7 rows directly. The .NET 6.0.36 and 7.0.20 release tags vendor Brotli 1.0.9 (BROTLI_VERSION 0x1000009) and their decode.c carries the unpatched DecodeBlockTypeAndLength() path with none of the fix's error handling. 1.0.9 sits inside the affected range of 1.0.3 through 1.2.0.

How to confirm exposure in a .NET application:

• Check the runtime: dotnet --list-runtimes on each host, and the runtime baked into each container image and self-contained publish. Anything below 8.0.33, 9.0.22 or 10.0.14, or on any 6.x or 7.x, carries the vulnerable decoder.
• Search for outbound decompression: AutomaticDecompression set to DecompressionMethods.Brotli or DecompressionMethods.All on HttpClientHandler or SocketsHttpHandler. All is the common one, and it includes Brotli.
• Search for inbound decompression: AddRequestDecompression / UseRequestDecompression in ASP.NET Core 7 and later. On .NET 6 that middleware does not exist, so an inbound path only exists through third-party middleware or custom code.
• Search for direct use: new BrotliStream( with CompressionMode.Decompress, or BrotliDecoder, anywhere data from outside the trust boundary is decoded. Message queues, file ingestion and cache layers are the usual places.
• Check your SCA output: scanners that key on the bundled Brotli version will flag every affected runtime regardless of configuration, and that finding has to be closed either way.

Technical detail: the decoder bug .NET inherited

The Brotli format switches between Huffman block types as a stream progresses. DecodeBlockTypeAndLength() in dec/decode.c handles those switches and has a special case for streams declaring only one block type, where a switch cannot occur and the function returns false. The streaming decoder treated that false as "need more input" instead of a format error, and kept appending bytes into an eight-byte internal buffer. That is the out-of-bounds write. The upstream fix adds a hard error, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH, and stops.

The fix was committed to Google's public Brotli repository on February 27, 2026, without a release or advisory, and stayed unnoticed until OpenAI's Codex Security team reported it. Brotli 1.0.10, 1.1.1 and 1.2.1 shipped on October 21, 2026. Microsoft pulled the fix into the .NET runtime four days later.

Microsoft's vector carries High attack complexity (AC:H), which is why its 8.1 sits below Google's 9.2. The disagreement is about reliability of exploitation, not about whether the write happens. Public proof-of-concept code exists; one red team reported code execution on an unmodified Node.js image through the same decoder, with the caveat that it did not land on every attempt. For .NET, treat memory corruption and crash as the floor, and treat anything in the process's memory, including tokens and connection strings, as potentially readable.

Microsoft's advisory is precise about reachability, and that precision is useful. A .NET application is not exposed simply because the affected runtime is installed. It is exposed when it decodes attacker-controlled Brotli through one of three paths: HttpClient automatic decompression configured to include Brotli, ASP.NET Core request decompression with br enabled, or explicit BrotliStream / BrotliDecoder calls on untrusted data. The first of those is the one most teams underestimate. Any service that fetches URLs an outside party can influence, with DecompressionMethods.All set because that is what the sample code used, is advertising br and decoding whatever comes back.

How to fix CVE-2026-111497

If you are on .NET 8, 9 or 10

The right path forward is Microsoft's October 25, 2026, release: 8.0.33, 9.0.22 or 10.0.14 (or 11 RC3 for preview users). Install the runtime update on every host, restart services so running processes pick up the new native library, rebuild container images from updated base images, and republish self-contained and NativeAOT applications against the patched runtime packs, since those embed their own copy and do not benefit from a host update.

Until that is deployed, Microsoft's guidance is to stop decoding untrusted Brotli: remove br from an existing request decompression configuration, drop DecompressionMethods.Brotli from an existing AutomaticDecompression setting, and stop passing untrusted data to Brotli APIs. Do not introduce decompression settings that were not already there; that creates new exposure rather than removing it.

Note the calendar. .NET 8 and .NET 9 both reach end of support on November 10, 2026. This out-of-band release is among the last Microsoft will ship for either. After that date, the next Brotli CVE, or the next anything, lands on those runtimes with no vendor fix.

If you are on .NET 6

There is no Microsoft fix. .NET 6 left support in November 2024. HeroDevs confirmed the vulnerable decoder at the final 6.0.36 tag, and every application on the shared 6.0 runtime, and every self-contained 6.0 publish, carries it.

Moving a .NET 6 application to .NET 8 is a real migration: a target framework change, a dependency audit for packages that dropped net6.0 support, breaking-change review across ASP.NET Core and EF Core, and a full regression cycle. For an estate of services it is a project measured in quarters. 

If that migration isn't feasible on your current timeline, NES for .NET delivers a remediated 6.0.x runtime, SDK and ASP.NET Core runtime that resolves CVE-2026-111497 on the version you already run, with no code changes. 

Install the NES runtime over the Microsoft one, or pull the NES container image, and the finding closes. NES also publishes the 6.0 runtime packs on its NuGet feed so self-contained publishes pick up the fix too.

Frequently asked questions about CVE-2026-111497 in .NET

Is .NET 6 affected by CVE-2026-111497?

Yes. The .NET 6 runtime vendors Brotli 1.0.9, inside the affected 1.0.3 to 1.2.0 range, and HeroDevs confirmed the unpatched decoder path at the 6.0.36 release tag. Microsoft's advisory does not list .NET 6 because Microsoft does not enumerate end-of-life versions, not because .NET 6 is clean.

Why did Microsoft patch out of band instead of waiting for Patch Tuesday?

Microsoft has not said. Public proof-of-concept code for the decoder bug appeared within a day of the Brotli release, and the next scheduled Patch Tuesday is November 10, which is also the end-of-support date for .NET 8 and 9. Shipping on October 25 gets the fix out two weeks early and ahead of that cutoff.

Is this Node2Shell or HTTP2Shell?

Both names refer to this CVE. Node2Shell stuck because Node.js shipped the first fix; HTTP2Shell spread once the same bug was confirmed across Python, Bun, Envoy, Istio and .NET. It is one bug in one library, bundled into many products. It has nothing to do with the HTTP/2 protocol.

Taking action on CVE-2026-111497 in .NET

CVE-2026-111497 is a decoder bug Microsoft inherited from Google and fixed for the runtimes it still supports. The urgency is Microsoft's own: an out-of-band release, two weeks ahead of schedule, for a flaw with public exploit code. On .NET 8, 9 and 10 the job is install, restart, rebuild. On .NET 6 there is no install to run. Because there is no upstream patch path for .NET 6, there is no timeline for public remediation. Any exposed deployment remains vulnerable indefinitely.

Find every .NET runtime in your estate, including the ones baked into containers and self-contained publishes. Patch the supported ones now. For .NET 6, and for .NET 8 and 9 after November 10, HeroDevs NES for .NET delivers remediated runtimes that resolve CVE-2026-111497 on the version you already run.

Check NES for .NET coverage for your version, or talk to our team.

Related reading

• Microsoft Security Advisory CVE-2026-111497
• .NET October 2026 out-of-band security updates
• Brotli v1.2.1 release notes
• CVE-2026-111497 (Node2Shell): Node.js Brotli RCE, EOL Risk

‍