Microsoft .NET out-of-band release reported November 2, 2026; re-issued fixes for October 13, 2026 advisories
Microsoft Ships Out-of-Band .NET Fixes: A Brotli Buffer Overflow on Every Platform and a Linux Tarball Privilege Flaw
Microsoft has released out-of-band security updates for .NET 8, .NET 9 and .NET 10, alongside .NET 11 Release Candidate 3, fixing two serious flaws and re-issuing two earlier fixes that did not fully work. The headline flaw is CVE-2026-111497, a buffer overflow in .NET's use of the Brotli decompression algorithm that affects all platforms: an unauthenticated attacker who gets a vulnerable application to process crafted Brotli data could read or corrupt process memory, leading to information disclosure, denial of service or elevation of privilege. Applications are exposed where they decompress through ASP.NET Core request decompression, HttpClient automatic response decompression, or the System.IO.Compression Brotli APIs. The second flaw, CVE-2026-114148, is unsafe ownership metadata in .NET tarballs that could let a local attacker modify files and gain elevated privileges; it affects Linux only, covering source-build tarballs for .NET 10 and 11 and, for .NET 8 and 9, ASP.NET Core distributions obtained through tarballs as well, including users who never build .NET from source. The release also re-issues fixes for CVE-2026-70197, a SocketAsyncEventArgs memory corruption flaw, and CVE-2026-102870, a Blazor WebAssembly debugger flaw, because the October 13 updates did not fully address them. The remediation path depends on how each application ships: framework-dependent applications need the updated runtime and a restart, self-contained applications must be rebuilt and republished because updating the host runtime does not touch the bundled one, and containers must be rebuilt and redeployed from updated images.
Executives
Out-of-band means the vendor judged these too urgent for the monthly cycle, and one of them sits in decompression code that web applications use constantly. The board-level detail is the self-contained application trap: servers can be fully patched at the operating system level while individual applications still carry the vulnerable runtime bundled inside them. Ask for closure evidence by application, not by server, and note that two of the four fixes in this release are repairs of October fixes that did not fully work, which is a reason to verify rather than assume.
CIO / CISO
Sequence by exposure: internet-facing ASP.NET Core services and anything that decompresses untrusted input first, then HttpClient consumers, then the Linux tarball population, which is easy to miss because it includes .NET 8 and 9 users who installed from ASP.NET Core tarballs without building from source. Track the re-issued pair in the same ticket: estates that closed CVE-2026-70197 and CVE-2026-102870 in October need the new builds before those closures count. Closure evidence is the running runtime version per application, which the dotnet --list-runtimes command reports on each host.
Engineers
Rebuild and republish self-contained applications; installing the new runtime on the host does nothing for them. Rebuild container images from updated .NET bases and redeploy, and for source-build consumers, fetch the refreshed tarballs and rebuild packages so the ownership fix is actually incorporated. After deployment, verify with dotnet --list-runtimes and by checking the application process, not the installer log.
Everyone (non-IT)
There is nothing to install by hand for most people in this story; it concerns the software framework many websites and business applications are built on. If a service you use schedules a short maintenance window this week, this out-of-band fix is a plausible reason, and it is the kind of interruption that prevents a worse one.