.NET Brotli CVE-2026-111497: emergency patches and an application inventory checklist
News date: 2026-10-25 · Sources reviewed: 2026-11-02
Installing operating-system updates is not always enough to protect a business application. On October 25, 2026, Microsoft issued out-of-band security releases for .NET 8, 9 and 10, plus .NET 11 Release Candidate 3. The key issue, CVE-2026-111497, affects Brotli decompression. An effective response must establish which applications use the relevant APIs and how each application is packaged and deployed.
The vulnerability and its limits
Microsoft describes a buffer overflow in .NET use of the Brotli decoder. Processing specially crafted compressed input may allow an unauthenticated attacker to read or corrupt process memory, potentially causing information disclosure, denial of service or elevation of privilege. Relevant paths include ASP.NET Core request decompression, HttpClient automatic response decompression and System.IO.Compression Brotli APIs. Request decompression and automatic response decompression are not enabled by default, and the .NET Framework is not affected by this specific issue.
- Exposure depends on application behavior and whether untrusted compressed data is processed.
- Avoid assuming that every .NET installation is directly exploitable.
The out-of-band versions
The October 25 releases include .NET 8.0.33, 9.0.22 and 10.0.14; .NET 11 users on release candidates need RC3. Microsoft also addressed CVE-2026-114148 involving Linux .NET tarball ownership, and reissued fixes for CVE-2026-70197 and CVE-2026-102870 because the October 13 updates had not fully resolved them. The Linux tarball issue has different exposure conditions depending on the version and distribution format, so administrators should consult the specific Microsoft advisory.
- Match each workload to its target runtime and supported release.
- Review vendor advisories rather than treating all Linux packages as equivalent.
Inventory the actual runtime footprint
The dotnet --list-runtimes command helps identify runtimes installed on a host, but it does not prove that self-contained applications or containers have been rebuilt. Inventory production and staging applications, build agents, deployment models and dependency owners. For Azure workloads, distinguish between the platform runtime, an application-bundled runtime and container images. Verify what the running application uses, not merely what an administrator sees on the host.
- Record framework-dependent versus self-contained deployments.
- Identify container image digests and their base images.
- Check whether untrusted data reaches Brotli decompression APIs.
Apply the fix according to deployment model
Framework-dependent applications need the updated runtime installed and a controlled application restart. Self-contained applications must be rebuilt and republished because a host runtime update does not replace their bundled runtime. Container workloads require rebuilt images and redeployment from patched bases. Microsoft also calls out source-build consumers and certain ASP.NET Core tarball installations on Linux for additional attention.
- Run functional tests for APIs and compression workflows in staging.
- Monitor exceptions, crashes and latency after deployment.
- Keep a rollback plan that does not silently reintroduce a vulnerable image.
Make application patching an operational control
This incident illustrates the difference between OS patch compliance and application dependency compliance. A useful control includes a software inventory, an accountable owner for each workload, a repeatable build process and evidence of the runtime actually deployed. VALUE360 can support infrastructure reviews, operational monitoring and coordinated change planning across Windows, Linux and Azure environments.
Prioritize a deployment-level inventory and apply the correct fix to each affected application. A fully patched operating system is not proof that a self-contained .NET workload has been updated.
Explore the related VALUE360 service →