.NET October 2026 Out‑of‑Band Updates: Brotli and Tarball Fixes

Brotli buffer overflow exposure in ASP.NET Core, HttpClient and System.IO.Compression #

CVE-2026-111497 applies to all platforms. Applications are exposed when they process Brotli-compressed data through ASP.NET Core request decompression, HttpClient automatic response decompression, or the System.IO.Compression Brotli APIs. The post states that request decompression and automatic response decompression are not enabled by default, so the first check is whether your code or configuration enables them or calls the Brotli APIs directly.

"This vulnerability may allow an unauthenticated attacker to read or corrupt process memory."

.NET October 2026 out-of-band security updates

The post states that .NET Framework is not affected. Because the attacker is described as unauthenticated, the exposure concerns any input that reaches the decompression path, not only logged-in users. The sources list possible outcomes of information disclosure, denial of service or elevation of privilege, but do not say which outcome applies to a given application.

Linux tarball ownership flaw in .NET 8 and .NET 9 ASP.NET Core tarballs #

CVE-2026-114148 is described as unsafe ownership metadata in affected .NET tarballs, which could allow a local attacker to modify files and gain elevated privileges. The post lists Linux as the affected platform. Scope depends on the version: for .NET 10 and .NET 11 it affects source-build tarballs only, while for .NET 8 and .NET 9 it also affects ASP.NET Core tarball distributions, including users who do not build .NET from source.

A team that installs ASP.NET Core from a tarball on .NET 8 or .NET 9 must update that installation even when it compiles no .NET code itself. A team that builds .NET 10 or .NET 11 from source needs the updated source-build artifacts and must rebuild its packages to incorporate the ownership fix.

Re-released SocketAsyncEventArgs and Blazor WebAssembly debugger advisories #

The update also re-releases the advisory for CVE-2026-70197, a SocketAsyncEventArgs memory corruption issue, for .NET 8, 9, 10 and 11, and the advisory for CVE-2026-102870, a Blazor WebAssembly debugger issue, for .NET 10 and 11. The post states that the October 13, 2026 release did not fully address these issues, and that today's updates provide those fixes. Teams that deployed the October 13 builds should treat these two advisories as still needing action.

The provided sources do not describe the technical details or severity of these two CVEs, so the linked security advisories are the place to confirm their scope.

Brotli 1.0.10 and 1.1.1 changes in the v8.0.33 and v9.0.22 releases #

The v8.0.33 release updates the bundled Brotli native dependency from 1.0.9 to 1.0.10. Its description says the change primarily fixes decoder error handling for block switch operations, and adds an error code named BLOCK_SWITCH (-17). The release page does not name a CVE, so its link to CVE-2026-111497 is an inference from the update post, not a statement in the release notes.

The v9.0.22 release updates Brotli from 1.1.0 to 1.1.1. Its auto-generated PR description classifies the change as a security fix for CVE-2026-111497 and calls it an out-of-bounds write that could permit remote code execution. That description is generated text and does not match the post's wording of buffer overflow, so the post is the authoritative source. The same description adds the error code BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH, while the v8.0.33 notes use the name BLOCK_SWITCH. This suggests that code matching on Brotli error values should be checked against the exact version it runs on.

Fixed versions of .NET 8, 9, 10 and 11 #

The post names the release lines that the advisories cover but does not list vulnerable build numbers, so the table shows only fixed versions.

Protection steps for framework-dependent apps, self-contained apps, containers and source builds #

1. Install the updated runtime for the .NET version your framework-dependent application targets, then restart the application.
2. Rebuild and republish self-contained applications with the updated runtime, because installing a newer runtime on the host does not update the runtime bundled with them.
3. Rebuild and redeploy containers using updated .NET container images.
4. If you consume source builds, obtain the updated source-build artifacts for your .NET version and rebuild your packages to incorporate the tarball ownership fix.
5. On .NET 8 and .NET 9, update ASP.NET Core tarball installations using the refreshed ASP.NET Core Runtime tarball, even if you do not build .NET from source.
6. If you run .NET 11 RC2, update to RC3 to receive these fixes.

How to check installed .NET runtimes on framework-dependent hosts #

Run the command below on each host that runs framework-dependent deployments, then confirm that the updated runtime for the version your application targets is listed.

dotnet --list-runtimes

The post notes that self-contained applications and container deployments carry their own runtime, so this command does not verify them. Check their build and image versions separately, and check any ASP.NET Core tarball installation as the update post describes.