A security flaw first presented as a Node.js problem now requires a much wider software inventory. CVE-2026-111497 is an out-of-bounds write in Google’s Brotli decoder, the native code used to unpack br-compressed data. In the days since Node.js disclosed the issue on October 21, maintainers have confirmed affected copies in Python packages, Java bindings, Linux distributions and Microsoft’s .NET runtime.
Microsoft released out-of-band .NET updates on October 25. The PyPA advisory database lists the Python Brotli package through 1.2.0 as vulnerable. Debian issued DSA-6582-1, while Java projects that bundle the decoder have begun publishing their own fixes.
The expansion matters because updating the operating system’s libbrotli package does not necessarily repair a copy compiled into Node.js, installed in a Python virtual environment or shipped inside a Java native JAR. Teams need to find the decoder by delivery path, then test whether untrusted data can reach it.
What HTTP2Shell actually affects
The flaw sits in the C decoder’s handling of an invalid block switch. According to the Node.js security advisory, the decoder can mistake a permanent format error for a temporary request for more input. Streaming decompression then continues writing bytes past an internal eight-byte buffer.
A crafted Brotli stream can corrupt process memory. The documented outcomes range from a crash and memory disclosure to remote code execution. GitHub’s advisory assigns a CVSS 4.0 score of 9.2, although Node.js rates its own exposure High rather than Critical because an application must decompress attacker-controlled Brotli data.
That condition can occur in two directions:
- A public service accepts a request body marked
Content-Encoding: brand decompresses it. - An application, worker or crawler automatically decodes a Brotli response returned by an attacker-controlled or compromised server.
- A document, archive or other untrusted file embeds Brotli-compressed data that an application opens.
Serving Brotli-compressed responses is not, by itself, the dangerous operation. Encoding data uses a different path. The urgent question is where a process decodes data it does not control.
Fixed versions confirmed so far
Start with the runtime or package that owns each decoder copy. The following fixes are documented by the maintainers as of October 25:
- Google Brotli: update to 1.0.10, 1.1.1 or 1.2.1, depending on the maintained branch. Versions 1.0.3 through 1.2.0 are covered by the CVE.
- Node.js: update supported lines to 22.23.4, 24.22.1 or 26.12.1. Node 20 and older lines are already outside normal support and should be migrated, not treated as safely frozen.
- Python: update the PyPI
Brotlipackage to 1.2.1 or later. The PyPA record identifies every release through 1.2.0 as affected. - .NET: install Microsoft’s October 25 out-of-band runtime and servicing updates for supported .NET releases. Microsoft identifies ASP.NET Core request decompression,
HttpClientautomatic response decompression andSystem.IO.CompressionBrotli APIs as possible entry points. - Brotli4j: update the Java library and all platform-specific
native-*artifacts to 1.24.0 or later. The project’s advisory warns that patching the host library does not replace the vulnerable native decoder inside older JARs. - Linux packages: use the fixed package supplied by the distribution rather than comparing only upstream version strings. Vendors may backport the patch without adopting Brotli 1.2.1.
This is not a complete product list. Envoy-based gateways, language extensions, desktop applications, firmware utilities and container images can vendor the same C source. A software composition tool that reports only direct application dependencies may therefore miss the copy that matters.
How to find vulnerable Brotli copies
1. Inventory runtimes before libraries
Collect the Node.js and .NET runtime versions used by production services, build agents, serverless functions, scheduled jobs and container base images. Do not rely on the version installed on an administrator’s laptop. Inspect version pins in Dockerfiles, CI workflows, deployment manifests, .nvmrc, .node-version, global.json and infrastructure-as-code repositories.
For Node.js, run node --version inside the deployed container or host process environment. A rebuilt image is required if the runtime is baked into the image; updating the host package will not alter that layer.
2. Search every Python environment
Python’s exposure is easy to overlook because Brotli support is often an optional extra. HTTP clients such as urllib3, Requests, HTTPX and aiohttp can automatically decode Brotli responses when a compatible package is present.
Run python -m pip show Brotli brotlicffi in each production virtual environment, image and function bundle. Then inspect lock files, constraints files and generated dependency reports. A clean global Python installation says nothing about an application-specific virtual environment.
Use python -m pip check after the upgrade, rebuild wheels for the target platform and rerun network-client tests. Native wheels compiled for a different CPU or Linux base can fail only after deployment.
3. Inspect Java native artifacts
For Java services, search dependency trees and fat JARs for Brotli4j and its native platform modules. Maven users can begin with mvn dependency:tree; Gradle users can use the project’s dependency reports. Update both the Java API artifact and matching native JARs. An application can appear to use a memory-safe language while JNI loads the vulnerable C decoder into the same process.
4. Scan files, containers and SBOMs
Search software bills of materials for package names and CPEs associated with Brotli, but supplement that with file and symbol discovery. Useful indicators include libraries named libbrotlidec, native modules containing Brotli decoder symbols, Python wheel metadata and JARs with packaged native libraries.
Scan stopped and running container images, not just hosts. Also check CI caches and artifact repositories so the next build does not quietly restore a vulnerable wheel, runtime tarball or base layer.
5. Map reachability, not just presence
Prioritize internet-facing services that accept compressed request bodies, automated crawlers and webhook processors, URL-preview services, document converters, proxy layers and clients that fetch from user-supplied URLs. An installed decoder with no untrusted input path is lower priority than a public endpoint that inflates request bodies before authentication.
Preserve that distinction in vulnerability tickets. “Package present” and “remotely reachable” are different findings, and teams need both to set an honest remediation order.
Temporary controls while updates roll out
The durable fix is to replace every vulnerable decoder. Where an update cannot be deployed immediately, disable Brotli decompression for untrusted inputs. At a reverse proxy or API gateway, reject request bodies with Content-Encoding: br before they reach the application. For outbound clients, remove Brotli from the accepted encodings or disable automatic decompression where the library provides that control.
These are narrow mitigations. They do not protect a desktop utility opening a crafted file, a background client fetching a hostile response through another code path or a bundled decoder used outside HTTP. A web-application firewall may reduce exposure to public endpoints, but it cannot repair memory corruption inside downstream software.
Restart patched processes and replace immutable containers after upgrading. A new library on disk does not change a decoder already mapped into a long-running process.
What defenders should monitor
There is public research demonstrating crashes and constrained code execution in laboratory configurations, including Imperva’s Node.js analysis. That does not mean every affected service is straightforward to exploit. Memory layout, runtime hardening and the exact decompression path all influence reliability; Red Hat notes that ASLR, NX, FORTIFY_SOURCE and SELinux raise the difficulty of turning corruption into dependable execution.
Until inventories and patches are complete, alert on unexplained crashes in services that decode Brotli, repeated malformed compressed requests, sudden worker restarts, core dumps and new child processes spawned by network-facing runtimes. Retain reverse-proxy request metadata, container restart history and endpoint telemetry. Avoid sending public proof-of-concept payloads into production merely to determine whether a server is vulnerable; version and artifact verification are safer and more conclusive.
No authoritative source reviewed for this article had confirmed broad in-the-wild exploitation by October 25. The combination of public technical detail, multi-runtime reach and inconsistent packaging still argues for fast action. The operational mistake would be to close the ticket after updating Node.js while an older decoder remains in a Python wheel, .NET runtime, Java JAR or container layer.
A practical remediation order
- Patch public services and clients that decompress attacker-controlled Brotli data.
- Update Node.js, Python, .NET, Java and distribution packages through their own supported channels.
- Rebuild containers and deployment bundles from clean, updated base artifacts.
- Rescan binaries and images for bundled copies that the host package manager cannot see.
- Restart workloads, test decompression paths and confirm the deployed version rather than the build manifest alone.
- Keep temporary request and response controls until the full inventory is clean.
CVE-2026-111497 is a good test of whether an organization can trace native code through modern software stacks. Brotli may appear as a small compression feature, but its decoder can travel inside runtimes, wheels, JARs, containers and applications. The patch is available; finding every copy is the harder job.
