Node2Shell (CVE-2026-111497): The Eight-Byte Bug Behind a Node.js RCE

Your dependency scanner says everything is fine. Your packages are up to date, your security checks are passing, and there's nothing obvious to fix. 

Then someone sends your application a compressed HTTP request.

The application attempts to decompress it, encounters a malformed instruction and writes data beyond a buffer in memory. Depending on how the flaw is exploited, the result could be a crashed service, leaked information or an attacker executing code on the server.

That’s the problem behind Node2Shell (CVE-2026-111497), a vulnerability in the Brotli decompression library bundled with Node.js. 

The unusual part is how little an application needs to do to encounter the problem. Some frameworks automatically decompress incoming requests, and Node.js can also decompress responses received from other servers.

An application doesn’t need to contain a deliberately vulnerable upload feature to be exposed.

So how did a feature designed to make web traffic smaller become a route to compromising an application? And why wouldn’t updating your npm dependencies necessarily help?

Let’s break it down.

What Is Node2Shell?

Node2Shell is the name given to CVE-2026-111497, a memory corruption vulnerability affecting Google's Brotli decoder.

The vulnerability received a CVSS v4.0 score of 9.2 (Critical), although the Node.js project classifies it as High severity in its own security advisory.

The flaw allows specially crafted Brotli-compressed data to trigger an out-of-bounds write, classified as CWE-787.

An out-of-bounds write happens when a program writes information outside the memory area allocated for it. This can corrupt nearby data, crash the application or create conditions an attacker can exploit.

For Node2Shell, the possible consequences include denial of service, exposure of process memory and remote code execution.

How Does a Compressed Upload Become a Security Vulnerability?

To understand the attack, you first need to understand Brotli.

Websites use Brotli to compress content such as HTML, CSS and JavaScript. Applications can also use it for other types of data. When a server sends Brotli-compressed content, it can identify the encoding through an HTTP header:

This tells the receiving application that the content needs to be decompressed before it can be used.

A decoder handles that process. It reads the compressed information, interprets the instructions within it and reconstructs the original data. Normally, that happens without anyone noticing.

Node2Shell exploits what happens when the decoder encounters a malformed instruction.

The Error That the Decoder Misunderstood

Brotli streams contain information describing how compressed blocks should be interpreted. As the decoder processes a stream, it may need to switch between block types.

In the vulnerable implementation, a particular invalid block switch was treated as though the decoder simply needed more input.

Those are two very different conditions: 

• If a decoder needs more input, it should wait for additional data and continue processing.
• If the compressed stream contains an invalid instruction, the decoder should reject it.

With Node2Shell, the decoder could confuse the two. Instead of stopping, it continued copying data into an internal buffer designed to hold just eight bytes. Eventually, the decoder could write beyond that buffer and corrupt adjacent memory.

That's the memory-safety failure at the centre of CVE-2026-111497.

Why Memory Corruption Can Become RCE

An out-of-bounds write doesn't automatically mean an attacker has complete control of a server. The initial effect may be a crash or damage to the application's internal state.

But if an attacker can influence what gets overwritten, they may be able to manipulate how the program behaves.

For example, corrupting information used to track memory locations can potentially make the application read from or write to places it shouldn't. Researchers can sometimes build on those behaviours to achieve code execution. That's what makes Node2Shell more serious than an ordinary decompression error. 

How Can an Attacker Reach the Vulnerable Decoder?

An application becomes exposed when attacker-controlled Brotli data reaches the vulnerable decoder.

Here are two ways that can happen:

Through Incoming HTTP Requests

Consider an API built with Express 5, a popular Node.js web framework. Express applications commonly use middleware to process request bodies.

Express 5 and body-parser 2.x can automatically decompress Brotli-compressed request bodies when their relevant parsers are enabled with their default inflation behaviour.

An attacker who can send compressed data to such an endpoint may therefore reach the vulnerable decoder without the application explicitly calling a Brotli function. If the parser runs before authentication, the attacker may not need an account.

