Yesterday I wrote about HTTP2Shell: CVE-2026-111497, a buffer overflow in the Brotli decoder that ended up in Node.js's HTTP stack and a long tail of Python packages. Today the same CVE forced Microsoft to do something it rarely does mid-cycle: ship out-of-band security updates for .NET 8, .NET 9, .NET 10, and .NET 11 Release Candidate 3.

If you run .NET services, this one needs action, not a newsletter skim. And the way you update depends entirely on how you deploy - which is where teams usually get this wrong.

What Microsoft shipped

From the official .NET blog announcement:

  • .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 to get the fixes)

The release addresses two CVEs and re-releases two advisories:

  1. CVE-2026-111497 - the Brotli buffer overflow. Per the MITRE record, it lives in c/dec/decode.c in Brotli 1.0.3 through 1.2.0 and lets a remote, unauthenticated attacker corrupt decoder memory, disclose memory contents, crash the process, or potentially execute code with a crafted compressed stream. In .NET terms, your app is exposed 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 from Microsoft: request decompression and automatic response decompression are not enabled by default, and .NET Framework is not affected.
  2. CVE-2026-114148 - unsafe ownership metadata in Linux .NET tarballs, letting a local attacker modify files and escalate privileges. For .NET 10 and 11 this affects source-build tarballs only; for .NET 8 and 9 it also affects ASP.NET Core tarballs, including people who never build from source.
  3. CVE-2026-70197 (SocketAsyncEventArgs memory corruption) and CVE-2026-102870 (Blazor WebAssembly debugger) - re-released because the October 13 patches did not fully address them. If you patched on Patch Tuesday and moved on, you are not actually patched.

The self-contained trap

This is the part that matters operationally, and it's the same trap I described for Node.js yesterday: installing the fixed runtime on the host does not reach every application.

  • Framework-dependent apps: install the updated runtime, restart the app. Done. You can verify with dotnet --list-runtimes.
  • Self-contained apps: the runtime is bundled inside your deployment artifact. Installing 8.0.33 or 10.0.14 on the host changes nothing for these. You must rebuild and republish with the updated runtime, and dotnet --list-runtimes on the server will not tell you a self-contained app exists, let alone what it bundles.
  • Containers: same story. Rebuild and redeploy from the updated .NET container images. Patching the host VM that runs your containers does not touch the runtime inside them.
  • Linux tarball installs on .NET 8/9: update from the refreshed ASP.NET Core Runtime tarball even if you don't build from source, because of the ownership fix.

So the audit question isn't "did we patch the servers?" It's "for every deployed artifact, which runtime is inside it, and when was it built?"

A five-minute audit

An example check you can adapt - first, find Brotli exposure in code:

# Are we decompressing Brotli anywhere? grep -rn --include='*.cs' -E 'BrotliStream|BrotliDecoder|DecompressionMethods\.Brotli|RequestDecompression' src/ # Are we enabling it in the HTTP pipeline? grep -rn --include='*.cs' -E 'UseRequestDecompression|AutomaticDecompression' src/

Then, for each deployment, answer the runtime question:

# Framework-dependent check (on the host): dotnet --list-runtimes # Self-contained / container check: you need the artifact, not the host. # For containers, inspect the base image tag: grep -rn -E 'FROM mcr\.microsoft\.com/dotnet' -i --include='Dockerfile*' .

Any BrotliStream, DecompressionMethods.Brotli, UseRequestDecompression(), or HttpClient handler with AutomaticDecompression set means the code path Microsoft lists as exposed. Treat those deployments as priority one.

The bigger picture

In three days we watched one Brotli CVE travel through Node.js, Python package ecosystems, and now the entire supported .NET line - plus PHP's own two RCEs from the same week, which BleepingComputer reports are now exploited in the wild. The pattern isn't that runtimes are careless. It's that a single compression library, vendored quietly into everything, turns one decoder bug into a global patch day. The scanners won't save you here: the vulnerable code is inside your runtime, inside your self-contained binary, inside your container image - places dependency scanners routinely miss.

The fix list is short: update, rebuild, redeploy, verify the artifact - not the host. The teams that get bitten are the ones that stop at dotnet --list-runtimes looking healthy.

Sources: Microsoft .NET Blog - October 2026 Out-of-Band Security Updates, CVE-2026-111497 (MITRE), BleepingComputer on PHP2Shell exploitation.