Node2Shell exploit shows Node.js RCE risk on standard build

Node.js users have a serious reason to update: researchers have demonstrated remote code execution through a flaw in the runtime’s bundled Brotli decoder, using crafted compressed data against a standard official build.¹²

The vulnerability, tracked as CVE-2026-111497, affects the Node.js 22.x, 24.x and 26.x release lines. The Node.js project included a fix in its October 21 security releases, while Imperva’s research shows how the bug could be pushed beyond a crash or limited memory read into attacker-controlled code execution on a normal Node.js 24.22.0 Linux arm64 image.¹²

What the demonstration shows

Imperva’s proof of concept, dubbed Node2Shell, targets the Brotli decoder that Node.js uses when applications handle compressed data. The researchers reached the vulnerable code through both sides of an HTTP exchange: an Express application processing a Brotli-compressed request body, and a Node.js process fetching a Brotli-compressed response.²

The result was not an instant, universal exploit. Imperva said the test took several attempts in its Linux arm64 setup and covered one specific build and application arrangement. It did not test every release between the pinned Express and body-parser versions, nor did it establish that every supported architecture is exploitable in the same way.²

That distinction matters, but it does not make the issue theoretical. The earlier public proof of concept only achieved code execution on a deliberately weakened build; Node2Shell demonstrates the more consequential result on an official Node.js image without a debugger or custom compilation.²

Who needs to act

The affected decoder sits inside Node.js, so the exposure is not limited to one framework. Applications can reach it through built-in fetch handling compressed responses, or through middleware that decodes compressed request bodies. Express 5’s body parsers support Brotli alongside gzip and deflate, making inventorying those routes particularly important.²

The Node.js advisory lists no runtime workaround that removes the vulnerability. The practical fix is to move to a patched release: Node.js 24.22.1 rejects the crafted data, and the October security release covers the supported 22.x, 24.x and 26.x lines.¹² Teams should also check container images and bundled binaries rather than relying only on a package-manager inventory. End-of-life Node.js lines do not receive the security fix.¹

Where an immediate update is impossible, Imperva suggested limiting untrusted Brotli traffic on affected paths where that can be done safely. That is a temporary risk reduction, not a replacement for patching. Vercel said it added rules for inbound requests on October 21, but those rules do not cover Brotli responses fetched by an application and do not remove the need to update.²

Our opinion

Node2Shell is a useful warning because it turns a familiar security habit—“keep the runtime patched”—into a concrete deployment check. The strongest part of the research is not the dramatic name or the shell-shaped branding; it is the demonstration that a standard build can cross the line from malformed input to code execution. The caveats are equally important: this is not evidence that every Node.js service is remotely exploitable today, and no exploitation in the wild had been reported as of October 22.²

For teams running Node.js in production, the sensible response is straightforward rather than theatrical: identify every supported runtime and container image, apply the fixed release, then review which endpoints accept or fetch untrusted Brotli data. If an update has to wait, narrow that exposure while treating the delay as technical debt. The patch is the durable answer.