That's why the request-handling configuration matters more than simply knowing that the application uses Express.

A bare Node.js HTTP server does not automatically decompress every incoming Brotli request. The vulnerable component must actually be used.

Through Compressed Responses From Other Servers

Node.js applications sometimes retrieve information from external websites or services using APIs such as fetch().

For example, an application might generate previews of submitted URLs or retrieve information from third-party services.

Node.js can automatically decompress responses labelled with Content-Encoding: br.

If an attacker controls a response that the application retrieves, they may be able to supply malformed compressed content through that route.

This means the attack surface can exist in an application that consumes external information, even when it doesn't accept compressed uploads from users. In both cases, the vulnerable component is the decoder bundled with the runtime.

Why npm Audit Won't Catch Node2Shell

You can scan your dependencies, receive a clean result and still be running a vulnerable Node.js version.

The npm audit command checks dependencies in your npm package tree against known vulnerability information. It's useful for identifying security problems in packages your project depends on. But Node2Shell involves the Brotli decoder included in the Node.js runtime itself.

Updating Express, body-parser or unrelated dependencies does not replace the vulnerable decoder inside an outdated Node.js binary.

That also explains why the issue can appear across different applications sharing the same runtime. The practical fix is to update Node.js to a corrected release, or apply an appropriate vendor-provided update where the runtime is supplied through another platform.

Which Node.js Versions Are Affected?

The Node.js project released fixes on 21 October 2026 for all three supported release lines.

Applications running an older release within one of these supported lines should be updated to the relevant fixed version or newer.

The official October 2026 Node.js security release provides the corrected versions and other vulnerabilities addressed by the same update. 

How Can Defenders Detect Node2Shell Activity?

Detection is particularly challenging because the malicious behaviour occurs inside the decompression process.

A request may appear ordinary until the application begins interpreting the compressed content. Investigators should look for several related signals.

• Repeated application crashes: An unexpected increase in Node.js worker exits or restarts may indicate attempts to trigger memory corruption, particularly when correlated with Brotli-encoded requests.
• Unusual decoder errors: Malformed Brotli streams may generate decompression errors. These are useful leads, although benign truncated or corrupted traffic can produce similar results.
• Unexpected process activity: A Node.js application launching an unfamiliar shell or making unexplained outbound connections deserves investigation, especially when it follows suspicious request processing.
• Unusual resource consumption: Some malformed streams can produce excessive CPU usage or tie up decompression workers without immediately crashing the service.

What Node2Shell Tells Us About the Next Wave of Vulnerabilities

Less than two weeks separated the PHP2Shell disclosures and the growing Node2Shell story. The two vulnerabilities affect different technologies and have different root causes, but they expose a similar problem.

Developers spend considerable time securing their application code and dependencies. Yet applications also rely on runtimes, native libraries and internal processing components that users rarely interact with directly.

Those components handle ordinary activities such as allocating memory, processing requests and decompressing data.

When they contain security flaws, attackers may be able to reach them through legitimate application functionality.

Node2Shell is a particularly useful example because the vulnerability can be reached through everyday HTTP processing, and the consequences depend on what happens inside a decoder most JavaScript developers never need to examine. 

Practice Node2Shell on TryHackMe

TryHackMe’s Node2Shell (CVE-2026-111497) is a recent Threat room that takes you through the vulnerability in a controlled environment.

The room was developed to examine the underlying flaw and connect exploitation evidence to defensive investigation. 

Across five tasks, you’ll explore how Brotli decompression works, what goes wrong when the decoder misinterprets malformed input and how an affected Node.js application can be identified.

You’ll investigate how the memory-protection challenge affects exploitation, examine the results and distinguish an application crash from successful code execution in the lab.

The learning objectives include recognising suspicious crash patterns, developing Sigma or SIEM detections and understanding when a runtime needs to be patched or replaced.