.NET October 2026 Out-of-Band Security Update Explained: Brotli Patch, Linux Tarball Fix and the 10 November Deadline (World Tech)
Image: Microsoft .NET logo (Wikimedia Commons). .NET is a framework, not a device, so there is no product photograph — the logo identifies the platform this update is about.
📌 KEY HIGHLIGHTS
- The release: Microsoft's .NET Blog published the out-of-band (OOB) updates on 25 October 2026, with the advice to update "as soon as possible".
- The fixed versions: .NET 8.0.33, .NET 9.0.22, .NET 10.0.14 and .NET 11 Release Candidate 3. .NET 11 RC2 users must move to RC3 to get the fixes.
- The headline flaw: CVE-2026-111497, a buffer overflow in .NET's use of the Brotli decompression algorithm, affecting all platforms — but only apps that actually process Brotli-compressed data through the affected APIs.
- The second flaw: CVE-2026-114148, unsafe ownership metadata in Linux .NET tarballs, letting a local attacker modify files and gain elevated privileges (Linux only).
- The catch: two advisories from 13 October are re-released because that patch did not fully fix them — if you patched on Patch Tuesday and stopped, you are not fully patched.
- The deadline behind it: .NET 8 and .NET 9 reach end of support on 10 November 2026, so this is among the last patches those versions will ever receive.
What happened?
On 25 October 2026, Microsoft's .NET team published an out-of-band security release — a patch that could not wait for the next scheduled servicing day. Out-of-band releases are rare by design: they mean the team judged the flaws serious enough, and the exposure wide enough, to break the normal calendar. The announcement, by Senior Program Manager Rahul Bhandari, covers .NET 8, .NET 9 and .NET 10, along with .NET 11 Release Candidate 3.
The context matters. This is the same Brotli decoder flaw — CVE-2026-111497 — that has been rolling through the software ecosystem all month: Node.js patched it on 21 October, Python and Bun followed, and TechByCountry covered that ecosystem-wide spread in the HTTP2Shell post. Microsoft's .NET patch is the .NET chapter of that same story, plus a second, .NET-specific flaw and two unfinished fixes from earlier in the month. It is a new vendor event with its own versions and its own deployment traps, not a repeat of the earlier coverage.
dotnet october 2026 out-of-band security update explained: the fixes
Four items ship in this release. Here is each one, who it hits, and what it does — in plain language first, with the technical detail after:
| Fix | Who it hits | What it does |
|---|---|---|
| CVE-2026-111497 — Brotli buffer overflow | All platforms; apps processing Brotli-compressed data via ASP.NET Core request decompression, HttpClient automatic response decompression, or System.IO.Compression Brotli APIs | An unauthenticated attacker may read or corrupt process memory, leading to information disclosure, denial of service, or elevation of privilege |
| CVE-2026-114148 — Linux tarball ownership | Linux only; .NET 10/11 source-build tarballs, .NET 8/9 also ASP.NET Core tarballs | Unsafe ownership metadata could let a local attacker modify files and gain elevated privileges |
| CVE-2026-70197 — SocketAsyncEventArgs memory corruption (re-released) | .NET 8, 9, 10, 11 | Memory corruption flaw whose 13 October fix was incomplete; this release completes it |
| CVE-2026-102870 — Blazor WebAssembly debugger (re-released) | .NET 10, 11 | Debugger flaw whose 13 October fix was incomplete; this release completes it |
1. The Brotli flaw — the one to understand. Brotli is a compression algorithm: data is squeezed smaller for transfer, then expanded back on arrival. The flaw sits in the decoder — the expanding side. A crafted compressed stream can make the decoder write past the end of an internal buffer, corrupting adjacent memory. Microsoft's post is precise about exposure: your app is at risk only if it processes Brotli-compressed data through ASP.NET Core request decompression, HttpClient automatic response decompression, or the System.IO.Compression Brotli APIs. Two important qualifiers: request decompression and automatic response decompression are not enabled by default, and .NET Framework — the older Windows-only framework — is not affected at all.

