Node2Shell enables code execution in standard Node.js build
Node2Shell, a Node.js vulnerability in the bundled Brotli decoder, can turn malicious compressed data into attacker-supplied code inside an application, according to a demonstration by Imperva researchers. Node.js is software used to run JavaScript outside a web browser, including in web applications and services. Brotli is a format for compressing data. The flaw, tracked under the Common Vulnerabilities and Exposures (CVE) identifier CVE-2026-111497, can result in remote code execution (RCE), meaning an attacker can make the affected application run commands or software of the attacker's choosing.
Imperva achieved code execution on the official Node.js 24.22.0 image for Linux arm64, the 64-bit ARM processor architecture. The test used an ordinary release rather than a specially weakened build, and it did not rely on a debugger, a tool for examining a running program. However, the result was not reliable on every attempt. Imperva needed several tries in its Linux arm64 environment before the supplied code ran. The researchers did not test other processor architectures or the Node.js 22.x and 26.x release lines, so the demonstrated result is limited to that build and application setup.
Node.js disclosed the vulnerability and issued fixes on October 21. When Imperva repeated the test against fixed release 24.22.1, the runtime rejected the crafted data and did not execute the supplied code. No exploitation in real attacks had been reported as of October 22. That absence of reported abuse does not remove the need to update applications that process Brotli data from untrusted sources.
The Node2Shell demonstration goes further than the first publicly available proof of concept, which is test code intended to show whether a vulnerability can be triggered. That earlier work reached code execution only on a deliberately weakened test build. Its author reported that the same approach caused a crash and exposed a limited amount of process memory on a normal build, but did not produce working code execution there. Imperva's result shows that exploitation was possible on one official, standard Node.js build, although its inconsistent success and narrow test scope remain important limitations.
The underlying decoder is included in Node.js 22.x, 24.x and 26.x, so exposure is not confined to the exact version Imperva used. An application can reach the vulnerable decoder from either direction of a Hypertext Transfer Protocol (HTTP) exchange, the request-and-response system used by websites and web services. One route is the built-in fetch() function reading a Brotli-compressed response from another server. The other is middleware, software placed between an incoming request and the application, decoding a Brotli-compressed request body.
Express 5 body parsers, including express.json(), express.urlencoded(), express.text() and express.raw(), can decode Brotli request bodies when they are enabled for a route. They also support gzip and deflate compression. Simply receiving a Brotli-compressed request with a basic Node.js HTTP server is not enough to invoke the affected code. The application must use suitable decoding middleware or call the decoder directly.
Imperva reproduced code execution through both the incoming request-body path and the outgoing response path. Its tests used pinned, specifically selected versions of Express from 5.0.0 to 5.3.0 and body-parser from 2.0.0 to 2.3.0. The researchers did not test every release between those endpoints, so the results should not be read as a version-by-version assessment of those packages.
The defect appears when the Brotli stream reaches a block change that should be impossible under the structure already declared by that same stream. Instead of treating the data as invalid, the vulnerable decoder interpreted the condition as a request for more input and continued processing in an invalid state. In a separate test using a memory sanitizer, a diagnostic tool that detects unsafe memory access, Imperva observed an out-of-bounds write. This means the decoder wrote data beyond the memory area intended to hold it. Node.js addressed the issue by importing an upstream Brotli change that stops decoding and returns a format error at that point.
The primary response is to install a patched Node.js release. Administrators also need to update container images and other packaged artifacts that include their own Node.js binary, because a software inventory may not identify every bundled copy. Node.js 20.x and earlier are end-of-life lines, meaning they no longer receive this correction, and should be moved to a supported release line.
The Node.js advisory provides no workaround within the runtime. Where an immediate update is not possible, Imperva recommends limiting untrusted Brotli traffic on affected request and response paths when practical, while stressing that only updating removes the vulnerability. Imperva added rules to its own web application firewall (WAF), a filtering service placed in front of web applications, and tested those rules against the attacks it reproduced. Vercel said it introduced inbound-request rules on October 21, but those rules do not protect applications that fetch malicious Brotli responses from other servers and are not a replacement for patching.
For site owners, the immediate question is whether their application, hosting image or deployment package contains an affected Node.js runtime and processes untrusted Brotli data. Organisations that need help reviewing runtime and infrastructure maintenance can consider AEU-I, which provides security-first IT, infrastructure and consulting. Regardless of hosting arrangement, the effective remediation for Node2Shell is to replace affected Node.js binaries, rebuild bundled artifacts where necessary and redeploy the updated application.