Microsoft Rushes .NET Patches for Critical HTTP2Shell Flaw

X (Twitter) Facebook Pinterest LinkedIn E-mail

Microsoft has released emergency .NET updates to fix HTTP2Shell (CVE-2026-111497), the critical flaw in the Brotli decoder, and recommends installing them as soon as possible: .NET 8.0.33, 9.0.22, 10.0.14 and 11 RC3. For anyone running .NET in the cloud, containers or Kubernetes, updating the server runtime isn’t enough: self-contained applications and container images have to be rebuilt.

The .NET patch for HTTP2Shell in 20 seconds

Microsoft released .NET 8.0.33, 9.0.22, 10.0.14 and 11 RC3 on October 25.
It affects applications that decompress untrusted Brotli data; it isn’t enabled by default.
Self-contained apps, NativeAOT, and containers must be rebuilt.
Public proof-of-concept exploits exist, and CISA considers it actively exploited.

The flaw, an out-of-bounds write in Google’s Brotli library, can cause crashes, memory leaks and, in some cases, remote code execution. Opensecurity explains in detail how HTTP2Shell affects .NET, ClickHouse and Apache Arrow because they bundle their own copies of Brotli. The .NET runtime shipped with version 1.1.0 built in, and Microsoft released its fixed versions out of cycle on October 25, according to BleepingComputer and Brandefense. .NET Framework isn’t affected.

Which .NET applications are exposed

According to Microsoft, Brotli decompression isn’t enabled by default in a standard .NET or ASP.NET Core installation, so exposure depends on each application. At risk are those that process untrusted Brotli data through:

ASP.NET Core’s request decompression.
HttpClient’s automatic response decompression.
The Brotli APIs in System.IO.Compression, such as BrotliDecoder and BrotliStream.

The two vectors are symmetric: a server that accepts requests with Content-Encoding br, or a client that downloads a compressed response from a malicious or compromised server. In microservices architectures, where one service calls another and external APIs, the second case matters just as much as the first.

How to patch on servers, containers and Kubernetes

The first step is inventorying which runtimes are installed on each machine:

dotnet --list-runtimes

After updating, processes need to be restarted so they load the new runtime. Applications published as self-contained or with NativeAOT carry their own runtime inside, so they aren’t fixed by updating the server: they have to be recompiled and redeployed. The same goes for container images, which must be rebuilt on a fixed base image and redeployed to clusters, and for the build environments and CI/CD pipelines that produce those artifacts.

If the patch can’t be applied right away, stopgap measures include blocking Brotli-compressed requests at the proxy or WAF, or disabling its decompression in the application. Azure WAF includes a rule, 920450, that blocks crafted requests it analyzes by default, and Cloudflare has published emergency rules that only log by default. None of these measures protect a client application that downloads a malicious response, so they don’t replace updating. Public proof-of-concept exploits exist, and CISA added the flaw to its catalog of exploited vulnerabilities on October 27, the same kind of urgent treatment CISA gave another critical Microsoft flaw this year, the Netlogon vulnerability affecting Windows domains.

Frequently asked questions

Which .NET versions fix HTTP2Shell?

.NET 8.0.33, 9.0.22, 10.0.14 and .NET 11 RC3. .NET Framework isn’t affected.

Is my .NET application exposed?

Only if it decompresses untrusted Brotli data through ASP.NET Core’s request decompression, HttpClient, or the Brotli APIs in System.IO.Compression; it isn’t enabled by default.

Is updating .NET on the server enough?

Not for self-contained applications, NativeAOT, or containers, which have to be recompiled and redeployed.

How do I check my installed .NET version?

With the dotnet –list-runtimes command, which shows the runtimes installed on the machine.

Sources: