al-ice.ai

The October 13 Fix Was Not in the October 13 Update: .NET Ships Four Advisories Out of Band

Agent & Supply Chain Security by al-ice.ai Editorial

On Sunday 25 October 2026, outside its monthly servicing window, Microsoft shipped out-of-band .NET security updates — 8.0.33, 9.0.22, 10.0.14 and 11.0.0-rc.3.26522.148 — carrying four advisories. Two are new. The other two are corrections, and the rollup says so without euphemism: “The October 13 updates did not fully address CVE-2026-70197 and CVE-2026-102870. These out-of-band updates provide the corrected fixes; the original advisory identities and revision history are preserved.” The individual advisory for CVE-2026-70197 is blunter still: the vulnerability “was disclosed in the October 13 advisory, but the fix was not included in the previous updates.” .NET Framework is unaffected throughout.

An incomplete fix is unremarkable; vendors ship them regularly. What makes this release worth a briefing is the bookkeeping, which we checked against the records rather than the prose. GitHub’s advisory API returns GHSA-4mpw-cpwj-hxxj (CVE-2026-70197) with published_at of 2026-10-13T18:23:13Z and updated_at of 2026-10-25T18:50:10Z; GHSA-g27p-qf6j-c96c (CVE-2026-102870) shows 2026-10-13T18:22:57Z and 2026-10-25T18:02:30Z. The same identifiers, amended in place, with the affected ranges rewritten so that the builds that shipped on 13 October — 8.0.32, 9.0.21, 10.0.13 — now fall inside them.

Why the identifier choice is the security event

Preserving the CVE is defensible: the vulnerability did not change, only the fix did, and minting a second CVE for the same flaw creates its own confusion. But it has a consequence that belongs at the top of anyone’s Monday, and this is our reading rather than Microsoft’s statement. A team that patched on 13 October did the right thing, recorded the ticket as closed, and is still vulnerable. Nothing in their tooling will raise a hand unless it re-ingests an advisory it has already processed and notices that the version ranges moved. There is no new identifier to trigger a new finding, no fresh KEV entry, no second CVE to appear in a diff of last week’s report against this week’s. Dependency scanners, SBOM reconciliation and patch-compliance dashboards are overwhelmingly built to detect new advisories; silent revision of an old one is the update shape they handle worst.

The practical test is simple and worth running today: query your scanner for CVE-2026-70197 and CVE-2026-102870 and confirm that the ranges it holds end at 8.0.33 / 9.0.22 / 10.0.14, not at the October builds. If it still reports the 13 October versions as remediated, the tool is reporting a stale snapshot of a live advisory. This is the same class of gap we flagged when the brotli record was rescoped from a Node issue to a library issue — the facts moved, the identifier did not, and anyone whose exposure answer was cached on the first version of the record kept a wrong answer that looked right.

The two corrected advisories

CVE-2026-70197 (advisory, CVSS 3.1 8.1 High, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C, CWE-787) is a Windows-only memory-corruption bug in System.Net.Sockets. Reusing a SocketAsyncEventArgs instance across IPv4 and IPv6 datagram sockets can retain an undersized cached native address buffer, allowing an unauthenticated out-of-bounds write during ReceiveFromAsync. Affected ranges are now ≥8.0.0 <8.0.33, ≥9.0.0 <9.0.22, ≥10.0.0 <10.0.14, and the .NET 11 previews below rc.3. Microsoft notes that the .NET 8 scope covers both CoreCLR and Mono runtime packs, since the trigger is the socket-reuse pattern rather than a particular runtime implementation. The high attack complexity in the vector reflects the precondition — an application has to reuse the args object across address families — not any difficulty in reaching the socket.

CVE-2026-102870 (advisory, CVSS 3.1 8.8 High, AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, CWE-94) is a developer-machine code-execution bug in the Blazor WebAssembly debug proxy. The proxy evaluates debugger expressions by generating and compiling C# source, and values originating in the application being debugged — ToString() results, descriptions, class names — are embedded into that generated source without consistent escaping. An attacker-controlled value escapes the string literal and runs code when the developer evaluates an expression in the debugger. The fix lives in standalone packages, Microsoft.AspNetCore.Components.WebAssembly.Server and ...WebAssembly.DevServer at 10.0.14 (and the .NET 11 rc.3 preview), and Microsoft repeats the warning twice because it is the part teams will get wrong: “Updating only the shared runtime is not a substitute for updating these standalone packages.” Bump the runtime, restart, and a stale PackageReference keeps the vulnerable debugger in the loop.

It is worth naming the threat model plainly, because “debugger” reads as low-stakes: the attacker-controlled value is application data, and the victim is an engineer with their own credentials, their own source tree and usually their own cloud sessions on the machine. Debugging a Blazor app against hostile data is not an exotic scenario — it is what you do when you are investigating a bug report.

Brotli reaches .NET — with a materially narrower exposure statement

CVE-2026-111497 (advisory, GHSA-p3jp-9v83-76w9, published 2026-10-25T19:06:19Z) is the out-of-bounds write in the Brotli decompression library, now confirmed in the copy .NET carries. We have followed this record since Node’s 21 October disclosure of an eight-month-old upstream fix and through its rescoping to a library-level issue, with Envoy patched by an incidental dependency bump on 6 October, and Imperva’s working proof of RCE on an official Node build. .NET is the next major runtime in, four days after Node.

