.NET 10.0.14 Ships Out-of-Band: Brotli Decompression Overflow and Two Re-Released October CVEs

Twelve days after October Patch Tuesday, Microsoft shipped an out-of-band security release for .NET: .NET 8.0.33, 9.0.22, 10.0.14, and .NET 11 RC3. Microsoft says to update “as soon as possible”, and two of the four CVEs in it are re-releases. If you rolled out 10.0.13, 9.0.21, or 8.0.32 on October 13 and called it done, you are not done.

CVE-2026-111497: a buffer overflow in Brotli decompression

CVE-2026-111497 is a buffer overflow in how .NET decompresses Brotli data. An unauthenticated attacker who can get crafted Brotli bytes into your process may be able to read or corrupt memory, which can mean information disclosure, denial of service, or elevation of privilege. It affects every platform. .NET Framework is not affected.

There are three ways in:

• ASP.NET Core request decompression, which inflates Content-Encoding: br request bodies from clients.
• HttpClient automatic decompression, which inflates br responses from servers you call.
• Direct use of the System.IO.Compression Brotli APIs.

The first two are off by default, so “do we use this?” is a grep away. These are the patterns to look for:

// 1. Server side: clients can send you Brotli bodies
builder.Services.AddRequestDecompression();
app.UseRequestDecompression();

// 2. Client side: servers can send you Brotli responses
var handler = new SocketsHttpHandler
{
    AutomaticDecompression = DecompressionMethods.All // includes Brotli
};

// 3. Direct API use on untrusted input
using var input = File.OpenRead(uploadPath);
using var brotli = new BrotliStream(input, CompressionMode.Decompress);
await brotli.CopyToAsync(output);

// Same code path through the span API
BrotliDecoder.TryDecompress(source, destination, out int written);

Request decompression is the worrying case. It takes attacker-controlled bytes from any client before your code sees them. If you enabled it on a public endpoint, patch first and audit later.

CVE-2026-114148: Linux tarball ownership

CVE-2026-114148 concerns unsafe ownership metadata in Linux tarballs, which a local attacker could use to modify files and escalate privileges. On .NET 10 and 11 it only affects source-build tarballs. On .NET 8 and 9 it also covers the ASP.NET Core runtime tarballs, so if your provisioning scripts tar -xzf the ASP.NET Core runtime, fetch the refreshed tarball even if you never build .NET from source.

The October 13 fixes were incomplete

According to the post, the Patch Tuesday release did not fully fix two advisories, so this release re-issues them:

• CVE-2026-70197, memory corruption in SocketAsyncEventArgs, on .NET 8, 9, 10, and 11.
• CVE-2026-102870, in the Blazor WebAssembly debugger, on .NET 10 and 11.

SocketAsyncEventArgs sits under Socket, Kestrel, and SocketsHttpHandler, so almost every networked .NET app runs that code.

Rolling it out

The fix depends on how the app is deployed:

# Framework-dependent: update the host runtime, then restart the process
dotnet --list-runtimes
# expect Microsoft.NETCore.App 10.0.14 / 9.0.22 / 8.0.33

# Self-contained or Native AOT: the runtime is inside your output, so republish
dotnet publish -c Release -r linux-x64 --self-contained

# Containers: pull fresh base images and rebuild, do not reuse cached layers
docker build --pull -t myapp:patched .

A host-level runtime update does nothing for self-contained apps or container images, because they carry their own runtime. .NET 11 RC2 users need to move to RC3, which also matters if you took the RC2 go-live license into production ahead of the November GA.

Back in April, .NET 10.0.7 also shipped out-of-band to fix CVE-2026-40372 in Data Protection. As then, the fix is to update and redeploy, and problems after updating go to dotnet/core issues.