A compressed response can look like harmless plumbing. The risk appears when a vulnerable decoder mistakes malformed block-switch data for an incomplete stream and writes past a fixed-size internal buffer.
At a glance: what HTTP/2Shell is, and isn’t
- The flaw: CVE-2026-111497 is a memory-safety bug in the Brotli decoder, also called HTTP/2Shell, Node2Shell, or Brotli2Shell.
- The trigger: A vulnerable decoder must process a crafted Brotli stream. Merely supporting HTTP/2, or compressing outgoing responses with Brotli, does not by itself prove exposure.
- The impact: Depending on the application and execution path, an out-of-bounds write can crash or corrupt a process, expose memory, or potentially enable remote code execution. Researchers demonstrated RCE on a vulnerable Node.js build.
- The urgency: CISA added the CVE to its Known Exploited Vulnerabilities catalog on October 27, indicating known exploitation. Public reporting does not establish the scale of successful compromises.
What actually breaks inside the decoder
Brotli can decode data incrementally. A streaming decoder has to tell the difference between “the stream is malformed” and “I need more bytes before I can continue.” In the vulnerable code, an invalid block switch could be treated as the second case. The decoder then kept appending data to an internal buffer intended to be only eight bytes long, writing beyond its boundary. The upstream fix corrects that error handling so invalid input is rejected instead of mistaken for incomplete input.
An out-of-bounds write is a memory-corruption primitive, not automatic code execution. The outcome depends on the process, build, memory layout, and available mitigations. In the wrong circumstances, it can become more than a crash. The Node.js RCE demonstration shows that code execution is possible in at least one vulnerable environment, not that every affected service is equally exploitable.
Where exposure can hide
The name is a little misleading. This is not a flaw in the HTTP/2 protocol. The common factor is the vulnerable Brotli decoder, wherever it is embedded and wherever it processes attacker-controlled compressed data.
That can include a server decoding compressed request data, a client decoding a response from an untrusted source, a proxy or service mesh, or software that processes compressed files. A service that only uses Brotli to compress outbound responses is not necessarily exposed through that function, but check whether the same runtime or library also decodes data elsewhere.
Upstream Brotli versions 1.0.3–1.0.9, 1.1.0, and 1.2.0 are affected. Fixed upstream releases include 1.0.10, 1.1.1, and 1.2.1. Downstream packages can carry their own code and release schedules. For example, Node.js lists fixes in 22.23.4, 24.22.1, and 26.12.1. Check each vendor advisory rather than assuming an operating-system package update fixes a bundled copy.
What to do now
- Inventory runtimes, packages, containers, and self-contained applications that include Brotli. Search dependency and software-bill-of-materials data, then check which ones decode untrusted input.
- Patch the decoder or the affected downstream runtime using its vendor’s fixed release. Review the Node.js advisory and guidance for .NET, Envoy, and Istio.
- Rebuild and redeploy affected containers and self-contained applications, then restart the processes. A patched host library may not replace a copy statically linked or bundled into an application.
- Until the patch is deployed, disable Brotli decoding on paths that process untrusted input if you can do so safely. Blocking incoming
Content-Encoding: brcan reduce one server-side path, but it does not protect clients decoding hostile responses or tools processing compressed files.
One easy trap: disabling Brotli compression, or removing br from a client’s Accept-Encoding header, does not reliably disable Brotli decoding. Verify the code path that receives and decodes data, not just the setting that controls what your service sends.
If you’re not sure where your organization decodes untrusted compressed data, start with the software inventory and dependency graph. That turns a vague alert into a concrete patch list.
Book a 15-minute exposure review
We’ll help identify likely exposure paths and practical next steps, with no obligation.