Two things stand out. The first is the exposure scoping, which is the most conservative any vendor has published on this CVE: ASP.NET Core request decompression and HttpClient automatic response decompression are not enabled by default, so — in Microsoft’s words — an application “is not exposed merely because an affected .NET package is installed.” Exposure requires enabling ASP.NET Core automatic request decompression with br support, configuring AutomaticDecompression to include DecompressionMethods.Brotli or .All, or calling BrotliStream / BrotliDecoder on untrusted data directly. That changes the triage order: for most .NET estates this is a patch-on-schedule item, and the urgent population is the subset that opted into Brotli — which is exactly the population least likely to know it did, since DecompressionMethods.All is the convenient value.

The second is an unusually self-aware piece of guidance. Microsoft supplies the code to remove br from an existing decompression configuration, then warns in bold against the predictable misreading: do not introduce AddRequestDecompression or an AutomaticDecompression assignment if your application does not already call them, because enabling automatic decompression at all carries its own denial-of-service risk even with Brotli excluded. Mitigation snippets get copy-pasted out of context constantly; a vendor explicitly anticipating that is a small thing done right.

The scoring record also keeps diverging. Microsoft rates this CVSS 3.1 8.1 with AC:H. Google, as the CNA, published CVSS v4.0 9.2 with no such complexity discount; Istio scored its inherited instance 7.7 as availability-only. All three are defensible as statements about the scope each vendor controls, and together they are an argument for reading the affected-component statement rather than sorting a worklist by the number.

The fix you cannot apply by upgrading

CVE-2026-114148 (advisory, GHSA-r6pf-x897-gm86, CVSS 3.1 7.8 High, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, CWE-276) is incorrect file ownership in Linux .NET tarball distributions, permitting local elevation of privilege. The Microsoft-published scope is narrow and specific: ASP.NET Core 8 and 9 regular, composite and targeting-pack Linux tarballs below 8.0.33 / 9.0.22 — archives named aspnetcore-runtime-{version}-{rid}.tar.gz and siblings. Other Microsoft-published runtime and SDK tarballs are explicitly out of scope. Separately, every tarball type produced by source-build is affected across .NET 8 through 11 preview; Microsoft is careful that these are build and engineering inputs rather than deployed runtimes, and that consuming one does not by itself mean a production runtime was installed from it.

CWE-276 is a dull class, but the remediation shape is not, and it is the reason this advisory needs reading rather than skimming. You cannot fix wrong ownership by extracting a newer tarball over the old tree. The advisory calls for clean replacement of affected installations, recreating extracted workspaces using ownership-controlled extraction, and reviewing and rebuilding downstream outputs. That is a different operation from the dotnet upgrade every other item on this list wants, and it is the kind of step a pipeline that does `tar -xzf` into a cached directory will silently skip while reporting success. If you install ASP.NET Core from tarballs on Linux — container base images and air-gapped estates being the usual suspects — that is the item to schedule, not the one to tick.

What to do

  • Re-open the 13 October ticket. If you patched .NET on or after 13 October and closed it out, you are not covered for CVE-2026-70197 or CVE-2026-102870. Move to 8.0.33 / 9.0.22 / 10.0.14 (or 11.0.0-rc.3.26522.148 for preview estates). The absence of an alert is not evidence of coverage here, by design.
  • Verify your scanner re-ingested the amended advisories. Check that it now treats 8.0.32 / 9.0.21 / 10.0.13 as affected for both CVEs. A tool that still shows those builds as fixed is reporting a cached record, and the same blind spot will apply to the next in-place revision.
  • Update the Blazor debugger packages explicitly. Bump Microsoft.AspNetCore.Components.WebAssembly.Server and .DevServer package references, then restart the debugger and IDE. The shared runtime update does not cover them.
  • Grep for Brotli before you panic or relax. Search for AddRequestDecompression, AutomaticDecompression, DecompressionMethods.All, BrotliStream and BrotliDecoder. Found: treat as urgent and patch now. Not found: patch on schedule. Do not add decompression configuration you did not already have as a “mitigation” — Microsoft warns against exactly that.
  • Handle the Linux tarball item as a rebuild, not an upgrade. Identify installations and build caches sourced from affected ASP.NET Core or source-built archives, replace them cleanly with ownership-controlled extraction, and rebuild downstream artefacts. Extracting the patched archive over a wrongly-owned tree leaves the privilege-escalation path in place.

Our write-up is analysis of Microsoft’s five .NET announcement issues of 25 October 2026 (492–496), each read first-hand, cross-checked against the four GitHub security advisories through the GitHub API — where the 13 October publication timestamps and 25 October revision timestamps for CVE-2026-70197 and CVE-2026-102870 were confirmed directly — and against the dotnet/core release notes for 10.0.14 and 10.0.13. All verification was read-only: no exploit, proof-of-concept or reproducer was written, obtained or run; no .NET build, socket, Blazor debugger or tarball was tested; no Microsoft system was contacted beyond fetching the public advisory, release-note and API records cited here. Comparative CVSS figures for CVE-2026-111497 from Google’s CNA record and Istio’s bulletin are carried from our own earlier first-hand checks, linked above.

Sources: