Microsoft .NET 8, 9 and 10 Out-of-Band Security Update Fixes Brotli Overflow and Linux Tarball Flaw

There are four CVEs in total. Two are new:

• CVE-2026-111497: a Brotli decoder buffer overflow on every platform.
• CVE-2026-114148: a Linux-only file-ownership problem in some tarball distributions.

Two are corrections to fixes from Patch Tuesday:

• CVE-2026-70197
• CVE-2026-102870

The versions you want​

Microsoft's release announcement lists these patched builds:

• Why two SDK numbers: they belong to different SDK feature bands. Pick the one that matches the band you already use.
• .NET 11: this is still a release candidate, not the final .NET 11 release.
• Where the builds are: Microsoft's status table shows installers and binaries, Linux and Windows container images, and Microsoft's Linux packages for Debian 12, openSUSE 15, Rocky 9 and Ubuntu 20.04/22.04 all published. When the table was captured, the Winget row had not yet been marked as verified.
• .NET Framework: not affected by the Brotli bug, so the classic Framework stack built into Windows can sit this one out.

Summary: if a .NET 8, 9 or 10 runtime is below 8.0.33, 9.0.22 or 10.0.14, it's out of date.

CVE-2026-111497: a known upstream Brotli bug reaches .NET​

Microsoft describes the flaw as a buffer overflow in the Brotli decompression library that .NET uses. It may allow an unauthenticated attacker to read or corrupt process memory. This could lead to information disclosure, denial of service, or elevation of privilege. Microsoft scores it High, 8.1, CWE-787 (Out-of-bounds Write). The vector is network-based with high attack complexity, and it needs no privileges or user interaction.

This is not a .NET-only bug. The flaw is in Google's reference Brotli C decoder, and other projects have been dealing with it for days:

• Where it started: Cybersecurity News reports it was first disclosed in Node.js security updates on October 21, and the bug is in the decoder, not in HTTP.
• Names and affected versions: security firm Phoenix Security tracks it under the names "HTTP2Shell" and "Node2Shell." It reports that Brotli 1.0.3 through 1.2.0 is affected.
• What .NET bundles: Phoenix says BrotliDecoder, BrotliStream, HttpClient automatic decompression and ASP.NET Core request decompression all run bundled Brotli 1.1.0.
• Why OS updates won't help: because .NET ships its own copy of the decoder, patching your Linux distribution's libbrotli does not fix .NET. You have to update .NET itself.

Why the severity labels don't match​

Reported severity varies a lot:

• Microsoft: CVSS 3.1, 8.1, High.
• Phoenix Security: cites a CVSS 4.0 9.2 Critical from the CNA, meaning the upstream CVE record.
• Warp2Search: claims the flaw is rated CVSS 10. Neither Microsoft's advisory nor the upstream rating supports that figure.
• Exploitation status: SecurityOnline's summary table marks the Brotli CVE as "Exploited." Microsoft's own CVSS vector uses an "unproven" exploit-maturity value. I couldn't confirm active exploitation of .NET applications specifically, so treat that label as unverified.

The practical reading: different scoring systems and different products produce different numbers. Whichever number you use, an out-of-bounds write that an unauthenticated network attacker can reach deserves fast action.

Are you actually exposed?​

Having an affected runtime installed doesn't automatically mean your application is vulnerable. Microsoft notes that ASP.NET Core and HttpClient do not automatically decompress Brotli data in their default configurations. Applications are exposed when they enable Brotli decompression or explicitly use Brotli decompression APIs to process attacker-controlled data.

There are three ways in:

1. ASP.NET Core request decompression with the Brotli (br) provider turned on.
2. HttpClient automatic response decompression, when HttpClientHandler.AutomaticDecompression or SocketsHttpHandler.AutomaticDecompression includes DecompressionMethods.Brotli or DecompressionMethods.All.
3. Direct use of the Brotli APIs in System.IO.Compression, such as BrotliStream or BrotliDecoder.

The DecompressionMethods.All case is the one most likely to catch people out. A developer who wrote "just decompress everything" two years ago probably doesn't remember it. Search your codebase for these settings before assuming you're safe.

The client side matters too. An internal service that calls a third-party API with automatic decompression turned on is exposed to whatever that API, or anyone who can tamper with its responses, sends back.

