.NET Brotli Patch: What to Update, How to Check, Container and Self-Contained App Traps

Microsoft released out-of-band (OOB) security updates for .NET 8, .NET 9 and .NET 10 on 25 October 2026, together with .NET 11 Release Candidate 3, to fix CVE-2026-111497. The bug is an out-of-bounds write in the Brotli decoder that .NET uses. A fix reaches an app only when the app runs the new runtime. That is where updates slip, because self-contained apps, NativeAOT executables and container images do not follow the host.

This page is only the .NET update job. Our HTTP2Shell post compares every stack that carries the decoder, and the Node2Shell post covers Node.js. The flaw itself is on our CVE-2026-111497 page, and the Brotli glossary entry explains the format.

Last updated: 27 October 2026. We update this page if Microsoft revises its advisory.

Which .NET Versions Fix the Brotli Flaw?

Microsoft’s advisory names one fixed runtime for each release and two SDK builds for .NET 8, 9 and 10. On the .NET 11 line the fix is in Release Candidate 3, and the .NET Blog tells RC2 users to move to RC3. Installing an SDK also installs the matching updated runtime.

Microsoft states that .NET Framework is not affected. The installers are on Microsoft’s .NET download page.

Does Your App Decode Brotli, or Just Sit Next to It?

Exposure takes a choice in the app. Microsoft’s advisory names three opt-in paths, and request decompression and automatic response decompression are off by default:

• ASP.NET Core request decompression with Brotli (br) support enabled.
• HttpClient automatic response decompression, where AutomaticDecompression on HttpClientHandler or SocketsHttpHandler includes DecompressionMethods.Brotli or DecompressionMethods.All.
• Direct use of the Brotli APIs in System.IO.Compression, such as BrotliStream or BrotliDecoder.

The advisory says an app is not exposed merely because an affected .NET package is installed. The MSRC entry says the same: Brotli decompression is not enabled by default in an out-of-the-box .NET or ASP.NET Core install. Microsoft still recommends updating affected installations as soon as possible, so use this list to order the work and not to skip it.

In each path the question is the same, and it is our reading of the advisory: can someone else choose the bytes your code decompresses? A public API that accepts br request bodies can be fed by a stranger. So can an HttpClient that calls servers you do not control.

What Is the Right Order for the .NET Brotli Update?

The order follows what each step needs. Shared runtimes come first because one install covers every framework-dependent app on the host. The restart comes next, because a patched host with a service that never restarted is still unpatched. The rebuilds follow, since they need the updated runtime, SDK or base image to build against.

Why Does a Patched Server Still Leave Some Apps Behind?

The check command in Microsoft’s .NET Blog is dotnet --list-runtimes. It lists the runtimes installed on a machine, and for framework-dependent deployments you confirm that the updated runtime is there. Microsoft adds that self-contained applications and container deployments must be checked separately because they carry their own runtime. Three cases need care:

• Self-contained apps. Microsoft’s blog says installing a newer runtime on the host does not update the runtime bundled with your application. Rebuild and republish.
• NativeAOT apps. Updating the machine’s shared runtime alone does not replace a decoder already linked into a NativeAOT executable. The affected packages in the advisory include the NativeAOT runtime packs and the Microsoft.DotNet.ILCompiler compiler package. Patch the SDK and any explicit references before you republish.
• Containers. Microsoft says to rebuild and redeploy using updated .NET container images. Updating the host that runs a container changes nothing inside it.

What Can You Do If You Cannot Update Today?

Microsoft’s advice until the update is deployed is to avoid decompressing attacker-controlled Brotli data. Its examples exist only for apps that already use decompression, and the warning that comes with them matters more than the code.

For ASP.NET Core request decompression, remove the br entry from the existing configuration. The default gzip and deflate providers stay.

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

For HttpClient, change the flags on the existing handler so they leave out DecompressionMethods.Brotli.

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

var httpClient = new HttpClient(handler);

Apps that call the Brotli APIs directly must stop passing untrusted Brotli data to them, and other code must not decompress the same data. Microsoft says these changes can affect normal request and response handling, so test them first. It also says installing the security update remains the recommended fix.

Has Anyone Exploited CVE-2026-111497 in .NET?

Microsoft’s entry in the Security Update Guide lists the flaw as publicly disclosed and not exploited, with the assessment “Exploitation More Likely”. MSRC rates it Critical with impact Elevation of Privilege, base score 8.1 and temporal score 7.1. The .NET advisory calls the same score High and classes the weakness as CWE-787, an out-of-bounds write. Its vector marks exploit code maturity as unproven.

Outside Microsoft, a GitHub search for the CVE id returned 63 repositories on 27 October 2026. Many use the Node2Shell or HTTP2Shell names. The only one whose description names .NET, created on 26 October, calls itself a scanner for .NET apps and Azure deployments.

What Else Did the Same .NET Release Fix?

CVE-2026-114148 is a Linux tarball bug: unsafe ownership metadata in affected .NET tarballs could let a local attacker modify files and gain elevated privileges. For .NET 10 and 11 it touches source-build tarballs only. For .NET 8 and 9 it also reaches ASP.NET Core tarballs, including users who do not build .NET from source.

Microsoft points those .NET 8 and 9 users to the refreshed ASP.NET Core Runtime tarball. The release notes add that downloading an updated archive does not by itself correct ownership in an existing installation.

Two earlier advisories were re-released because the 13 October 2026 update did not fully address them. CVE-2026-70197 (SocketAsyncEventArgs memory corruption) is listed for .NET 8, 9, 10 and 11. CVE-2026-102870 (Blazor WebAssembly debugger) is listed for .NET 10 and 11.

For Blazor on .NET 10, update the Microsoft.AspNetCore.Components.WebAssembly.Server and Microsoft.AspNetCore.Components.WebAssembly.DevServer package references to 10.0.14. Updating the shared runtime alone does not update those packages.

How Do You Show the Update Is Done?

For framework-dependent apps, keep the dotnet --list-runtimes output of each host. For everything else Microsoft gives no check command. Keep a record per app instead: the runtime version it was built with, the date of the rebuild and, for containers, the image it was rebuilt on. An app without that record is the next one to look at.