Microsoft shipped out-of-band .NET security updates on 25 October 2026 for .NET 8, .NET 9, .NET 10 and .NET 11 Release Candidate 3. Two of the four fixes exist only because the 13 October updates did not fully address the vulnerabilities they claimed to close.
What happened
The corrected advisories are CVE-2026-70197, an out-of-bounds write in System.Net.Sockets rated 8.1, and CVE-2026-102870, a code injection flaw in ASP.NET Core rated 8.8. Both allow code execution over a network. On Windows, reusing a SocketAsyncEventArgs instance across IPv4 and IPv6 datagram sockets can leave a cached native address buffer too small, producing an out-of-bounds write during ReceiveFromAsync.
The release also covers CVE-2026-114148, unsafe ownership metadata in .NET tarballs that lets a local attacker modify files and gain elevated privileges on Linux. Microsoft lists it against source-build tarballs on .NET 10 and 11, and against ASP.NET Core tarballs on .NET 8 and 9, which includes people who do not build .NET from source. The same release carries the Brotli decompression fix for CVE-2026-111497, already patched upstream in Node.js.
Microsoft has not reported exploitation of any of these. The reason to move anyway is the second ship: a fix that was already installed once and did not work is not a control you can rely on until you confirm the newer build is actually the one running.
Who is affected
Systems running .NET 8, 9, 10 or the .NET 11 preview, which in practice means almost every Windows line-of-business application written in the last decade.
- ASP.NET Core applications that have request decompression or automatic response decompression enabled, if they handle untrusted compressed input.
- Self-contained and single-file .NET applications, which carry their own runtime and are not fixed by installing a newer runtime on the host.
- Docker and Kubernetes workloads built on older .NET base images.
- Linux servers running ASP.NET Core installed from tarballs, including .NET 8 and 9 deployments that were never built from source.
What to do now
Patch the runtime and then rebuild anything that ships its own copy of it.
- Install .NET 8.0.33, 9.0.22 or 10.0.14, or .NET 11 Release Candidate 3, and restart the hosted applications.
- Run dotnet --list-runtimes on each server and confirm the build number, not just the major version.
- Rebuild and republish self-contained applications, and rebuild container images from updated .NET base images. A host runtime update does nothing for these.
- Update Visual Studio 2022 and 2026 and any build agents, since the affected component list covers the toolchain as well as the runtime.
- Treat the earlier October patch as unverified until the new build number is confirmed on every host that reported it as done.
What this means for South African businesses
A South African SME rarely knows which .NET runtime a vendor's line-of-business application carries, and vendor installs are usually self-contained, which is exactly the case a host-level Windows update does not fix. The realistic exposure is not a targeted attack on the runtime but a stale copy of it sitting on a server nobody has rebuilt since 2022. If your application inventory does not record runtime build numbers, this is the week to start, because a reissued patch is the cheapest possible reminder that installed does not mean patched.
Source: Microsoft .NET blog, October 2026 out-of-band security updates.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.