Microsoft has shipped security updates on an unscheduled basis for .NET 8, .NET 9, .NET 10 and the third release candidate of .NET 11. The driver is CVE-2026-111497, a buffer overflow rooted in how the framework invokes the Brotli decompression algorithm. The company’s advice is to install the patches immediately. Details went up on the .NET team’s official blog on 25 October, and BetaNews reported on the release.
- What an attacker gains: Microsoft states that someone who never authenticates can read a process’s memory or tamper with it. Three harms follow: information disclosure, denial of service, or privilege escalation. Every platform is in scope.
- Which software is actually reachable: Exposure applies to programs handling Brotli-compressed input through three routes — request decompression in ASP.NET Core, automatic decompression of responses in HttpClient, and the Brotli APIs under System.IO.Compression. Microsoft notes that the first two stay inactive unless a developer turns them on, and that .NET Framework is untouched.
- A second flaw, Linux only: The same package repairs CVE-2026-114148, which concerns Linux alone. Some .NET tarballs shipped ownership metadata that was unsafe, opening a path for a local attacker to alter files and climb to higher privileges. On .NET 10 and .NET 11 the problem is confined to source-build tarballs; on .NET 8 and .NET 9 it also catches anyone who installed ASP.NET Core from a tarball, even without ever compiling .NET from source.
- Severity, and a caveat on sourcing: BetaNews labels the flaw critical, while Microsoft’s blog attaches no score at all, and the advisory page at the Microsoft Security Response Center could not be reached. BetaNews also frames the impact in terms that differ somewhat from Microsoft’s, so the official notice remains the safer reference.
Versions to install, and the deployment trap
The builds to move to are 8.0.33 for .NET 8, 9.0.22 for .NET 9, 10.0.14 for .NET 10 and Release Candidate 3 for .NET 11; anyone still sitting on RC2 needs to step up to RC3.
For plenty of teams the difficult part is not the runtime itself but what surrounds it. Patching the server does not always settle matters, because applications published as self-contained carry a runtime of their own inside the build and must therefore be recompiled and shipped out again. Container images have to be rebuilt from updated base images. Only framework-dependent apps are mended simply by installing the runtime and restarting. Microsoft points to the dotnet –list-runtimes command as a way to inventory what each machine holds, though knowing that inventory is not the same as knowing how each app was deployed.
Two October fixes that needed another attempt
Microsoft concedes that a pair of patches issued on 13 October left their defects partly open. It has reissued advisories for CVE-2026-70197, a memory corruption bug in SocketAsyncEventArgs touching .NET 8, 9, 10 and 11, and for CVE-2026-102870, found in the Blazor WebAssembly debugger shipped with .NET 10 and .NET 11. The current updates fold in both repairs.
All of this lands in the same month as October’s Patch Tuesday, which closed more than 1,400 vulnerabilities, and the sheer volume makes triage genuinely hard. My reading is that an emergency release which also has to redo earlier patches is the clearest argument against treating a security bulletin as finished the moment something has been installed. The parallel is a server still running an unpatched PHP build while WordPress itself is current: the layer that actually executes in production is the one that counts. Anyone running .NET services should check today whether Brotli data from external clients reaches any of them; those instances deserve patching first, and self-contained builds and containers are precisely the ones that slip through. The order is plain enough — find the outward-facing Brotli consumers, update the runtime, then revisit every build and image that carries its own copy, and confirm the fix landed rather than assuming it did.