CVE-2026-111497 enabled security researchers at Imperva to run attacker-supplied code on an official Node.js 24.22.0 image for Linux arm64 by feeding crafted Brotli data to the runtime's bundled decoder.
The Node2Shell demonstration and what it proved
Imperva's proof of concept—called "Node2Shell"—executed code on a standard Node.js 24.22.0 Linux arm64 image with no debugger or custom build by supplying malicious Brotli-compressed input to the decoder. The company reported that the exploit did not succeed on every attempt: code execution in their Linux arm64 setup required several tries. On the patched release, 24.22.1, the same crafted data was rejected and no code execution occurred.
Imperva's work built on an earlier public proof of concept that only achieved full code execution on a deliberately weakened custom build; that earlier author reported a crash and a limited read of process memory on a standard build and said a working attack had not been achieved on normal builds. As of October 22, no exploitation of the flaw in the wild had been reported.
How the Brotli decoder error leads to memory corruption (CVE-2026-111497)
Imperva traced the root cause to how the bundled Brotli decoder handles an impossible point inside a Brotli stream. Brotli streams announce the block types they will use as decoding proceeds; the test input reached a block change that the stream's own structure made impossible. The vulnerable decoder interpreted that condition as a request for more input and continued decoding in an invalid state.
In a separate run under a memory sanitizer, continuing from that invalid state produced an out‑of‑bounds write—writing past an intended buffer—which is the memory-corruption behind the bug. Node.js addressed the issue by importing an upstream Brotli patch that causes the decoder to stop with a format error at that point instead of continuing.
Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coverageWhich applications and data paths are affected
The flaw lives in the Brotli decoder Node.js bundles, so it can affect applications on the 22.x, 24.x, and 26.x release lines—not only the single build Imperva tested. A service can reach that decoder in two common places: when it reads a Brotli-compressed response via Node.js's built-in fetch(), and when middleware decodes a Brotli-compressed request body.
Notably, Express 5's body parsers—express.json(), express.urlencoded(), express.text(), and express.raw()—now decode Brotli request bodies when applied to a route, alongside gzip and deflate. A plain Node.js HTTP server, by contrast, does not decode a Brotli request body simply by receiving one; decoding requires that middleware or an explicit call. Imperva reproduced code execution through both the request-body and response paths while testing Express 5.0.0 through 5.3.0 and body-parser 2.0.0 through 2.3.0 at pinned versions, though they did not test every release in between.
Vendor fixes, mitigations, and remaining operational gaps
- Node.js disclosed the flaw and released fixes on October 21; the patched 24.22.1 release rejects the crafted data Imperva used.
- The advisory lists no workaround inside Node.js itself; Imperva said only updating removes the flaw. The company recommended limiting untrusted Brotli traffic on affected paths where that is practical.
- Imperva added rules to its web application firewall and tested them against the attacks it reproduced.
- Vercel said it added rules on October 21 that block the attack in inbound requests for customers running Node.js on its platform. Vercel's rules do not cover Brotli responses fetched by an application from other servers, and Vercel emphasized that their rules do not replace updating the Node.js runtime.
- The advisory warns that updates must reach container images and other artifacts that bundle a Node binary—locations a standard package inventory can miss. End-of-life lines 20.x and earlier do not receive the fix and should be migrated to a supported line.
What this means for technologists and hosted-platform operators
Technologists and security teams should prioritize deploying the patched releases and verifying that container images and other artifacts that include a Node binary are updated, since packaging can hide vulnerable runtimes. Where an immediate update is impossible, teams can limit untrusted Brotli traffic on affected request or fetch paths, but the advisory notes no in‑runtime workaround exists—the update is the definitive fix.
Hosted-platform operators that already applied request‑blocking rules—Vercel and Imperva among them—have reduced exposure for inbound request paths, but those rules do not eliminate the risk entirely because they do not protect applications that fetch Brotli-compressed responses from upstream servers. Operators should continue to press for customer-side updates and to test mitigation coverage across both request and response flows and across processor architectures.
Imperva's demonstration closed an important technical gap between earlier research and a working exploit on an official build, but it also left a practical question open: will similar, reliable code-execution results reproduce across other architectures and on the 22.x and 26.x lines that Imperva did not test? Given the absence of an in‑runtime workaround and the confirmed upstream patch, the immediate, concrete step is clear—inventory your runtimes and move to patched releases so that the crafted Brotli data is rejected rather than decoded.
