.NET out-of-band update: a Brotli flaw reads your app memory
On Oct 25 Microsoft shipped out-of-band security updates for .NET 8, 9 and 10: a Brotli buffer overflow lets an unauthenticated attacker read or corrupt process memory. Update the runtime and republish your app.
If you run .NET applications, Oct 25, 2026 brought an update that was not on the schedule. Microsoft shipped out-of-band security updates for .NET 8, 9, and 10, plus .NET 11 Release Candidate 3, and recommends updating as soon as possible. The reason: a Brotli decompression flaw lets an unauthenticated attacker read or corrupt process memory, plus a second fix for Linux tarball ownership, and re-releases of two fixes that the Oct 13 release did not complete.
What shipped on Oct 25?
The official post on the .NET blog, dated Oct 25, 2026 at 18:45 UTC (21:45 at +03), announces out-of-band updates: .NET 8.0.33, .NET 9.0.22, and .NET 10.0.14, plus .NET 11 RC3. Out of band means the update did not wait for the monthly patch day, which alone tells you the team sees the risk as urgent.
The update fixes two new flaws and re-releases two older ones. The new ones: CVE-2026-111497 in Brotli, and CVE-2026-114148 in Linux tarball ownership. The re-released ones: CVE-2026-70197, a SocketAsyncEventArgs memory corruption flaw, and CVE-2026-102870, a Blazor WebAssembly debugger flaw, because the Oct 13 release did not fully address them.
How does the Brotli flaw affect your app?
CVE-2026-111497 is a buffer overflow in .NET's use of the Brotli decompression algorithm. An unauthenticated attacker can read or corrupt process memory, and the result can be information disclosure, denial of service, or elevation of privilege. The flaw affects all platforms, but with one condition: your app must actually process Brotli data.
The three paths the post names: ASP.NET Core request decompression, HttpClient automatic response decompression, and the System.IO.Compression Brotli APIs. The important point is that request decompression and automatic response decompression are not enabled by default, so many apps are not exposed through those two paths. But if your code uses the compression APIs directly, or if you enabled decompression yourself, you are inside the risk zone.
There is a lesson here from other runtime updates in the same month: the Node.js October 2026 security releases also closed flaws in the runtime itself, not in your code. A runtime flaw means every app using it inherits it, even if your code is clean.
What about the Linux tarball ownership flaw?
CVE-2026-114148 is narrower, but worse for anyone who builds from source. Unsafe ownership metadata in .NET tarballs lets a local attacker modify files and gain elevated privileges.
On .NET 10 and 11, the flaw affects source-build tarballs only. On .NET 8 and 9, it also affects ASP.NET Core distributions obtained through ASP.NET Core tarballs, even if you do not build .NET from source.
So if you install .NET from your system package manager, this flaw probably does not concern you. But if you distribute or build from tarballs, you need the updated artifacts and a rebuild.
Why are there re-released fixes from Oct 13?
Because the first fix was not complete. Microsoft says plainly that the Oct 13, 2026 release did not fully address the SocketAsyncEventArgs memory corruption flaw and the Blazor WebAssembly debugger flaw, so today's update re-releases them with the complete fix. The first covers all four versions, the second covers .NET 10 and 11 only.
That detail matters in practice: if you updated on Oct 13 and relaxed, you are still not protected from these two flaws. The new update is not a repeat, it is the completion. It is the same pattern seen with the PHP flaws: the first emergency fix does not mean the story is over.
What to do now?
The right step depends on how you publish your app, and installing alone is not enough in every case.
If your app is framework-dependent, install the updated runtime for your .NET version, then restart the application.
If your app is self-contained, rebuild and republish with the updated runtime. Installing a new runtime on the host does not update an app that carries its runtime inside it.
If your app runs in a container, rebuild and redeploy using the updated .NET container images.
If you build from source, obtain the updated source-build artifacts and rebuild your packages.
If you are on .NET 8 or 9 and use ASP.NET Core tarballs, update using the refreshed ASP.NET Core runtime tarball.
Check with
dotnet --list-runtimesthat the updated version is installed, and check self-contained apps and containers separately because they carry their own runtime.
When did you last update the runtime?
An out-of-band update late in the month, after a monthly release that was incomplete, is a reminder that the runtime is not a layer you forget after installing it.
If you have .NET apps in production, update today and redeploy according to your app type, then ask yourself: which other runtime do you have, from Node.js to PHP, waiting for its next release?
If you want someone to check these settings before anyone else finds them, Muhassan audits your platform and hands you a clear fix plan.
FAQ
Is my app affected if I never enabled decompression?
Your app is affected if it processes Brotli data through one of three paths: ASP.NET Core request decompression, HttpClient automatic response decompression, or the System.IO.Compression Brotli APIs. Request and automatic response decompression are not enabled by default, but direct use of the compression APIs is still affected.
Is .NET Framework affected?
No. The official post says plainly that .NET Framework is not affected. The update covers .NET 8, 9, 10 and .NET 11 RC3 only.
I run .NET 11 RC2, what should I do?
Update to .NET 11 RC3. The post says RC2 users should update to RC3 to receive these fixes.
My app is self-contained, is installing a new runtime enough?
No. A self-contained app carries its runtime inside it, so installing a new runtime on the host does not update it. You must rebuild and republish with the updated runtime, and the same goes for containers: rebuild and redeploy.
