Summary
- The 25 October updates cover supported .NET 8, 9 and 10, and .NET 11 Release Candidate 3.
- SocketAsyncEventArgs corrections apply to .NET 8–11; the Blazor debugger reissue applies to .NET 10 and 11.
- Self-contained deployments and containers require rebuilt application artefacts.
Microsoft has issued emergency .NET security updates following the discovery of vulnerabilities in Brotli decompression and Linux package handling, while also correcting two October fixes that did not fully resolve their original issues.
The Microsoft .NET team released the out-of-band packages on 25 October 2026 for supported .NET 8, 9 and 10 versions, alongside Release Candidate 3 of .NET 11. The company recommends prompt deployment according to the affected runtime and packaging arrangements.
CVE-2026-111497 concerns a memory corruption vulnerability in .NET's handling of the Brotli decompression algorithm. Brotli is widely used to reduce the size of data transmitted between web services and clients, and vulnerable decoding can allow an unauthenticated attacker to read or corrupt process memory.
Microsoft identifies potential consequences including information disclosure, denial of service and elevation of privilege. Exposure depends on whether an application processes untrusted Brotli-compressed content through affected interfaces.
Those interfaces include ASP.NET Core request decompression, HttpClient automatic response decompression and direct use of Brotli APIs in System.IO.Compression. Request and automatic response decompression are not enabled by default, which changes the exposure of applications that have not opted into those features.
A second flaw, CVE-2026-114148, concerns unsafe file-ownership metadata in particular Linux .NET archive distributions. Under affected conditions, local users may be able to modify files or gain elevated privileges through the ownership settings applied when affected packages are installed.
The packaging scope is version dependent. For .NET 10 and .NET 11, the vulnerability affects source-build tarballs. For .NET 8 and .NET 9, it also affects ASP.NET Core runtime archives obtained through tarball distributions, including customers who do not build .NET from source.
Microsoft simultaneously reissued corrections for CVE-2026-70197 and CVE-2026-102870 because its routine 13 October updates had not fully addressed those defects. The scope of the two reissues is different and should not be combined into a uniform affected-version claim.
CVE-2026-70197 concerns SocketAsyncEventArgs memory corruption and applies to .NET 8, 9, 10 and 11. The Blazor WebAssembly debugger issue, CVE-2026-102870, applies to .NET 10 and 11 under the company's current advisory.
The new stable versions are .NET 8.0.33, 9.0.22 and 10.0.14. Developers using .NET 11 Release Candidate 2 should move to Release Candidate 3 to receive the relevant corrections.
Updating the operating system or shared runtime alone does not remediate every deployment. Framework-dependent applications normally use a centrally installed runtime, so upgrading that runtime and restarting the application can incorporate the new components.
Self-contained applications, however, distribute their own runtime inside the application package. Administrators must rebuild and republish those artefacts; a patched runtime installed elsewhere on the server does not replace the one bundled with the application.
Containerised services similarly need updated images and redeployment. Source-build consumers must use corrected source-build packages, while affected .NET 8 and 9 ASP.NET Core tarball users need the refreshed runtime archive.
This is important in organisations running numerous independently deployed microservices. A central asset inventory might confirm that hosts have received security updates while older containers or packaged applications continue to run the vulnerable code.
Supplier-managed software creates another dependency. Customers may need a vendor-provided rebuild before the corrected runtime reaches their application, even where Microsoft has already released the underlying fix.
Microsoft's release guidance also distinguishes installation from verification. A framework-dependent deployment can be checked against the runtime versions installed on its host, but a self-contained release or container must be inspected as an application artefact. Teams operating several deployment models therefore need to distinguish the version of .NET installed on a server from the version actually running inside each affected service.
The .NET Framework product line is not affected by these particular out-of-band updates. The vendor's release notice sets out the package differences, corrected version numbers and deployment instructions needed to establish which assets remain exposed.
The incident also shows why correcting a vulnerability and proving that corrected code is present in production are separate tasks. Microsoft has supplied the fixes; the deployment method determines how they reach running applications.