Temporary mitigations (only if you're already using Brotli)​

Microsoft's advice until you can patch is to stop decompressing attacker-controlled Brotli data. The advisory includes a strong warning: only change decompression settings you already have. Don't add AddRequestDecompression or an AutomaticDecompression assignment that wasn't there before. Turning on automatic decompression can create its own denial-of-service risk, even without Brotli.

ASP.NET Core: if you already use request decompression, remove the br provider. The default gzip and deflate providers stay in place:

builder.Services.AddRequestDecompression(options =>
{
    options.DecompressionProviders.Remove("br");
});

HttpClient: if you already use automatic decompression, limit the flags to gzip and deflate:

var handler = new HttpClientHandler
{
    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
};

Direct API callers: Microsoft says applications must stop passing untrusted Brotli data to those APIs until updated. Ensure that other application code does not continue to decompress the same untrusted Brotli data.

Test these changes before you roll them out, because they change how requests and responses are handled. Installing the update is still the real fix.

Summary: the bug is serious, but whether you're exposed depends on your configuration. Find out which of your apps decompress Brotli, patch those first, and use the workarounds only to cover the gap.

CVE-2026-114148: the Linux tarball ownership problem​

The second new CVE is not another buffer overflow, despite some headlines suggesting otherwise.

What's wrong: some .NET Linux tarballs contain incorrect ownership metadata. If extraction keeps that ownership, a local account may end up controlling runtime files that a more privileged application later loads. Microsoft rates it High, CVSS 7.8, under CWE-276 (Incorrect Default Permissions). It covers ARM, ARM64 and x64 Linux.

Microsoft-published archives that are affected (.NET 8 and 9 only):

• File names: aspnetcore-runtime-{version}-{rid}.tar.gz, aspnetcore-runtime-composite-{version}-{rid}.tar.gz and aspnetcore-targeting-pack-{version}-{rid}.tar.gz.
• Not affected: Microsoft's other .NET 8 and 9 runtime and SDK tarballs.

Source-built .NET Linux distributions (every tarball type source-build produces):

How to tell if you're affected: Microsoft says a version number alone can't tell you. You need to know:

• which archive an installation came from
• whether extraction kept the archive's numeric ownership, for example a privileged tar extraction or an ownership-preserving container import
• what ownership the resulting files actually have

Restoring the ASP.NET Core NuGet packages does not introduce the defect by itself.

How to fix an affected installation​

Microsoft is clear on one point: downloading a new archive or extracting it over the old directory does not fix an existing installation. The steps are:

1. Inventory: find the affected directories and every app, service, scheduled job and container image that uses them. Stop those workloads.
2. Download and verify: get the patched archive and check its checksum against the publisher's release information.
3. Install into a new, empty directory: don't reuse the old tree or copy files from it. For shared installs, use a trusted administrator account and a directory whose parent folders untrusted users can't change.
4. Extract without restoring ownership: Microsoft's GNU tar example runs under umask 022 with --no-same-owner --no-same-permissions.
5. Repoint and verify: update app and service configuration, restart, and check which runtime each app actually loads, not just whichever dotnet comes first on PATH.
6. Retire the old tree: if you suspect compromise, preserve evidence first.
7. Rebuild custom container images from trusted inputs. Patching a running container doesn't fix the image that new containers start from.

Source-build workflows: move to the fixed source-build release, recreate extracted workspaces from scratch, and rebuild any downstream packages or images that may have inherited bad ownership.

Summary: this is a Linux-only, local privilege-escalation problem. If you extracted ASP.NET Core tarballs as root on .NET 8 or 9, assume you need to do a clean reinstall.

Two October 13 fixes needed another pass​

Microsoft is also re-releasing advisories for CVE-2026-70197 and CVE-2026-102870, because the October 13 Patch Tuesday release did not fully fix them.

CVE-2026-70197 (.NET 8, 9, 10 and 11): a memory-corruption flaw in System.Net.Sockets on Windows.

• Reusing one SocketAsyncEventArgs object across IPv4 and IPv6 datagram sockets can leave a cached native address buffer too small.
• That can lead to an out-of-bounds write during ReceiveFromAsync.
• The complete fix is in the October 25 builds.

CVE-2026-102870 (.NET 10 and 11): a Blazor WebAssembly debugger flaw.

• Fixed package versions are 10.0.14 and 11.0.0-rc.3.26522.148 of Microsoft.AspNetCore.Components.WebAssembly.Server and Microsoft.AspNetCore.Components.WebAssembly.DevServer.
• These are package references, so updating the shared runtime won't fix them. Bump the packages, then restart your debugger and development environment.

If you patched on October 13 and moved on, you need to patch again.

Deployment checklist​

How you update depends on how the app was built and deployed:

Self-contained and NativeAOT apps are the ones most likely to be missed. Updating every server leaves them untouched, because each one carries its own copy of the vulnerable code. An executable built in March stays vulnerable until you rebuild it.

To see what's installed, run:

dotnet --list-runtimes

That shows the shared runtimes on the machine. It doesn't show what a self-contained app bundles, or which runtime a given service actually loads. For a full picture, combine it with your build pipeline records and image scans.

One note from release day: developers on Microsoft's release thread reported that some aka.ms download links briefly redirected to storage that returned HTTP 409 errors. This broke channel-based dotnet-install scripts and CI setup. A Microsoft contributor later said the problem was fixed and suggested retrying. If your pipeline failed on October 25, rerun it before you start debugging.

The bigger picture​

These fixes arrived twelve days after Patch Tuesday, and two of the four CVEs are corrections of earlier patches. That's not a great look for a servicing process that is supposed to be predictable.

To be fair, Microsoft didn't create the main bug. It inherited a flaw in a widely shared C library, and it shipped fixes for four release lines, plus containers and Linux packages, within days of the Node.js disclosure. The advisories are also unusually detailed about real exposure: they spell out exactly when an app is reachable instead of telling everyone to panic.

The broader lesson is about bundled dependencies. A .NET runtime carries its own Brotli, and so does a self-contained app. Unless you rebuild and redeploy those copies, they keep running whatever version was compiled in. Patch the runtimes, rebuild the self-contained and NativeAOT apps, clean up any .NET 8 or 9 ASP.NET Core tarball installs on Linux, and check which apps have Brotli decompression turned on.