Node2Shell: Exploiting CVE-2026-111497 Through Malformed Brotli Streams in Node.js

Overview

Why This Bug Matters: Decompression Is an Attack Surface

Brotli (Content-Encoding: br) is the default high-ratio compression on the modern web. Every CDN, browser and most HTTP clients speak it, which means it is also something servers and clients decode automatically, often without application code ever asking for it. Node.js exposes the bundled decoder through node:zlib (brotliDecompress, createBrotliDecompress), and higher-level code reaches it implicitly: fetch() (Undici) transparently decompresses responses, and Express 5 / body-parser 2 decompress br request bodies before the JSON or raw parser ever sees them.

That makes CVE-2026-111497 unusual among runtime bugs. The attacker does not need a vulnerable application route or a logic bug in your code. They need one of two things: a way to send a compressed body to a parser that inflates it, or a way to make your service fetch something from a server they control. Webhooks, URL previews, OAuth discovery, SSRF-ish "import from URL" features, link unfurlers, scraper services and server-side rendering all qualify.

Root Cause Analysis

Brotli in 90 seconds

A Brotli stream is a sequence of meta-blocks. Each meta-block header declares, for three categories (literals, insert-and-copy commands, distances), how many block types exist (NBLTYPES, 1 to 256) and, when more than one exists, a prefix code for block-type switch commands and block lengths. During decoding, when the current block's counter runs out, the decoder calls DecodeBlockTypeAndLength() to read the next block type and its length from the bitstream, then swaps in the matching Huffman tree group and context map.

If a category declares exactly one block type, a block switch is structurally impossible: there is nothing to switch to, and no switch codes were ever decoded. A conforming decoder must treat any attempt to perform one as a format error.

The flaw: a format error that looks like "need more input"

DecodeBlockTypeAndLength() returns a boolean-style result. In vulnerable versions, the path that encounters the impossible switch returned the same failure value as the path that simply ran out of buffered bits. The caller, the streaming state machine in BrotliDecoderDecompressStream(), interprets "false" as BROTLI_DECODER_NEEDS_MORE_INPUT: it saves its position, stashes the unconsumed tail of input into a small internal ring and returns to the host asking for more bytes. That is the CWE-252 half of the bug.

The CWE-787 half follows directly. The decoder keeps a tiny internal buffer (8 bytes, sized for the largest bit-reader refill it should ever need) to carry partial input across calls. In the "need more input" path it appends new caller data into that buffer, expecting a successful parse to drain it. Because the parse can never succeed on this stream, every subsequent chunk from the attacker is appended past the end of the 8-byte buffer, overwriting whatever decoder state follows it in the BrotliDecoderState structure: pointers, counters, ring-buffer sizes and table references the decoder will later dereference and write through.

Memory view of the corruption

Call path inside Node.js

# Simplified native call chain for an inbound Brotli body (vulnerable runtime)
#0  DecodeBlockTypeAndLength()          // decode.c: impossible switch, returns FALSE
#1  DecodeLiteralBlockSwitch / Command / Distance ...
#2  ProcessCommands()                   // result treated as NEEDS_MORE_INPUT
#3  BrotliDecoderDecompressStream()     // appends next chunk into 8-byte buffer → OOB write
#4  BrotliDecoderContext::DoThreadPoolWork()
#5  CompressionStream<...>::Write()   // node_zlib.cc
#6  zlib.createBrotliDecompress()  ←  body-parser 2.x / Undici fetch() / user code

The fix

Upstream commit 0ed4268 ("Detect and report invalid stream earlier") landed in the public Brotli source tree on February 27, 2026. It makes DecodeBlockTypeAndLength() return a dedicated error, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH, (numeric value -17) and propagates that error out of the decoder instead of collapsing it into "need more input". Genuine input shortfalls still return NEEDS_MORE_INPUT. Node.js cherry-picked the change and also exposed the new decoder error code to JavaScript. Critically, the commit was not flagged as a security fix, and no Brotli release shipped it until October 21. Any project vendoring Brotli from a release tarball stayed vulnerable for roughly eight months while the fix sat in plain sight in the public repository, a textbook "silent fix" window for anyone diffing upstream.