Illustrative image: a data-centre server room — the kind of infrastructure .NET applications run on. Image: Wikimedia Commons / BalticServers.com. This is NOT a Microsoft facility and does NOT show the .NET update.
2. The Linux tarball flaw — the quiet one. Some .NET distributions ship as tarballs — compressed archives you extract yourself. Microsoft found that certain Linux tarballs carried unsafe ownership metadata: extracted with numeric ownership preserved, a local account could end up controlling runtime files, and then modify files used by a more privileged application. For .NET 10 and 11 this affects source-build tarballs only; for .NET 8 and 9 it also affects ASP.NET Core distributions obtained through ASP.NET Core tarballs — including users who never build .NET from source. If you install .NET from a package manager or installer rather than a tarball, this one does not touch you, but check anyway: the tarball path is common on CI servers and minimal containers.
3. The re-released fixes — the real reason to act twice. The October 13 servicing release did not fully address CVE-2026-70197 (SocketAsyncEventArgs memory corruption) or CVE-2026-102870 (the Blazor WebAssembly debugger). Microsoft is unusually frank about this: the advisories are re-released because the earlier fixes were incomplete. The practical consequence is sharp — a team that patched on Patch Tuesday, verified the version number, and moved on is still exposed to those two flaws until it takes this out-of-band release. "Patched" is only true against the latest patch, not the last patch you remember.
Why it matters for World Tech readers
India has one of the world's largest .NET developer communities — enterprise software, banking systems and government portals across the country run on .NET, and Indian IT services firms maintain .NET codebases for clients worldwide. For those teams, this release is a two-front job: patch the runtime, and then check the deployment types that a runtime install does not cover.
That second front is where teams usually get this wrong, and Microsoft's own update guide spells it out. Framework-dependent apps are the easy case: install the updated runtime and restart. Self-contained apps bundle their own runtime, so installing a newer runtime on the host changes nothing — you must rebuild and republish. Containers are the same trap in a different shape: rebuild and redeploy on the updated .NET container images, because an image built before the patch keeps the old runtime until it is rebuilt. Source-build consumers need updated artifacts and a rebuild, and ASP.NET Core tarball users on .NET 8 and 9 need the refreshed tarball even if they never build from source. The check command for the easy case is dotnet --list-runtimes — but it only verifies framework-dependent hosts, not the self-contained and container deployments that carry their own runtime.
Then there is the calendar. .NET 8 and .NET 9 reach end of support on 10 November 2026 — fifteen days after this patch — and .NET 11 reaches general availability at .NET Conf on 10–12 November. This out-of-band release is therefore among the last patches .NET 8 and 9 will ever receive, and the last safe moment to patch before the migration question becomes urgent: move to .NET 10 (supported until November 2028) or .NET 11 at general availability, because after 10 November there will be no more fixes for the old lines at all.
Should you care?
✅ Verdict: Patch now if you ship .NET code — and then verify the deployment types a runtime install cannot reach: rebuild self-contained apps and containers, refresh tarballs, and re-check the two re-released flaws even if you patched on 13 October. ⏳ Wait on nothing else: there is no workaround and no reason to delay an out-of-band security release. 🔍 Honest caveat: Microsoft's post does not claim in-the-wild exploitation of the .NET flaw, and the severity scores for the tarball and re-released flaws come from secondary coverage, not Microsoft's announcement — the urgency here is the flaw's reach plus the 10 November end-of-support cliff, not a reported attack.
How to update to the fixed .NET versions
First, find what you run: dotnet --list-runtimes on every host, and check container base images and self-contained build outputs separately — they carry their own runtime and will not show up in that list. Then move to the fixed version for your line: .NET 8 → 8.0.33, .NET 9 → 9.0.22, .NET 10 → 10.0.14, .NET 11 → Release Candidate 3 (RC2 users must update to RC3). Framework-dependent apps: install the updated runtime and restart. Self-contained apps: rebuild and republish. Containers: rebuild and redeploy on updated images. After updating, re-run the checks that match your risk: Brotli-processing paths, Linux tarball installations, and the SocketAsyncEventArgs and Blazor debugger surfaces from the re-released advisories. A successful install alone is not proof the fix is in place for self-contained and container deployments — check the rebuilt artifact, not just the host.
For background, this release follows the .NET 11 Release Candidate 2 announcement from 13 October (whose servicing versions — 10.0.13, 9.0.21, 8.0.32 — this release supersedes), the Node.js October 2026 security release that first patched the same Brotli flaw, and the VS Code 1.143 release that changed the editor most .NET developers open every day.
FAQs
What is the .NET October 2026 out-of-band security update?
It is an emergency patch Microsoft published on 25 October 2026 for .NET 8, 9 and 10 plus .NET 11 Release Candidate 3, outside the normal servicing calendar. It fixes the Brotli buffer-overflow flaw (CVE-2026-111497), a Linux tarball ownership flaw (CVE-2026-114148), and completes two October 13 fixes that were incomplete.
Which .NET versions do I need to update to?
.NET 8 → 8.0.33, .NET 9 → 9.0.22, .NET 10 → 10.0.14, and .NET 11 → Release Candidate 3. If you are on .NET 11 RC2, you must move to RC3 to receive these fixes — RC2 itself is not patched.
Is .NET Framework affected by the Brotli flaw?
No. Microsoft states explicitly that .NET Framework is not affected. The flaw affects .NET (formerly .NET Core) applications that process Brotli-compressed data through ASP.NET Core request decompression, HttpClient automatic response decompression, or the System.IO.Compression Brotli APIs — and the two decompression features are not enabled by default.
I already patched on 13 October — am I covered?
Not fully. Microsoft re-released the advisories for CVE-2026-70197 and CVE-2026-102870 because the 13 October release did not fully address them. You need this out-of-band release as well, and if you run self-contained apps or containers, a host runtime install alone does not patch them — rebuild and redeploy.
What happens to .NET 8 and 9 after 10 November 2026?
Both reach end of support on 10 November 2026 and stop receiving security fixes. Plan the move to .NET 10 (supported until November 2028) or .NET 11, which reaches general availability at .NET Conf on 10–12 November 2026.
Takeaway: This is the patch you install twice — once for the runtime, once for everything that bundles its own copy — and for .NET 8 and 9, it is nearly the last patch there will ever be. Patch, rebuild, and plan the November move.
Follow World Tech on TechByCountry for tomorrow's update.
📸 Get tech in the last 24 hours on Instagram — follow @_techinlast24hrs for daily posts (9 AM–9 PM) and reels at 12:30 PM & 8:30 PM.
Sources
- Microsoft .NET Blog — ".NET October 2026 Out-of-Band Security Updates" (25 Oct 2026, primary announcement)
- Neowin — "Microsoft issues urgent .NET security patches for critical buffer overflow flaws" (26 Oct 2026)
- GBHackers — "Microsoft Issues Emergency .NET Security Updates to Fix Four Vulnerabilities" (26 Oct 2026)
- SecurityOnline — ".NET Security Update Fixes Brotli Buffer Overflow Flaw" (26 Oct 2026)
- DEV Community — "The Brotli flaw is in .NET now: Microsoft's out-of-band patch, and the self-contained trap" (26 Oct 2026)
Comments
Post a Comment