Saturday, 31 October 2026Global tech news & guides — what changed, and what it means for you.
AuTechWire
Original editorial illustration of a deep-blue server rack with a glowing compressed-data stream splitting at a decompression valve into a clean teal path and a corrupted amber path, on a dark background

Microsoft’s Emergency .NET Patch: The Same Brotli Flaw, a Different Ecosystem

by

Microsoft’s Emergency .NET Patch: The Same Brotli Flaw, a Different Ecosystem

In brief

  • Microsoft’s out-of-band .NET update fixes the Brotli memory flaw behind Node2Shell — but only apps that decompress untrusted data are exposed. Check your build.
  • The out-of-band release of October 25, 2026 covers .NET 8, 9, and 10, plus .NET 11 Release Candidate 3. The headline fix is CVE-2026-111497, a buffer overflow in .NET’s use of the Brotli decompression algorithm, rated 8.1 under CVSS v3.1 by Microsoft.
  • Most .NET applications are not exposed: ASP.NET Core request decompression and HttpClient automatic response decompression are not enabled by default. The risk concentrates in apps that turned those features on or call the Brotli APIs directly on data they do not control.
  • The same release re-issues two October 13 fixes that did not fully land, and fixes a Linux-only tarball ownership flaw. If you patched on October 13, you still need this update.
  • Microsoft reports no active exploitation so far, but rates exploitation “More Likely.” Working exploits exist in researchers’ hands, which is why the update is out-of-band rather than waiting for the next monthly cycle.

The same flaw, third ecosystem

If the name Brotli has started to feel familiar, that is because this is the third time in a week it has headlined a security release. The flaw is a buffer overflow — an out-of-bounds write — in the Brotli compression decoder, the library that squeezes data smaller for faster transfer over the web. A specially crafted compressed stream can make the decoder write outside its buffer, corrupting process memory. From there, Microsoft says, an unauthenticated attacker could read or corrupt process memory, leading to information disclosure, denial of service, or elevation of privilege.

The flaw first drew wide attention in the Node.js world, where it was nicknamed Node2Shell, and then spread through the Go ecosystem, where it reached frameworks like Traefik, Fiber, and Iris. Microsoft’s October 25 announcement confirms that .NET carries the same flaw in its own copy of the Brotli decoder. The underlying bug is shared; the exposure is not. Each ecosystem’s risk depends on where and how it decompresses data it did not create, and that is where the .NET story differs from the Node.js and Go stories.

One detail from the disclosure timeline is worth noting because it explains why a bug can feel both old and urgent at once. The root cause in Brotli’s source code was fixed in February, but at the time it was not recognized as a security vulnerability, and no new Brotli release shipped with the fix. It was only when researchers demonstrated the security impact in October that the flaw became a vulnerability with a CVE number and a patching scramble across ecosystems. Old code, new understanding, urgent patch — that sequence is now the pattern for this whole incident.

Are you actually exposed? Three paths, and one default that saves most apps

Microsoft’s announcement names three ways a .NET application can process Brotli-compressed data: ASP.NET Core request decompression, HttpClient automatic response decompression, and the System.IO.Compression Brotli APIs. The critical sentence follows immediately: request decompression and automatic response decompression are not enabled by default.

That default is the single most important triage fact in this story. If your application never turned those features on and never calls the Brotli APIs on untrusted input, this flaw does not reach you through .NET’s decoder, whatever version you run. The patch is still worth applying — defence in depth, and the release carries other fixes — but you are not in the emergency queue.

You are in the emergency queue if any of these three is true. First, your ASP.NET Core service enables request decompression, so it decompresses request bodies sent by clients — clients you do not control. Second, your application enables HttpClient automatic response decompression, so it decompresses responses from servers you do not control. Third, your code calls the System.IO.Compression Brotli APIs on data arriving from outside your trust boundary: uploaded files, webhook payloads, fetched archives, or any stream an attacker can influence. In each case the attacker controls the compressed bytes, and the decoder is the thing standing between those bytes and your process memory.

The practical check is a code search, not a version check. Search your services for request-decompression middleware, HttpClient decompression settings, and Brotli API calls, and trace whether the data they handle comes from outside. A service that decompresses only its own internally produced data is in a different risk class from a public API endpoint that decompresses whatever a client sends. Prioritize the public-facing decompression paths first, then work inward.

The patched versions, and the October 13 catch

The patched builds, per Microsoft’s release announcement, are:

  • .NET 8: runtime 8.0.33 (SDKs 8.0.133 and 8.0.427, depending on feature band)
  • .NET 9: runtime 9.0.22 (SDKs 9.0.123 and 9.0.320)
  • .NET 10: runtime 10.0.14 (SDKs 10.0.114 and 10.0.403)
  • .NET 11: Release Candidate 3 (11.0.100-rc.3.26522.148) — still a prerelease, not the final .NET 11 release

If your runtime is below the patched version for its line, update it. The two SDK numbers per line belong to different SDK feature bands; pick the one matching the band you already use rather than switching bands mid-crisis.

