Microsoft Ships Emergency .NET Security Update Over Critical Brotli Flaw
The October 25 out-of-band release fixes a CVSS 10 decompression flaw, re-releases two incomplete patches, and lands with .NET 8 and 9 going dark in two weeks.
Microsoft just published an emergency security patch for .NET, and the team's advice is unambiguous: update as soon as possible. The out-of-band release arrived October 25, 2026, posted by Rahul Bhandari, a Senior Program Manager on the .NET team. It hits .NET 8, 9, and 10, plus .NET 11 RC3. And unlike a routine Patch Tuesday drop, this is the kind of update you don't sit on.
What makes it interesting isn't just the headline flaw. It's the calendar. Two of the runtimes being patched reach end-of-support on November 10, 2026, a mere fifteen days out. After that, .NET 8 (the LTS) and .NET 9 (the STS) stop getting security fixes altogether. So this is arguably among the last patches these versions will ever see. That raises the stakes on two fronts at once.
The new flaws and the unfinished fixes
The headline bug is CVE-2026-111497, a buffer overflow in how .NET handles the Brotli decompression algorithm. Microsoft says it "may allow an unauthenticated attacker to read or corrupt process memory," which opens the door to information disclosure, denial of service, or elevation of privilege. Upstream it's rated Critical at CVSS 10.
Here's the part that should make you sit up: this isn't a .NET-only problem. The flaw lives in the shared Brotli reference implementation. Node.js already shipped fixes on October 21, 2026, and the security press leaned into nicknames like "Node2Shell" and later "HTTP2Shell." Node calls the end state remote code execution.
The Google Brotli advisory points at versions 1.0.3 through 1.2.0 and pins the fixes to 1.0.10, 1.1.1, and 1.2.1. The out-of-bounds write sits in the decoder, where a crafted compressed stream can corrupt adjacent memory.
So which .NET apps are actually in range? It comes down to anything that ingests Brotli data, whether that's ASP.NET Core request decompression, HttpClient automatic response decompression, or the System.IO.Compression APIs.
The nuance, though, is that neither request decompression nor automatic response decompression is on by default, and .NET Framework is untouched. The risk concentrates on modern apps that actively fetch or accept Brotli content from untrusted sources. Not exactly a blast radius, but not nothing either.
If the new flaw is the headline, the re-released fixes are the awkward bit. Microsoft is basically conceding that its October 13, 2026 patch "did not fully address these issues," so it's shipping corrected versions now.
Consider CVE-2026-70197, an out-of-bounds write in System.Net.Sockets.Socket.ReceiveFromAsync. The root cause is genuinely fiddly: reuse a single SocketAsyncEventArgs across IPv4 and IPv6 datagram sockets, and the cached native address buffer can stay too small. Flip from IPv4 to IPv6 and you write past the end of it. Microsoft rates this as an Important RCE at CVSS 8.1.
Then comes CVE-2026-102870, a code-injection hole in the Blazor WebAssembly debugger. That debug proxy generates and compiles C# to evaluate expressions, and certain attacker-controlled values weren't consistently escaped. Get an app being debugged to expose one, plus a developer actually evaluating an expression, and you're running code on their machine. It's CVSS 8.8, and it needs user interaction to pull off. The affected set stretches from Microsoft.AspNetCore.Components.WebAssembly.Server 10.0.0 through 10.0.12 into .NET 11 previews, plus Visual Studio 2022 before 17.14.42 and Visual Studio 2026 before 18.10.4.
A third new fix deserves a mention too. CVE-2026-114148 is about unsafe ownership metadata in .NET tarballs on Linux, which could let a local attacker escalate privileges. For .NET 10 and 11 it's source-build tarballs only. For .NET 8 and 9 it's wider, hitting ASP.NET Core distributions as well, which means folks who don't build from source can be exposed. Worth knowing if you install the runtime out of an extracted tarball.
What to install before the November deadlines
The version matrix is plain enough. .NET 8 moves to 8.0.33, .NET 9 to 9.0.22, .NET 10 to 10.0.14, and .NET 11 gets RC3. Microsoft specifically flags that .NET 11 RC2 users should jump to RC3 to pick these fixes up.
| .NET version | Update to | Download location |
|---|---|---|
| .NET 8 | 8.0.33 | .NET 8 SDK and Runtime |
| .NET 9 | 9.0.22 | .NET 9 SDK and Runtime |
| .NET 10 | 10.0.14 | .NET 10 SDK and Runtime |
| .NET 11 | Release Candidate 3 | .NET 11 SDK and Runtime |
The timing here is more than a calendar quirk. .NET 8 and .NET 9 share that November 10, 2026 end-of-support date because Microsoft extended STS support from 18 to 24 months, which nudged .NET 9's window to line up exactly with .NET 8's LTS. After that date, nothing ships for either.
.NET 10 is the long-term destination, held in support until November 14, 2028. .NET 11 lands GA around November 10 to 13 at .NET Conf 2026, with RC1 in September and RC2 on October 13, both carrying go-live licenses. RC3 is the last candidate before GA.
The practical upshot: if you're running .NET 8 or 9, treat this patch as a bridge to .NET 10 LTS, not a fixed address.
One aside that helps frame all this: the October 13 Patch Tuesday was a monster. Dustin Childs of the Zero Day Initiative counted roughly 1,415 new CVEs, the first four-digit volume he's ever seen and more than any prior calendar year. Microsoft was even experimenting with "risk cohorts" to help customers triage. Only one CVE was under active attack at release, CVE-2026-96951, a Windows Shell "Mark of the Web" bypass. Two were publicly known: CVE-2026-108398, a .NET Framework feature bypass worth CVSS 8.8 that dodges Windows Defender Application Control, and CVE-2026-92707, a MessagePack-CSharp DoS. Childs flagged 59 wormable CVEs that month, several of them .NET-adjacent.
That this OOB release lands two weeks later, on top of all that, just proves Microsoft will still break schedule when a flaw like the cross-runtime Brotli bug demands it.
Microsoft's guidance splits cleanly by deployment model. Framework-dependent apps: install the updated runtime and restart. Self-contained apps: rebuild and republish, since swapping in a newer host runtime doesn't touch what's bundled inside. Containers: rebuild and redeploy from updated .NET container images. Source-build consumers: grab refreshed artifacts and rebuild. ASP.NET Core tarball users on .NET 8 and 9 need the refreshed runtime tarball even if they don't build from source.
To see what's actually on a machine, run dotnet --list-runtimes and confirm the right build shows up. That check applies to framework-dependent deployments only, since self-contained and container builds carry their own runtime. Report any post-update problems in the .NET release feedback issues on GitHub.
On my own read of priorities, internet-facing apps that accept or proxy Brotli content should go first. Custom Accept-Encoding handling, file-upload pipelines, API gateways: those are the highest-risk paths for the CVSS 10 flaw. Then audit Linux tarball installs of .NET 8 and 9. Then take the re-released fixes seriously. If you patched on October 13, this OOB update still counts. Blazor WebAssembly folks should keep the debugger out of production and update their server component.
.NET October 2026 Out-of-Band Security Updates - .NET Blog
Out-of-band security updates for .NET address the Brotli decoder vulnerability and tarball ownership vulnerability.
