Skip to content

.NET 8, 9 and 10 out-of-band Brotli security update

On 25 October 2026 Microsoft released out-of-band security updates for .NET 8, 9 and 10 (8.0.33, 9.0.22 and 10.0.14) and .NET 11 RC3, fixing the Brotli decompression flaw CVE-2026-111497 and finishing two fixes from the 13 October release. Anyone running .NET apps on servers, in containers or as self-contained builds should update; Microsoft says "We recommend updating as soon as possible."

Runbook card

What changes: new .NET runtimes 8.0.33, 9.0.22 and 10.0.14 fix CVE-2026-111497 (Brotli buffer overflow), CVE-2026-114148 (Linux tarball ownership) and re-release the fixes for CVE-2026-70197 and CVE-2026-102870.
Who: admins and developers running .NET 8, 9 or 10 apps: Windows and Linux servers, line-of-business and RMM tools, containers, self-contained apps. .NET Framework is not affected.
By when: "as soon as possible". Microsoft gives no deadline. Install it even if you applied the 13 October update.
Do this: 1. Install the updated runtime on every host and restart the apps. 2. Rebuild and republish self-contained apps. 3. Rebuild and redeploy container images from updated .NET images. 4. On .NET 8 and 9 Linux tarball installs, take the refreshed ASP.NET Core tarball.
Check: dotnet --list-runtimes shows Microsoft.NETCore.App and Microsoft.AspNetCore.App at 8.0.33, 9.0.22 or 10.0.14 or later.
Source: .NET Blog: .NET October 2026 Out-of-Band Security Updates (25 October 2026).

What Microsoft says

CVE-2026-111497, all platforms: "A buffer overflow vulnerability exists in .NET's use of the Brotli decompression algorithm. This vulnerability may allow an unauthenticated attacker to read or corrupt process memory. This could lead to information disclosure, denial of service, or elevation of privilege."

Apps are exposed if they handle Brotli-compressed data through ASP.NET Core request decompression, HttpClient automatic response decompression or the System.IO.Compression Brotli APIs. Microsoft: "Request decompression and automatic response decompression are not enabled by default. .NET Framework is not affected."

CVE-2026-114148, Linux only: "Unsafe ownership metadata in affected .NET tarballs could allow a local attacker to modify files and gain elevated privileges." On .NET 10 and 11 this affects source-build tarballs only. On .NET 8 and 9 it also affects ASP.NET Core tarballs, "including users who do not build .NET from source".

Microsoft is also re-releasing the advisories for CVE-2026-70197 (SocketAsyncEventArgs memory corruption) and CVE-2026-102870 (Blazor WebAssembly debugger) "because the October 13, 2026 release did not fully address these issues". If you patched on 13 October, you still need this update.

.NET version Fixed version
.NET 8 8.0.33
.NET 9 9.0.22
.NET 10 10.0.14
.NET 11 Release Candidate 3 (RC2 users should update)

What is not known: Microsoft's blog post gives no CVSS score or severity rating and says nothing about exploitation. We do not call it exploited.

The part that gets missed

Installing the new runtime on a host only fixes framework-dependent apps. Microsoft: "Installing a newer runtime on the host does not update the runtime bundled with your application." Self-contained apps and container images carry their own copy, so each one needs a rebuild and redeploy.

Azure App Service for Windows has finished rolling out the updated built-in runtimes (update of 27 October 2026), but the App Service team says the platform update "does not replace a .NET runtime bundled with your application or inside your custom image".

How to check (read-only)

On each Windows or Linux host:

dotnet --list-runtimes

Look for Microsoft.NETCore.App and Microsoft.AspNetCore.App at 8.0.33, 9.0.22 or 10.0.14 or later for each line you run. Note that dotnet --version shows the SDK version, not the runtime your app uses.

On Windows, a quick inventory across the folders the shared runtime uses:

Get-ChildItem "$env:ProgramFiles\dotnet\shared\Microsoft.NETCore.App", "$env:ProgramFiles\dotnet\shared\Microsoft.AspNetCore.App" -Directory -ErrorAction SilentlyContinue |
  Select-Object @{n='Runtime';e={$_.Parent.Name}}, Name

For self-contained apps and containers, check the runtime the running process reports, for example by logging System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription at start-up, as the App Service team suggests.

How to verify

After updating, dotnet --list-runtimes lists the fixed version, restarted apps report it at start-up, and rebuilt container images are built from the updated .NET base images. Keep older runtimes only where an app still targets them, and plan to move those apps.

Impact and rollback

This is a servicing update within each release line, so framework-dependent apps roll forward to it after a restart. Test business-critical apps first where you can. If something breaks, Microsoft asks you to report it in the .NET release feedback issues rather than staying on a runtime with known flaws.

Related: the other October 2026 Windows out-of-band update in our eMudhra CA keys brief, the Exchange OWA and mail flow known issue from the October Windows Server updates, this week's CISA KEV additions, all dated actions on Microsoft 365 security deadlines, and more Threats & vulnerabilities news.

Sources

Last reviewed: 31 October 2026. Runbook Lab is not affiliated with Microsoft.