The release also carries a catch that will surprise teams who did their patching diligently two weeks ago. Microsoft is re-releasing the advisories for CVE-2026-70197 (a SocketAsyncEventArgs memory corruption issue) and CVE-2026-102870 (a Blazor WebAssembly debugger issue) because the October 13, 2026 release did not fully address them. Today’s updates provide those fixes. In plain terms: if you patched on October 13 and stopped, you are not fully patched. This update closes both the new Brotli flaw and the unfinished October business, which is a second reason it went out-of-band instead of waiting.

A third fix rides along for Linux deployments only: CVE-2026-114148, unsafe ownership metadata in affected .NET tarballs, which could allow a local attacker to modify files and gain elevated privileges. For .NET 10 and 11 it affects source-build tarballs only; for .NET 8 and 9 it also affects ASP.NET Core distributions obtained through ASP.NET Core tarballs, including for users who do not build from source. Linux teams installing from tarballs should check their distribution path, not just their runtime version.

And one reassurance for teams on the older stack: .NET Framework — the classic Framework built into Windows — is not affected by the Brotli bug. If your application runs on .NET Framework rather than modern .NET, this particular flaw is not yours to patch.

What Microsoft says about exploitation — and what it does not say

Microsoft’s advisory marks the flaw as publicly disclosed and assesses exploitation as “More Likely.” Working exploits have been put together by researchers, but as of the announcement there was no indication of criminals using them in successful attacks. That combination — working exploits, no observed abuse yet, and a “More Likely” rating — is exactly the profile that justifies an out-of-band release: the window between public exploit code and real-world use is the window defenders have, and it is measured in days, not months.

The Azure side of the story shows the same urgency with a different timeline. Azure App Service for Windows began rolling out the updated built-in .NET runtimes through its safe deployment practices on October 26, with the rollout in progress rather than complete at last check. If your application runs on Azure App Service’s built-in runtimes, the platform will bring you the fix — but “in progress” is not “done,” and self-contained deployments, containers with pinned runtimes, and on-premises hosts are your responsibility regardless. Verify the running runtime, not the deployment pipeline’s intentions: the version your process actually loads is the only version that matters.

What to do today

  • If you run a public-facing ASP.NET Core service with request decompression enabled: patch first, today. This is the highest-exposure configuration in the .NET story, because the attacker supplies the compressed bytes directly.
  • If your code decompresses untrusted data through HttpClient or the Brotli APIs: patch next, and audit which data sources feed those paths while the update rolls out. Consider temporarily disabling decompression of untrusted input if the patch cannot land immediately.
  • If you patched on October 13: patch again. The re-released fixes for CVE-2026-70197 and CVE-2026-102870 are in this update, and the October 13 versions do not fully cover them.
  • If you run Linux from tarballs: check the CVE-2026-114148 scope for your .NET line and distribution path, not just the runtime number.
  • If you run .NET Framework, or your .NET apps never enable decompression: apply the update in your normal cycle, and record the triage — the next Brotli-style shared-library flaw will ask the same “are we exposed?” question, and the answer will again depend on your configuration, not just your version.
  • If you run on Azure App Service built-in runtimes: confirm the rollout has reached your app’s region and stamp, and check the runtime your app actually reports.

Why this keeps happening

The deeper lesson of the Brotli week is not about one decoder. It is about shared libraries: a single compression library sits inside Node.js, Go, Python packages, .NET, and dozens of other runtimes, and a flaw in it becomes a flaw in all of them at once. Each ecosystem patches on its own schedule, with its own version numbers, its own defaults, and its own exposure profile — which is why a single CVE number generates a week of separate announcements, each of which matters differently depending on what you run.

For defenders, the practical consequence is that tracking CVEs by product name is no longer enough. Track them by shared component, too. When a flaw lands in a widely bundled library, assume every runtime you run needs checking, and check configuration — not just version — in each one. The .NET story’s saving grace, the off-by-default decompression setting, is a reminder that good defaults are a security control in their own right: they turned a critical flaw into a non-event for most .NET applications, and the applications that opted out of the default are the ones paying for it now.

What is still unknown

Whether exploitation moves from researcher demonstrations to real attacks is the open question, and it is the one that will decide whether this update is remembered as timely or late. Microsoft’s “More Likely” assessment and the public exploit code point in one direction; the absence of observed abuse so far points in the other. Treat the patch as urgent for exposed configurations regardless, and watch for CISA Known Exploited Vulnerabilities listing or vendor incident reports in the days after this release. This draft will need a freshness check at publish time for any exploitation report, CISA listing, or Microsoft update.

Related reading

Sources

  • Microsoft .NET Blog, “.NET October 2026 Out-of-Band Security Updates,” October 25, 2026: https://devblogs.microsoft.com/dotnet/dotnet-october-2026-oob-security-updates/
  • The Register, “Microsoft releases emergency .NET security fixes for Google Brotli bug,” October 26, 2026: https://www.theregister.com/security/2026/10/26/microsoft-releases-emergency-net-security-fixes-for-google-brotli-bug/5305515
  • Cycode, “node2shell (CVE-2026-111497): What to Patch in Node.js” (updated October 26, 2026 with .NET section): https://cycode.com/blog/node2shell-cve-2026-111497/
  • Azure App Service, “.NET Brotli Security Updates on Azure App Service for Windows,” October 26, 2026: https://azure.github.io/AppService/2026/10/26/dotnet-brotli-security-update-app-service-windows.html

Last verified: October 28, 2026.

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Related Stories

Leave a Comment