// Conceptual diff (not the literal patch)
- if (!SafeReadBlockType(s, br, &block_type)) return BROTLI_FALSE;   // ambiguous
+ if (s->num_block_types[tree_type] < 2)
+     return BROTLI_FAILURE(BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH);
+ /* ...callers now distinguish a format error from NEEDS_MORE_INPUT
+    and move the decoder into a terminal error state */

Exploit Maturity Assessment

Proof of Concept (PoC)

Independently validated targets

PoC Reproducibility

Can a PoC be built from available information? Yes. A complete public exploit exists for Node.js 24.22.0 x86-64.

• Required tools: an isolated lab with the official vulnerable node:24.22.0 image, the public exploit, a Brotli bitstream generator, and an ASan-instrumented Brotli build for root-cause triage.
• High-level steps (lab only): declare a single block type for one category; let that block's counter run out mid-stream; force a block switch; keep streaming chunks so each append extends the overflow; observe the fault or shell on the vulnerable build and a clean -17 format error on the patched build.
• Porting limits: official Node.js binaries are not position-independent, so code addresses are fixed per build, but the heap, stacks and allocator arenas are randomized. The exploit needs a build-specific offset and the correct socket descriptor, which becomes less predictable on busy services. Expect offsets for other popular builds to appear quickly.

Time-to-Exploit Analysis

Vulnerability Timeline

Affected and Fixed Versions Across the Ecosystem

Because Brotli is a library, this is a supply-chain-shaped vulnerability. Patching Node.js does not fix the Python worker next to it, the Envoy sidecar in front of it, or a curl binary in the same image.

Active Exploitation & Threat Actors

Post-Exploitation Details

MITRE ATT&CK Mapping

Vulnerability Chaining Opportunities

Can this be chained? Yes. Node2Shell is an excellent second stage for anything that lets an attacker choose a URL your server fetches.

Patch / Mitigation

Verify the runtime you actually run

# Host / VM
node --version
# Do NOT rely on process.versions.brotli: the fix was cherry-picked without a version bump,
# so it reports 1.2.0 on both patched and vulnerable builds. Check the Node.js release instead.

# Patched runtimes expose the new decoder error constant (expect a number, not undefined)
node -p "require('zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH"

# Every image in your registry / cluster, not just the app server
docker run --rm --entrypoint node <image> --version
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

# Python environments that silently enable br decoding
pip show brotli brotlicffi 2>/dev/null | grep -E "Name|Version"

Interim mitigation while rolling out

# NGINX: refuse Brotli-encoded request bodies at the edge
if ($http_content_encoding ~* "br") { return 415; }

# HAProxy
http-request deny deny_status 415 if { req.hdr(content-encoding) -i -m sub br }

// Express 5: reject br bodies BEFORE any body-parser middleware runs
app.use((req, res, next) => {
  const ce = (req.headers['content-encoding'] || '').toLowerCase();
  if (ce.split(',').some(v => v.trim() === 'br')) {
    return res.status(415).send('Unsupported Content-Encoding');
  }
  next();
});
app.use(express.json());

Indicators of Compromise (IOCs)

IOCs Available: Yes. Indicators below come from the first recorded in-the-wild exploitation attempt and the reconnaissance that preceded it. The exploit body varies per target, so behavioral indicators remain essential.

Network and payload indicators

# Structured IOC list (CVE-2026-111497 / Node2Shell)
ipv4        94.154.43.7                                                   # exploitation
sha256      7fcbdaaecd4419e2930927844f3b772668204737a4e7602a2290c991c93c5c4b   # br exploit body
asn         AS44620                                                       # node2shell-check scanner source
user_agent  Mozilla/5.0 (compatible; node2shell-check/1.0)
http        POST, Content-Encoding: br, Content-Length: 23069983
http        POST, Content-Encoding: br, Content-Length: 1032 (A-padded)

