Brotli CVE-2026-111497: Memory Corruption, Information Disclosure, and RCE via Crafted Compressed Streams

1. Basic Information

• Article Name: Wednesday, October 21, 2026 Security Releases
• Source: Node.js project
• Published Date: October 21, 2026
• Original Source: Node.js project
• Related Information Sources: GitHub Advisory: Python Brotli / brotlicffi, Istio Brotli Requirements, Envoy Brotli Advisory, BleepingComputer, JPCERT/CC, Microsoft .NET Advisory, Imperva, OpenAI
• Related Malware, Threat Groups, CVEs, Products: CVE-2026-111497, Google Brotli, Node.js, .NET, Python Brotli, Bun, Envoy, Istio
• Severity: High

2. Executive Summary

The Brotli stream decoder incorrectly treats invalid block switching as a request for additional input rather than a permanent error, writing data beyond the 8-byte internal buffer. Decompressing attacker-controlled Brotli data can cause process crashes or disclose process memory, and may allow remote code execution (RCE) when additional conditions are met. Public proofs of concept and research demonstrations exist, but the reviewed public sources do not report malicious exploitation in the wild.

3. Attack Flow

The following are separate paths leading to the same decoder vulnerability. Sending requests to a server and retrieving responses as a client are independent attack vectors and do not form a single mandatory sequence of steps.

Server Decompression of Compressed Requests

1. An attacker sends a crafted Brotli stream as an HTTP request or API input.
2. An application or runtime decompresses the data using the vulnerable decoder.
3. Writing to the internal buffer continues even after invalid block switching, causing an out-of-bounds write.
4. This leads to process crashes, memory information disclosure, and, when memory layout and protection mechanism conditions are met, remote code execution (RCE) under the process privileges.

Client Decompression of Compressed Responses

1. An attacker induces a backend client, crawler, proxy, AI agent, or similar entity to retrieve an attacker-controlled URL.
2. The client receives a response marked with Content-Encoding: br and automatically decompresses it.
3. The same decoder flaw is triggered inside the client process, potentially leading to crashes, memory information disclosure, and code execution if additional conditions are met.

The following table organizes the attack vectors and investigation perspectives. RCE, subsequent child processes, and outbound communications do not occur in all environments.

Running an HTTP server on a vulnerable Node.js runtime does not, by itself, cause received bodies to be decompressed with Brotli. A configured request parser or another component must actually decompress the input. Imperva demonstrated RCE on Node.js 24.22.0 (Linux arm64) through both the built-in fetch() response-decompression path and the request-decompression path in a configured Express/body-parser application. The same input was rejected by patched version 24.22.1. These results do not establish successful exploitation on untested builds or architectures.

This vulnerability is not specific to HTTP/2. Although nicknames such as "HTTP2Shell," "Node2Shell," and "Broccoli2Shell" exist, the fundamental attack condition is a vulnerable Brotli decoder decompressing data controlled by an attacker.

4. Attacker Position and Execution Location

For the server-side vector, the prerequisite is the ability to send compressed requests from the internet or an internal network. For the client-side vector, the requirement is the ability to cause the target to retrieve and decompress an attacker-controlled response. Memory corruption itself occurs inside processes such as Node.js, .NET, Python, or reverse proxies that invoke the Brotli library.

5. Visibility for Victims and Administrators

• Victims: May perceive the issue as service unresponsiveness, connection drops, or 5xx errors.
• Administrators: May detect decoder process segmentation faults (segfaults), core dumps, unexpected process restarts, or suspicious child process creation and external communications immediately following HTTP request processing.

6. Success and Failure Conditions

Success Conditions

• The vulnerable Brotli decoder binary is incorporated into the running process.
• In .NET environments, this applies to Brotli-enabled request decompression, HttpClient automatic response decompression, or explicit use of BrotliStream / BrotliDecoder. Default configurations of ASP.NET Core and HttpClient do not automatically decompress, and .NET Framework is not affected. Envoy and Istio are also affected when the Brotli decompressor is explicitly enabled.
• The target process actually performs decompression processing on attacker-controlled Brotli data.
• Whether RCE succeeds also depends on the target version, CPU architecture, memory layout, and OS mitigations such as ASLR.

Failure Conditions and Mitigations

• Update to patched versions provided by respective vendors, such as Google Brotli (1.0.10, 1.1.1, 1.2.1) or Node.js (22.23.4, 24.22.1, 26.12.1).
• Until patching is complete, disable or exclude Brotli request and response decompression processing enabled in existing environments. Microsoft advises against enabling previously unused decompression features as part of a mitigation.
• Reject Brotli before decompression, following OpenAI's guidance. Simply removing br from Accept-Encoding or stopping outbound compression on CDNs or web servers does not protect incoming request or client-side response decompression paths. Even if decompression is stopped in Envoy or Istio, compressed data may flow to backend components, so remaining vulnerable decoders must also be protected.
• After updating, restart related processes and ensure container images are rebuilt and redeployed. Updating only the operating system's Brotli library may leave vulnerable runtime-bundled copies unchanged.

7. What Happens Upon Success

