Microsoft Issues Emergency .NET Fixes for Brotli Flaw and Linux Privilege Escalation

Microsoft Issues Emergency .NET Fixes for Brotli Flaw and Linux Privilege Escalation

Microsoft releases emergency .NET updates to fix a Brotli memory flaw and Linux privilege escalation, while correcting two incomplete October security patches.

Listen to this article

0:00 —

Press play to start listening

Microsoft has released emergency security updates for .NET 8, .NET 9, .NET 10 and .NET 11 Release Candidate 3 (RC3), fixing a buffer overflow flaw and a Linux vulnerability that could let local attackers gain higher privileges. The company has urged developers and administrators to install the updates as soon as possible.

The October 25 out-of-band release also revisits two vulnerabilities that Microsoft’s October 13 security updates did not fully fix. The latest release addresses both issues again, alongside the newly disclosed flaws. Hackread.com previously reported on Microsoft’s October Patch Tuesday, when the company released fixes for a record 1,413 vulnerabilities.

What the Vulnerabilities Could Allow

The most serious issue, CVE-2026-111497, affects Brotli- a compression technology used to reduce the size of data transferred or processed by applications. A flaw in how .NET handles this data could let an attacker read or corrupt a program’s memory without first logging in. Depending on the application and circumstances, this could expose information, crash a service or allow an attacker to gain higher privileges.

The vulnerability affects .NET applications on all platforms, but exposure depends on how they handle compressed data. Microsoft specifically identifies ASP.NET Core request decompression, automatic response decompression in HttpClient, and the Brotli APIs in System.IO.Compression as affected paths. The automatic decompression features are off by default, and .NET Framework is not affected.

The same Brotli decoder flaw also affects other software, including Node.js. On October 26, Tenable reported that proof-of-concept code was publicly available and that researchers had demonstrated remote code execution in Node.js. It also reported an attempted exploitation targeting Node.js, but noted that it had not independently confirmed the activity.

A second flaw, CVE-2026-114148, affects Linux .NET tarballs containing unsafe file ownership information. A local attacker could use this issue to change files and gain elevated privileges. It affects source-build tarballs for .NET 10 and .NET 11. On .NET 8 and .NET 9, affected ASP.NET Core tarball distributions are also included, even when users do not build .NET from source.

Updates and Deployment Requirements

Microsoft has also reissued fixes for CVE-2026-70197, a memory corruption flaw involving SocketAsyncEventArgs, and CVE-2026-102870, which affects the Blazor WebAssembly debugger. The October 13 updates did not fully address either issue.

The updated releases are .NET 8.0.33, 9.0.22 and 10.0.14, alongside .NET 11 RC3. Users running .NET 11 RC2 should upgrade to RC3.

Update details (source: Microsoft)

How the updates are applied depends on the deployment because applications using a shared .NET runtime need the updated runtime installed and must be restarted, while applications bundled with their own runtime must be rebuilt and republished. Container deployments require new images and redeployment.

Those building .NET from source must rebuild their packages using updated artifacts. Users of affected ASP.NET Core tarballs on .NET 8 and .NET 9 must install the refreshed versions. Updating the host system alone will not patch a runtime bundled inside an application or container.

Seemant Sehgal, founder and CEO of BreachLock, highlighted the potential consequences if attackers exploit the Brotli flaw in a vulnerable .NET process.

“When vulnerabilities like CVE-2026-111497 are left unpatched, an attacker exploiting this chain can start with memory corruption inside a vulnerable .NET process, escalate privileges against the service account running it, and inherit whatever reach that account has. Enterprises typically grant those accounts more reach than they need,” Sehgal told Hackread.com.

He urged organizations to identify the runtime versions running in production and establish who is responsible for each deployment.

“Teams that already know what runtime versions are running in production and who owns each one will patch this fast. The rest should start that inventory work now,” he said.

Deeba is a veteran cybersecurity reporter at Hackread.com with over a decade of experience covering cybercrime, vulnerabilities, and security events. Her expertise and in-depth analysis make her a key contributor to the platform’s trusted coverage.
Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts