Brotli patches are a deployment problem, not a package update

A buffer overflow in Brotli has turned a routine compression-library update into an application and deployment cleanup. CVE-2026-111497 is reachable wherever an application decompresses attacker-controlled Brotli data—not just in HTTP/2 servers—and patches now span .NET, Node.js, Python, Bun, Envoy and Istio.

Microsoft issued out-of-band .NET fixes on October 25, 2026 for .NET 8, 9, 10 and 11, warning that an unauthenticated attacker could read or corrupt process memory. Microsoft assigns the flaw a CVSS v3.1 score of 8.1 and marks exploitation as “More Likely.” Its stated outcomes include information disclosure, denial of service and elevation of privilege.

The vulnerability has accumulated several names—Broccoli2Shell, Node2Shell and HTTP2Shell—because the bug was initially disclosed through Node.js before its upstream Brotli-decoder scope became clear. Those labels describe different entry points and disclosure histories, not separate flaws. The technical boundary is whether a process accepts and decompresses an untrusted Brotli stream.

Recommended reading

PHP’s patch wave is an asset-inventory failure

Sergey Kuznetsov • Oct 22, 2026 • 10 min read

The decoder mistake behind the overflow

The defect sits in Brotli’s streaming decoder. A malformed block switch can be treated as a temporary request for additional input rather than a permanent format error. The decoder then continues appending bytes to an internal eight-byte buffer, writing beyond its bounds and corrupting adjacent memory.

“An invalid block switch was reported as a temporary need for more input instead of a permanent format error, so the streaming decoder kept appending input bytes to an eight-byte internal buffer.”

That mechanism makes a compressed HTTP request one plausible delivery route, but not the only one. A client application can also be compromised when it fetches a malicious Brotli-compressed response and decompresses it. JFrog researchers also demonstrated an FFmpeg path through libjxl: a crafted JPEG XL image can carry Brotli-compressed metadata in brob boxes. Apache Arrow is also affected for denial-of-service attacks.

The practical impact depends on the consuming application’s behavior, not merely on whether a network perimeter accepts inbound compressed requests. Blocking Brotli requests at a reverse proxy may reduce one server-side path, but it does not stop a service from fetching and decoding a hostile compressed response. It also does not repair an already deployed runtime carrying a vulnerable decoder.

Fixed releases across the exposed stack

The affected upstream Brotli releases are 1.0.3 through 1.0.9, plus 1.1.0 and 1.2.0. Google’s fixed releases are 1.0.10, 1.1.1 and 1.2.1. Node.js published fixed versions 22.23.4, 24.22.1 and 26.12.1; Python Brotli is fixed in 1.2.1, while brotlicffi is fixed in 1.2.1.0.

Envoy shows why package-level inventory is insufficient. Its security advisory says the affected releases are vulnerable on all platforms only when the Brotli decompressor is configured. In that configuration, a remote unauthenticated attacker can corrupt adjacent decoder-state memory, disclose sensitive memory, deny service or potentially execute arbitrary code with a crafted stream.

Each supported Envoy branch requires a different target version: 1.36.11 must move to 1.36.12, while 1.39.2 must move to 1.39.3. Version 1.40.0 is the fixed current-line release. Microsoft, by contrast, says it has issued new .NET versions but the supplied reporting does not identify the individual patched .NET build numbers. Administrators cannot safely substitute a general “latest Brotli” update for the vendor-specific runtime release that ships the decoder.

Bun, Istio and Python projects have likewise published fixes. For Python HTTP clients, the exposure includes urllib3[brotli], requests, httpx and aiohttp[speedups] when configured with a vulnerable decoder. That helps with triage, but it is not a reason to defer patching: an optional decompression path becomes an attack surface when a workload enables it.

February source fix, October ecosystem release

The upstream code correction was committed in February 2026, but it was not recognized as a security vulnerability at the time and Brotli had no newer release. Stable fixes for Google Brotli and Node.js arrived on October 21, 2026; public disclosure followed on October 22, and patched Python packages became available on October 23. Microsoft’s .NET update followed on October 25.

“This root cause issue was actually fixed in the Brotli source code in February, but it wasn’t known at the time that it gave rise to a security vulnerability, and there was no more recent release of Brotli.”

A source-level correction does not help users until it becomes a released library. It also does not reach runtimes that bundle a copy or vendors that independently incorporate the code. Node.js deployments are specifically called out as a case where updating the system Brotli library may not change the decoder used by the application.

Rebuilds and restarts are part of the fix

For a fleet operator, the remediation unit is the running workload. Updating package manifests or a host library does not repair containers built with an old runtime, nor does it replace code already loaded into a process. Remediation requires updating the affected component, rebuilding container images, redeploying them and restarting affected services.

OpenAI’s Patch the Planet guidance recommends blocking untrusted Brotli-compressed data where feasible until patches are deployed. That is a temporary exposure-reduction measure, not a complete mitigation. It is incomplete for applications that initiate outbound requests and automatically decode Brotli responses, so eliminating only inbound traffic at a firewall or proxy leaves a path open.

Proof-of-concept exploits exist, and Imperva has reported remote-code-execution results for Node2Shell. Microsoft says it has no indication of successful criminal exploitation, but its “Exploitation More Likely” designation supports treating the patch as urgent rather than waiting for confirmed campaigns.

Cloud exposure makes inventory the hard part

Wiz estimates that 91% of cloud environments rely on components vulnerable to the Brotli flaw, and that 82% have publicly exposed Node.js instances. Those figures do not establish that every environment is exploitable: exposed software must still use a reachable vulnerable decompression path. They show why remediation may extend across containerized services, Kubernetes clusters, API gateways, reverse proxies, serverless workloads and cloud-hosted applications.

The immediate work is to identify where Brotli is embedded rather than merely installed. Inventory should distinguish system packages from bundled runtime copies, confirm whether Brotli decompression is enabled, and verify that rebuilt artifacts—not only development environments—contain fixed versions. A successful package-manager transaction without a fresh deployment is not evidence of remediation.

A familiar patching pattern, with a harder dependency chain

This incident follows a security-heavy 2026 patch cycle. In August, Microsoft addressed 400 vulnerabilities, including three zero-days, while Apple’s iOS 26.6.1 fixed more than 20 flaws across WebKit, image processing and memory-corruption components. We also documented Google’s claim that it found and fixed 1,072 Chrome security bugs in 60 days.

Brotli differs from a browser or operating-system update because vulnerable code can remain inside application runtimes, proxies and images after a host package has been upgraded. The key question for engineering teams is not “have we patched Brotli?” but “which decoder does each production process actually execute?” Until teams can answer that from deployed artifacts and running versions, CVE-2026-111497 remains a deployment problem rather than a completed package update.