Host and behavioral indicators

Detection & Monitoring

Log sources

Splunk

# ── QUERY 1: Brotli-encoded request bodies to app endpoints ─────────────
index=web sourcetype IN ("nginx:plus:kv","nginx:access","aws:elb:accesslogs")
  http_method IN ("POST","PUT","PATCH")
  http_content_encoding="*br*"
| stats count values(uri_path) AS paths values(status) AS statuses max(bytes_in) AS max_body by src_ip
| where count > 3 OR max_body > 10000000
| eval risk="HIGH - Possible CVE-2026-111497 probing / exploitation"

# ── QUERY 2: Node.js crash bursts per host ──────────────────────────────
# Aggregate with stats by time bucket AND host, filter on the plain count field,
# then chart if needed. (timechart ... by host pivots hosts into separate columns,
# so a later "where count > 2" has no count field to test.)
index=k8s OR index=linux
  (process_name="node" OR container_command="*node*")
  (exit_code IN (134,135,139) OR signal IN ("SIGSEGV","SIGBUS","SIGABRT"))
| bin _time span=5m
| stats count AS crashes by _time host
| where crashes > 2
| xyseries _time host crashes            ``` optional: chart only the filtered rows ```

# ── QUERY 3: Node.js spawning a shell or downloader (post-RCE) ──────────
index=edr (parent_process_name="node" OR parent_process_name="nodejs")
  process_name IN ("sh","bash","dash","curl","wget","nc","ncat","python","python3","perl")
| eval risk="CRITICAL - Node.js child shell"
| table _time host user parent_process_name process_name process_cmdline risk

# ── QUERY 4: br request FOLLOWED BY a crash on the same host (≤ 60 s) ──
# Ordered correlation: request must precede the crash. src_ip identifies the
# client that sent the preceding request; it is a candidate, not proof of
# attribution, unless request-level IDs (e.g. X-Request-ID) link the two events.
(index=web http_content_encoding="*br*" http_method="POST")
OR (index=k8s exit_code IN (134,135,139))
| eval etype=if(index="web","req","crash")
| eval req_time=if(etype="req",_time,null()), req_src=if(etype="req",src_ip,null())
| sort 0 host _time
| streamstats last(req_time) AS last_req_time last(req_src) AS last_req_src by host
| where etype="crash" AND isnotnull(last_req_time) AND (_time - last_req_time) >= 0 AND (_time - last_req_time) <= 60
| eval gap_s=_time - last_req_time
| table _time host last_req_src gap_s
| rename last_req_src AS "preceding br request src (candidate)"

# ── QUERY 5: Known IOCs ─────────────────────────────────────────────────
index=web (src_ip="94.154.43.7" OR http_user_agent="*node2shell-check*")
| stats count earliest(_time) AS first latest(_time) AS last values(uri_path) by src_ip http_user_agent

Elastic / KQL

# ── br request bodies ────────────────────────────────────────────────────
http.request.method:(POST or PUT or PATCH) and
http.request.headers.content-encoding:*br*

# ── node spawning shells ─────────────────────────────────────────────────
event.category:process and event.type:start and
process.parent.name:(node or nodejs) and
process.name:(sh or bash or dash or curl or wget or nc or python3)

# ── node talking to instance metadata (endpoint telemetry, not flow logs) ─
event.category:network and process.name:node and destination.ip:"169.254.169.254"

# ── Known IOCs ───────────────────────────────────────────────────────────
source.ip:"94.154.43.7" or user_agent.original:*node2shell-check*

Microsoft Sentinel (KQL)

// ── Linux endpoint (MDE): node spawning a shell ─────────────────────────
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("node", "nodejs")
| where FileName in~ ("sh","bash","dash","curl","wget","nc","python3","perl")
| project Timestamp, DeviceName, AccountName, InitiatingProcessCommandLine, ProcessCommandLine
| extend Risk = "CRITICAL - Possible Node2Shell post-exploitation"

