Microsoft's Brotli Patch Shows Why .NET Exposure Varies

Microsoft released emergency .NET updates on October 25 for a flaw in Brotli, the compression software used inside multiple products. The bug, CVE-2026-111497, can corrupt a program’s memory when it decodes malicious compressed data. Microsoft issued out-of-band fixes for .NET 8, 9 and 10, plus .NET 11 Release Candidate 3, and urged users to update as soon as possible. Node.js and other projects have also shipped fixes. One vulnerable decoder has produced several separate patch jobs.

For anyone responsible for an application, the useful question is more precise than “Do we use Brotli?” It is: Which copy of the decoder does this application use, and can data from someone we do not trust reach it? The first answer tells you what to update. The second tells you how exposed that application may be while you do it. A vulnerability listing alone cannot answer both.

Brotli compresses data for transmission and storage; its decoder reconstructs that data for an application to use. Here, a malformed stream can make the decoder treat an invalid block switch as a request for more input. It then continues adding bytes to an internal eight-byte buffer, writing beyond its bounds. Memory corruption can crash a process or expose data, and some affected applications may permit code execution. Those are potential outcomes of a reachable flaw, not outcomes every installation will suffer.

An attacker needs the application to decode the crafted stream. That could happen when a server accepts compressed input from a client. It could also happen when an application fetches a compressed response from a server an attacker controls. The nickname “HTTP2Shell” does not confine the bug to HTTP/2: other software paths that decode attacker-controlled Brotli data can encounter it too.

Why a .NET Installation Needs a Closer Look

Microsoft says a standard .NET or ASP.NET Core installation does not enable Brotli decompression by default. Its guidance identifies three routes that may expose an application: ASP.NET Core request decompression, HttpClient automatic response decompression, and direct use of the System.IO.Compression Brotli APIs. Teams have to opt into the first two or call the APIs themselves.

That configuration detail gives operators a way to prioritize, though it is no reason to leave a vulnerable supported runtime unpatched. A service that accepts compressed requests needs its inbound path checked. A service that fetches responses needs its outbound client behavior checked too. Blocking compressed requests at a proxy may reduce the first route while leaving the second open. The practical test is whether an untrusted compressed stream reaches the decoder, not whether a web service merely sends Brotli-compressed pages to its users.

The .NET update is a product fix. A team running one of the affected .NET versions should identify the applicable Microsoft release, deploy it and restart or redeploy affected workloads so running processes use updated code. Applications using Brotli directly deserve the same exposure review as those using framework features. Microsoft’s opt-in language describes .NET’s defaults; it does not measure how many deployed applications have enabled those features. Nor does it settle whether a separate component in the same application has its own vulnerable decoder.

The Fix Existed Before the Security Release

The dates reveal another wrinkle. OpenAI says the root-cause issue had been fixed in Brotli’s source code in February, before its security implications were recognized, and that no newer Brotli release was then available. On October 21, Node.js published version 24.22.1 as a security release; its release record lists a Brotli dependency change for CVE-2026-111497. Microsoft’s .NET fixes followed on October 25.

A change in a project’s source tree is one step. Someone must put it in a release; products that incorporate that code must take the fix into their own builds; users must install those builds. The February date therefore does not mean .NET or Node.js users had a February patch waiting for them. OpenAI’s account explains that the change was not understood as a security fix at the time. It does not, by itself, assign responsibility for every project’s later release schedule.

Node.js is a useful comparison because its affected release lines bundle the Brotli decoder. Its 24.22.1 release incorporated a fix into that dependency. Updating only a machine’s system Brotli library will not replace a vulnerable copy bundled in a Node.js build. Rapid7 identifies fixed Node.js releases for the 22.x, 24.x and 26.x lines as 22.23.4, 24.22.1 and 26.12.1, respectively. Operators need a fixed release for the line they actually deploy, including the runtime inside any container image they run.

The comparison has a limit: bundling tells you where the patch must land, while application behavior determines whether an attacker can reach the decoder. For Node.js, Rapid7 describes the relevant path as an application passing attacker-controlled Brotli data to the decoder through node:zlib. For .NET, Microsoft points to opt-in framework features and direct API calls. Neither product’s default or patch instructions can be copied wholesale onto the other. A host may also run both, giving its operators two inventories to check rather than one convenient checkbox.

Put Severity Beside Exposure

The possible consequences justify prompt maintenance. Microsoft says an unauthenticated attacker could read or corrupt process memory, with potential information disclosure, denial of service or privilege escalation. Node.js-related guidance also identifies possible remote code execution when the vulnerable decoder is reachable. As of October 26, there was no known exploitation in the wild. That is a time-bound observation, not a promise about future attacks; proof-of-concept exploits had already been published.

If a team cannot update immediately, restricting the paths that decode untrusted Brotli data may reduce exposure temporarily. Removing inbound Brotli support alone is an incomplete measure for an application that also decodes fetched responses. Disabling decompression can break expected behavior, so owners need to test that choice against what their service actually does. The longer-term work belongs with product maintainers and deployment teams: ship the corrected dependency in each affected product, then make sure the running copy has changed.

Microsoft’s emergency release closes a .NET patch path. Whether it closes an application’s risk depends on the version it runs, the decoder it reaches and the compressed data it accepts. Those are answerable questions, and considerably more useful than counting how many machines have Brotli installed.