HTTP2Shell Hits Microsoft .NET — Why OOB Patches Are Only Half the

The Patch That Misses the Point

Microsoft released an emergency out-of-band security update on October 25 for .NET 8 (v8.0.33), .NET 9 (v9.0.22), and .NET 10 (v10.0.14), plus a release candidate for .NET 11. The fix addresses CVE-2026-111497 — a memory corruption flaw in Google’s Brotli decompression library that has been called both Node2Shell and HTTP2Shell.

That dual naming is itself a signal. This is not a single vendor’s bug. It lives in Brotli, a compression format used across Node.js, Python, Bun, Envoy, and now Microsoft’s runtime stack. The vulnerability allows an unauthenticated attacker to read or corrupt process memory, leading to information disclosure, denial of service, or privilege escalation.

Getting the patch installed is the easy part. Understanding who remains exposed is where the real risk hides.

Why This Isn’t Just a .NET Story

The Japanese-language coverage from Windows Magazine (窓の杜) emphasizes operational detail — version numbers, patch tiers, container rebuild instructions — that Western reporting has been slower to match. That gap matters here because HTTP2Shell is fundamentally a supply-chain problem, not a product problem.

Brotli is baked into the compression pipeline of virtually every modern web stack. An attacker who controls or intercepts traffic between a client and a Brotli-enabled server can craft a malformed compressed payload that triggers the memory corruption. The same flaw appeared in Node.js first, hence the Node2Shell name, but it does not respect runtime boundaries. It lives at the decompression layer, where HTTP response bodies are unpacked before your application code ever sees them.

Microsoft’s inclusion of PowerShell updates alongside Visual Studio and .NET runtime patches suggests the organization recognizes this isn’t contained. The fact that CVE-2026-114148 — a separate Linux-specific tarball ownership metadata vulnerability enabling local privilege escalation — was patched in the same window reinforces that .NET’s attack surface extends beyond the compression library alone.

The Self-Contained Trap

Here is what most breach timelines will miss in the first days: the OOB patch only helps environments running the shared .NET runtime on the OS.

If your application is self-contained — meaning the .NET runtime ships with the app binary rather than relying on the OS-installed version — installing the updated runtime on the host machine does nothing. The app continues using its bundled runtime. The same applies to containerized deployments that pin a specific .NET image tag. Pulling a newer base image without rebuilding and redeploying leaves the vulnerability intact.

Microsoft is clear about this. The guidance says organizations must rebuild and redistribute self-contained applications with the updated runtime. Containers need to be rebuilt against patched images. You cannot patch your way out of this by updating the host OS alone.

That distinction separates organizations that will slip through the cracks from those that won’t. Many enterprises run hundreds or thousands of self-contained microservices, each compiled at different times with different runtime versions. Inventory alone is a non-trivial task.

Default States and Hidden Risk

There is a silver lining in Microsoft’s posture: Brotli request decompression and response decompression are disabled by default in .NET. If your application never explicitly enabled these features, you are likely not vulnerable to the decompression path of CVE-2026-111497.

But that protection disappears the moment any library in your dependency tree calls into System.IO.Compression’s Brotli API directly. Third-party packages, even those that don’t advertise compression as a feature, may route traffic through Brotli under the hood — especially if they handle HTTP responses that were compressed by an upstream CDN or load balancer.

This is where audit discipline matters. Running dotnet –list-runtimes will tell you whether the host OS is patched. It will not tell you whether your application code or its transitive dependencies are making direct Brotli calls. Developers need to check their own dependency graphs.

What Happens Next

The .NET 11 Release Candidate 3 is already available, and Microsoft is urging users of RC2 to upgrade. That pattern — pushing early adopters toward the latest candidate — is standard practice when a critical vulnerability is disclosed mid-release-cycle. It signals that the fix is considered stable enough for production deployment in .NET 11 but that the organization wants to move the RC3 user base off older candidate builds that may carry additional unfixed issues.

The simultaneous patches for CVE-2026-70197 (a SocketAsyncEventArgs memory corruption bug from the October 13 update that was incomplete) and CVE-2026-102870 (a Blazor WebAssembly debugger flaw) suggest Microsoft’s October update cycle has been rough. Two previously-patched vulnerabilities required follow-up fixes in the same window. That pattern raises the probability that other issues exist in recent releases that have not yet surfaced.

The Real Takeaway

HTTP2Shell is a reminder that compression libraries are part of your security perimeter. Brotli, Deflate, GZIP — these are not implementation details. They are attack surfaces.

The patch exists. The version numbers are published. The harder work is answering: which of our services use self-contained deployments? Which containers need rebuilding? Which third-party libraries call Brotli APIs directly? How many of our .NET 8, 9, and 10 installations have runtimes that haven’t been updated because nobody thought to check?

Windows-only .NET Framework is unaffected. That boundary is clear. Everything else — and there is a lot of everything else — needs attention before the next exploit hits.