Microsoft released emergency security updates for .NET on October 25 to address two newly disclosed vulnerabilities and two flaws that its October 13 patches failed to fully resolve, potentially leaving some systems exposed despite earlier updates. The emergency updates cover .NET 8, 9 and 10, along with .NET 11 Release Candidate 3.
Microsoft is urging organizations to install the latest updates as soon as possible.
The Vulnerabilities and Their Risks
One of the newly disclosed flaws, CVE-2026-111497, is a buffer overflow vulnerability in .NET's Brotli decompression algorithm. It affects .NET across all supported platforms and could allow an unauthenticated attacker to read or corrupt an application's memory. Depending on the application's configuration and the circumstances of an attack, exploitation could lead to information disclosure, denial of service, or privilege escalation. The older .NET Framework is not affected.
The second vulnerability, CVE-2026-114148, affects certain .NET installation packages for Linux. It stems from unsafe file ownership metadata in affected .NET tarballs, which could allow an attacker with local access to modify files and gain higher privileges. For .NET 10 and 11, the vulnerability affects source-build tarballs only. For .NET 8 and 9, certain ASP.NET Core tarball distributions are also affected.
Two Previously Disclosed Vulnerabilities
CVE-2026-70197 is a memory corruption vulnerability in the .NET SocketAsyncEventArgs class that could allow an unauthenticated attacker to write data outside allocated memory. Microsoft disclosed the flaw on October 13, but the update released that day did not fully address it.
CVE-2026-102870 is a remote code execution vulnerability in the Blazor WebAssembly debugger. An attacker could exploit the flaw to execute malicious code on a developer's computer if the developer evaluates an expression containing attacker-controlled data during a debugging session. The October 13 update also failed to fully address this vulnerability.
The incomplete fixes highlight a potential weakness in patch verification. Organizations relying on installation records or version checks could have considered affected systems protected even though the vulnerabilities remained.
“Anyone relying on a patch report dated October 13 has been carrying a false green light for almost two weeks, and a version check would not have caught it, because on paper those deployments looked current,” saidDenis Calderone, Principal and CTO of Suzu Labs. “When the vendor's release notes are the source of truth and the source of truth was wrong, verification has to mean more than a version number.”
Why Some Applications Remain Vulnerable After Patching
Installing the latest .NET updates doesn't necessarily mean every application on a system is protected. Framework-dependent applications use a shared runtime installed on the host, so updating that runtime and restarting the applications can address the vulnerabilities. Self-contained applications are different. They bundle their own copy of .NET, which means developers have to rebuild and republish them with the patched runtime.
The same issue applies to containers. Updating the host won't replace a vulnerable runtime inside a container image. Teams must pull updated .NET container images, rebuild the affected containers, and redeploy them.
Remediation becomes more difficult when organizations lack a complete inventory of their .NET applications. Without knowing which applications use a shared runtime and which carry their own, IT teams may overlook vulnerable deployments. Host-level patch reports may show that an update was installed successfully, while applications running older, bundled runtimes remain exposed.
What IT and security teams should do now
Microsoft recommends installing the latest .NET security updates as soon as possible. The patched versions are 8.0.33, 9.0.22 and 10.0.14, along with .NET 11 Release Candidate 3. Organizations running self-contained applications or containers must also rebuild and redeploy them with the updated runtimes. Linux users who build .NET from source should obtain updated source-build artifacts and rebuild their packages, while organizations using affected ASP.NET Core tarballs for .NET 8 or 9 need to update their installations with the corrected packages.
Teams should also review their exposure to the Brotli vulnerability. Microsoft identifies ASP.NET Core request decompression and HttpClient automatic response decompression as potential attack paths, though neither is enabled by default. Applications using Brotli through System.IO.Compression APIs may also be affected. Where immediate patching isn't possible, disabling unnecessary Brotli decompression can help reduce exposure until the updates are deployed, although this may not eliminate every potential attack path.
Administrators can use the dotnet --list-runtimes command to identify runtimes installed on a host, but they'll need to check self-contained applications and containers separately. Maintaining an inventory of application owners, deployment types, and runtime versions can help teams identify vulnerable systems and confirm that updated components are running in production.