// ── Container crash loops (Container Insights) ──────────────────────────
KubePodInventory
| where ContainerRestartCount > 3
| where ContainerLastStatus has_any ("Error", "139", "134")
| summarize Restarts = max(ContainerRestartCount) by Name, Namespace, bin(TimeGenerated, 15m)

// ── Patched runtime rejecting exploit input (app logs) ──────────────────
AppTraces
| where Message has "ERR__ERROR_FORMAT_BLOCK_SWITCH"
| summarize Attempts = count() by AppRoleName, bin(TimeGenerated, 15m)

// ── App Gateway / Front Door: br-encoded request bodies ─────────────────
AzureDiagnostics
| where Category in ("ApplicationGatewayAccessLog", "FrontDoorAccessLog")
| where requestHeaders_s has "content-encoding: br"
| summarize count() by clientIP_s, requestUri_s, bin(TimeGenerated, 10m)

Falco (runtime)

- rule: Node.js Spawns Shell (Node2Shell post-exploitation)
  desc: A Node.js process started a shell or network utility
  condition: >
    spawned_process and proc.pname in (node, nodejs) and
    proc.name in (sh, bash, dash, curl, wget, nc, ncat, python3, perl)
  output: "node child process (parent=%proc.pname cmd=%proc.cmdline container=%container.name image=%container.image.repository)"
  priority: CRITICAL
  tags: [CVE-2026-111497, T1059.004]

Suricata (inbound, cleartext or after TLS termination)

alert http any any -> $HOME_NET any (msg:"Possible CVE-2026-111497 Node2Shell - Brotli request body";
  flow:established,to_server; http.method; content:"POST";
  http.header; content:"Content-Encoding|3a 20|br"; nocase;
  threshold:type both, track by_src, count 5, seconds 60;
  classtype:attempted-admin; sid:9261114; rev:1;)

Behavioral indicators for EDR

• Any interactive shell whose ancestor is node in a container that normally never executes child processes.
• Memory pages becoming writable and executable in a node process outside V8's JIT regions.
• A node process that crashed and restarted several times, then begins outbound connections it never made before.
• Reads of /proc/self/environ, /var/run/secrets/kubernetes.io/serviceaccount/token or ~/.aws/credentials by the runtime.

Risk Assessment

Exposure decision flow

Remediation Recommendations

SecPod Coverage

Key Takeaways

• The bug is in the runtime, not your code. Express, body-parser and fetch() are delivery routes into a native decoder compiled into Node.js.
• Outbound traffic is attack surface. A server that fetches a URL an attacker controls can be exploited through the response, and edge WAFs never see it.
• One error code, two meanings. Collapsing "malformed" into "incomplete" is a recurring parser bug class; streaming decoders are especially prone to it.
• This is now exploited. A public exploit, in-the-wild attempts and a CISA KEV listing mean the window for routine patching has closed.
• Silent fixes are an attacker head start. Eight months between the upstream commit and a release is time defenders did not know they had lost.
• Patch, rebuild, restart, verify. Updating a package without restarting the process or rebuilding the image leaves the vulnerable decoder running.

Node2Shell is a reminder that the lowest layers of the web stack, compression, parsing and TLS, are now being mined with AI-assisted tooling at a pace that compresses the gap between disclosure and a public exploit to about a day, and to in-the-wild attempts and a CISA KEV listing within a week. The patch is available and drop-in. The fastest way to remove this risk is to replace every vulnerable Node.js runtime you run and restart it today.

Instantly Fix Risks with Saner Patch Management

Saner patch management is a continuous, automated, and integrated software that helps security teams fix risks exploited in the wild. The software supports major operating systems such as Windows, Linux, and macOS, along with 550+ third-party applications.

It allows teams to set up a safe testing area to validate patches before deploying them in production. Saner patch management also supports patch rollback in case of patch failure or system malfunction.

Experience the fastest and most accurate patching software here.