Successful exploitation can crash the decoder process (DoS), disclose process memory, or, when additional conditions are met, execute code with the process's privileges. In .NET environments, this may lead to privilege escalation depending on the application configuration and execution context.

8. Observable Logs

The following are investigation ideas (Inference). Available logs vary by product and configuration and do not represent confirmed IOCs observed in active exploitation environments. Normal Content-Encoding: br traffic or data lengths alone cannot be used to conclusively determine an attack.

• Email: No email-initiated attack activities specific to this vulnerability have been reported.
• Proxy / SWG / DNS: Content-Encoding: br traffic, abnormal responses, and communication histories to backend fetch destinations.
• Endpoint / EDR: Segfaults in Node.js, dotnet, Python, or proxies, core dumps, abnormal child process launches, and unexpected allocations of executable memory regions.
• Identity / IdP: The reviewed sources do not report authentication IOCs specific to this vulnerability. Investigate possible service account abuse following successful RCE separately.
• SaaS / Cloud: Container restarts, Pod CrashLoopBackOff states, spikes in load balancer 5xx errors, and differences in deployed image digests.
• Network: Brotli streams chronologically matching decoder errors, repetitive communications from the same source, and request-response flows immediately preceding crashes.

9. Attack Success Determination

If the only evidence is the arrival of crafted Brotli data or traffic matching a PoC fingerprint, classify it as an attack attempt. The occurrence of decoder errors or process crashes indicates potential memory corruption but does not immediately signify successful RCE. Confirm initial execution only when there is execution evidence, such as suspicious child processes launched by the decoder process, process telemetry matching attacker commands, or equivalent evidence. Imperva's RCE results were obtained in a research environment using Node.js 24.22.0 (Linux arm64) and specific test configurations; they do not establish reliable reproduction across all environments.

10. Investigation Playbook

1. Trigger: Crashes or segfaults in processes that decompress Brotli data, core dumps, detected PoC fingerprints, or suspicious child processes.
2. Initial Verification: Verify incorporated decoder copies, runtime and package versions, request/response decompression settings, and process restart times.
3. Endpoint Investigation: Preserve and investigate process trees before and after crashes, core dumps, memory faults, launched shells, download tools, and file modification histories.
4. Authentication & Cloud: Check service account and Workload Identity usage history, secret access logs, and cloud API operation logs.
5. Post-Exploitation Tracking: Track traces of credential access, persistence configurations, lateral movement, and data exfiltration.
6. Containment: Temporarily halt suspicious Brotli decompression processing, update to vendor-patched versions, restart processes, and rebuild container images.
7. Judgment Categories: Evaluate distinctly across stages including reachability, decoder errors, crashes, memory information disclosure, RCE, and subsequent compromises.

11. Defense and Detection Ideas

• Single Event: Alerts for segfault occurrences in Brotli decompression processes coupled with preceding br encoding communications.
• Chronological Correlation: Perform correlation analysis from receiving crafted compressed streams -> decoder errors or process crashes -> process restarts -> generation of suspicious child processes and outbound communications.
• Proactive Threat Hunting: Cross-search SBOMs, container image layers, binary dependencies, and runtime-bundled modules to comprehensively identify vulnerable Brotli copies.
• Logging Considerations: Identifying causal relationships becomes difficult if TLS-terminated plaintext payloads, client-side response headers, and process crash telemetry are not preserved.
• Priority Controls: Prioritize applying vendor-patched versions, restarting processes, rebuilding and redeploying containers, and disabling unnecessary automatic Brotli decompression features.

12. Facts / Inference / Hypothesis

Facts

• The Node.js project explained the out-of-bounds write mechanism against the 8-byte internal buffer in Brotli and released patched versions.
• JPCERT/CC provided guidance on affected versions of Google Brotli and the scope of impact on widespread embedded products.
• Imperva demonstrated RCE under specific conditions in a research environment running Node.js 24.22.0 (Linux arm64).
• The reviewed public sources do not report malicious exploitation in the wild.

Inference

• Not only web servers, but also backend clients and crawlers that retrieve data from external URLs and decompress Brotli responses serve as critical attack surfaces.
• In asset management, it is necessary to track not only direct package dependencies but also container images, vendor-embedded libraries, and statically linked binaries.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Uncertainties and Additional Investigation."

13. MITRE ATT&CK Mapping

14. Uncertainties and Additional Investigation

• The presence of active exploitation by malicious actors, patch availability status across all embedded products, and detailed RCE success conditions per product and architecture remain unconfirmed. The existence of public PoCs cannot be treated as confirmation of production environment compromise.

15. Impact on SOCs and Organizations

Even for organizations that do not directly develop or operate Node.js or .NET internally, API clients, service meshes, proxies, Python packages, and container images bundling the Brotli library may be affected. Create software inventories from both public web services and batch processing tasks retrieving external URLs, and verify patch application and process restarts for each embedded copy.

16. Summary by Target Audience

• For SOCs: Monitor process crashes, suspicious child process launches, and outbound communications occurring immediately after Brotli decompression processing by correlating them chronologically with request and response traffic.
• For Administrators: Promptly apply patched versions provided by product vendors, and ensure process restarts and container image rebuilds/redeployments are fully completed.
• For Users: Follow update guidance and restart procedures provided by service administrators.