Node2Shell CVE-2026-111497: Out-of-Bounds Write in Node.js Brotli Decoder

What Happened

CVE-2026-111497 is an out-of-bounds write in Google’s Brotli decoder. A carefully crafted compressed stream can corrupt memory inside the decoder and, in some cases, lead to remote code execution.

Node.js became the most visible victim because it automatically decompresses Content-Encoding: br in fetch() and in popular middleware such as Express body-parser. The bug itself is not in Node.js. It lives in the native C decoder that many runtimes and packages bundle.

What Is a Sensitive Library?

A Sensitive Library is a library that handles untrusted input in a way that can affect the security of the process. Typical examples include parsers, decoders, deserializers, and native code that processes data coming from the network or from users.

Raven classifies libraries into families. Brotli falls into two of them:

• Customs Officer — it parses and decodes untrusted input.
• Smuggler — it is native C code that crosses the boundary from a managed language into memory-unsafe code.

Raven knows in advance that libraries like this are sensitive. It does not wait for a CVE. It treats them as higher-risk by default.

Why Brotli Is a Sensitive Library

Brotli is a compression library written in C. Its only job is to turn compressed bytes into uncompressed bytes (and the other way around). It is widely embedded because many languages and runtimes simply compile the same Google C source into their own binaries or native extensions.

After reviewing the source code of the decoder (c/dec/decode.c), two things are clear:

• The library never calls system(), exec(), popen(), or any other function that runs external code.
• Its entire purpose is data transformation. It has no legitimate need to execute code or spawn processes.

How the Bug Works

In the vulnerable versions, the function DecodeBlockTypeAndLength returned a generic failure when the compressed stream asked for a block-type switch that the metadata had declared impossible. On the fast decoding path, that failure was ignored. The decoder continued with stale internal state and eventually wrote past the end of an internal buffer.

That is the entire bug: an invalid compressed input caused the decoder to keep going when it should have stopped, and the continued execution produced an out-of-bounds write.

How Runtime Prevention Stops It

Because the Brotli decoder is already treated as a Sensitive Library, a simple preventive policy can be applied in advance:

This library is not allowed to trigger process creation or command execution.

Normal decompression never needs those capabilities, so the policy does not break legitimate use. If an attacker succeeds in turning the memory corruption into code execution, the first thing that code usually tries to do is spawn a process or run a command. The syscall is attributed to the Sensitive Library’s call stack and blocked.

This is prevention, not just detection. The policy can be in place before any CVE is published, because the library was already classified as sensitive.

The Real Scale

The same vulnerable decoder is bundled in hundreds of packages across more than a dozen languages. Updating Node.js closes only the Node.js path. Every other copy of the C decoder still needs its own update. Until that happens, a runtime policy that understands which library is on the stack remains effective.

Summary

Brotli is a Sensitive Library because it is native code that decodes untrusted input.

It has no legitimate need to execute code.

A runtime policy can block code execution from it before any exploit succeeds.

That is how knowledge of a library’s role turns into concrete prevention, even when the underlying bug is still present.

Raven ADR Runtime Prevention

Raven ADR (Application Detection and Response) runs inside the application and sees execution down to the library and function level. Runtime Prevention is the enforcement capability that can stop sensitive actions (such as process creation) when they originate from a library that should not perform them. No code changes and no signatures are required. The policy can be applied the moment the library is classified as sensitive — before a CVE even exists.