vulnerability

.NET ships an out-of-band patch: a Brotli overflow, a tarball ownership flaw, and two fixes that had to be redone

Microsoft's 2026-10-25 out-of-band .NET release fixes a Brotli decompression buffer overflow now on CISA's KEV list, a Linux tarball ownership flaw that lets a local attacker escalate, and two network-code-execution CVEs whose October 13 patch turned out to be incomplete.

A decompression chip on a circuit board with a stream of compressed data overflowing into the adjacent memory, shown as a glowing red crack. Rendered with AI.

On 2026-10-25, Microsoft released an out-of-band .NET security update, and two days later CISA added the headline flaw to the Known Exploited Vulnerabilities catalog. The release bundles three things that deserve separate attention: a buffer overflow in the Brotli decompression path, a local privilege escalation in the Linux tarball packaging, and the re-release of two network-code-execution CVEs whose October 13 patch did not fully hold.

The Brotli decoder overflow (CVE-2026-111497)

The overflow sits in how .NET uses Google's Brotli decompression algorithm (versions 1.0.3 through 1.2.0). A remote, unauthenticated attacker who can get a crafted Brotli-compressed stream to a .NET process can corrupt the decoder state memory that sits next to the buffer being written. Depending on what that corrupted state controls, the outcome ranges from leaking sensitive memory contents and crashing the process (a denial of service) to, in the worst case, executing arbitrary code.

The exposure path is worth stating plainly because it shrinks the real-world blast radius. A .NET process only reaches the vulnerable decoder through one of three routes: ASP.NET Core request decompression, HttpClient automatic response decompression, or the System.IO.Compression Brotli APIs. The first two are not enabled by default, and .NET Framework is not affected at all. A service that never turns on Brotli decompression or never calls the Brotli APIs directly is not exposed to this flaw through the network. The CISA row was added 2026-10-27 with a federal remediation due date of 2026-11-10, and it maps to CWE-252 (unchecked return value) and CWE-787 (out-of-bounds write).

The tarball ownership flaw (CVE-2026-114148)

The second item is a local privilege escalation. Affected .NET tarballs for Linux carry unsafe ownership metadata, which lets a local attacker modify files and gain elevated privileges. The scope differs by version: on .NET 10 and 11 the flaw is limited to source-build tarballs, but on .NET 8 and 9 it also reaches ASP.NET Core distributions obtained through the ASP.NET Core tarballs, including users who do not build from source. For a self-hosted or containerized .NET deployment that pulls its runtime from a tarball, that second case is the one to check.

The re-release: two fixes that had to be redone

The release also re-issues the advisories for CVE-2026-70197 (a SocketAsyncEventArgs out-of-bounds write that allows unauthorized network code execution on .NET 8, 9, 10, and 11) and CVE-2026-102870 (a Blazor WebAssembly debugger code-injection flaw, unauthorized network code execution on .NET 10 and 11). The reason for the re-release is the one that matters most for operators: the October 13, 2026 release did not fully address these two flaws. Microsoft shipped a patch on 2026-10-13, and for roughly the next twelve days two network-code-execution vulnerabilities remained exposed because that patch was incomplete. The 2026-10-25 out-of-band release is the correction.

Defensive response

The fixed versions are .NET 8 8.0.33, .NET 9 9.0.22, .NET 10 10.0.14, and .NET 11 RC3 (RC2 users must move to RC3). Update the runtime and any ASP.NET Core distribution in the same pass. If you run .NET 8 or 9 from a tarball, verify the ownership metadata is fixed in the build you are pulling.

The two things worth carrying away

The first is the incomplete-patch window. A vendor patch that shipped on 2026-10-13 and was found not to hold is a concrete reminder that a "patched" state is only as good as the last verified release. The twelve-day gap between the first patch and the out-of-band correction is the period during which the two network-code-execution flaws were still live. The second is the decompression path. Because request and automatic response decompression are off by default, the Brotli overflow is a lower-probability exposure than the raw "remote unauthenticated RCE" framing suggests, and the honest risk assessment depends on whether your service actually turns that path on.

Note on the Node.js angle: the underlying Brotli CVE was already covered from the Node.js side in a prior Malwlab article. This piece covers the .NET-specific follow-up, the tarball ownership flaw and the re-released .NET CVEs, not a re-hash of the Node.js release.

Sources

This article was drafted with AI/LLM assistance and reviewed by a human before publication. All factual claims were checked against the public sources cited above. The feature image was generated with AI. See How we use AI for the full workflow.

Topics: