CVE-2026-111497 is an out-of-bounds write in the Google Brotli decompression library - the code that unpacks Content-Encoding: br web traffic - which Node.js, Bun, .NET, Envoy, Istio, Python packages, and a long tail of other software embed. Google scores it 9.2 Critical (CVSS v4.0); Node.js rates it High and states it can enable remote code execution. On October 27, 2026 - six days after disclosure - CISA added it to its Known Exploited Vulnerabilities catalog with a November 10 due date under BOD 26-04.

You are exposed only if your application actually decodes Brotli data an attacker can influence - most commonly through Express 5 / body-parser 2 request bodies, fetch() responses, or direct node:zlib calls. Patches exist for all supported Node.js lines (22.23.4, 24.22.1, 26.12.1) and upstream Brotli (1.0.10 / 1.1.1 / 1.2.1), but end-of-life Node.js releases will never receive one. For industrial operators, the concern is not PLCs - it is the Node.js-based support applications sitting at the IT/OT boundary, where a compromise could expose remote-access credentials and provide a pivot toward operations networks.

First actions today: inventory every Node.js runtime and Brotli-containing artifact (including inside containers), patch internet-facing services that decode untrusted content first, reject inbound Content-Encoding: br at the edge as a bridge control, and treat the November 10 KEV due date as a hard planning boundary for federal and critical-infrastructure environments.

Key Facts at a Glance

What Happened?

The unusual thing about this vulnerability is that its fix predates its discovery as a security issue. In February 2026, the Brotli maintainers committed a correction to the decoder that hardened block-switch handling; no one recognized it as security-relevant and no release followed. OpenAI's Codex Security team (Khai Tran and Sylvie Mayer) found the flaw during red-teaming, reported it, and Node.js coordinated disclosure for October 21, 2026, alongside OpenAI's Patch the Planet initiative and Google's Brotli releases.

Node.js shipped 22.23.4, 24.22.1, and 26.12.1 on disclosure day. One day later, Imperva's red team demonstrated code execution on the official, unmodified Node.js 24.22.0 Docker image for Linux arm64 - no weakened build, no debugger. On October 27, CISA added the CVE to KEV.

Note for readers finding older coverage: articles published between October 22 and 26 state the CVE is not in KEV and that no in-the-wild exploitation exists. Both statements were accurate when written and are now outdated.

What Is Brotli - and Why Is Its Decoder an Attack Surface?

Brotli is Google's open-source compression algorithm, released in 2015 and now a standard part of the web stack. Servers advertise it via the br token in Content-Encoding; browsers and HTTP clients decompress responses automatically. It typically shrinks text assets 20–26% more than gzip, which is why it is effectively mandatory for modern web performance.

The security asymmetry matters: compression takes trusted plain data and produces bytes; decompression takes untrusted bytes and reconstructs data. The decoder must parse every bit of an attacker's input - lengths, block types, Huffman tables, copy commands - before any validation of the meaning of the data happens. That makes the decoder exactly the kind of component where a single malformed stream can violate memory safety. Brotli reaches your applications in several forms:

• Bundled and statically linked: Node.js vendors the C source under deps/brotli and compiles it into the runtime binary. The npm package named brotli is unrelated - updating it does nothing.

• System libraries: Linux distributions may build Node.js against the system libbrotli, in which case the fix arrives via the distro's Brotli package, not a Node.js version bump.

• Language bindings and runtimes: Python's brotli/brotlicffi, .NET's bundled copy, Bun's embedded library, Java's brotli4j.

• Infrastructure software: Envoy, Istio, curl builds, FFmpeg, Apache Arrow, ClickHouse - anywhere br-encoded traffic is parsed.

Technical Analysis of CVE-2026-111497

The root cause: one return value, two meanings

Brotli organizes a stream's data into categories - literals, insert-and-copy commands, distances - and each category is split into blocks. The stream header declares up front how many block types each category uses. When a block is exhausted, the decoder reads a switch specifying the next block's type and length.

The catch: a category that declares one block type can never legitimately switch. In the vulnerable code, the function DecodeBlockTypeAndLength returned false both when input ran out mid-read and when the stream requested an impossible switch. The callers couldn't tell the difference:

• Streaming path: false meant "need more input," so the decoder kept appending attacker bytes to an internal eight-byte buffer - writing past its end.

• Fast path: the return value was ignored entirely, and decoding continued from block state the header had ruled out.

The fix

The upstream change (Brotli commit 0ed4268a, February 2026) gives the impossible switch its own permanent format error, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH (code −17), and forces every caller to halt. Node.js cherry-picked the commit and exposes the new constant in its zlib bindings. The same fix shipped in Brotli 1.0.10, 1.1.1, and 1.2.1.

Impact, ranked by evidentiary strength

1. Denial of service - demonstrated and reliable. A malformed stream crashes the process. Any service decoding untrusted Brotli can be repeatedly killed, taking every in-flight request down with the worker.

2. Memory disclosure - demonstrated. Public PoC authors report a limited read of process memory on standard builds; Vercel reports researchers demonstrated memory disclosure plus command execution on unpatched 22.x/24.x/26.x. Leaked heap can contain request data, tokens, and configuration.

3. Remote code execution - demonstrated in a lab, under constraints. Imperva achieved RCE on the official 24.22.0 Linux arm64 image via both fetch() responses and Express 5 / body-parser 2 request bodies, requiring multiple attempts; the exploit is not public, x86-64 and the 22.x/26.x lines were not tested. An earlier public PoC reached RCE only on a deliberately weakened build.

A useful way to hold these together: the CVSS vector itself encodes a caveat - AT:P (attack requirements: present). The decoder must actually be reachable with attacker-controlled input. The score describes the vulnerable component, not your specific deployment.

Node2Shell and Node.js Exposure

"Node2Shell" is Imperva's name for its analysis; the Node.js project does not use it. Since late October 23 the same flaw has circulated as HTTP2Shell and Broccoli2Shell; Tenable calls it Brotli2Shell. All refer to CVE-2026-111497 - there is no second vulnerability hiding under an alternate name.

Why Node.js took center stage: the vulnerable code is a property of the runtime binary, and Node.js is the most common place the decoder meets untrusted network input. Three realistic paths exist:

1. Inbound request bodies. Express 5 and body-parser 2.x (≥2.0.0) transparently decompress bodies sent with Content-Encoding: br. Researcher Ron Masas noted that app.use(express.json()) alone is sufficient on a vulnerable runtime. A bare Node.js HTTP server does not decode Brotli bodies on its own.

2. Outbound fetch(). Node's built-in fetch() automatically decompresses br-encoded responses. Any feature that calls URLs it doesn't fully control - webhooks, user-supplied callbacks, server-side requests - lets a malicious or compromised upstream server attack your client.

3. Direct node:zlib use. Any code passing untrusted data to brotliDecompress/createBrotliDecompress.

The npm brotli package is a separate project and is not the vulnerable component - only a fixed runtime build removes the flaw.

A state model worth internalizing: (1) vulnerable library installed → (2) vulnerable decoder reachable → (3) attacker can supply input → (4) decoder processes it → (5) exploitation succeeds → (6) post-exploitation value exists. Most internet-facing Node.js services sit at stage 3 or 4 today; everything past stage 4 is environment-dependent. Two services on the same Node version can have radically different risk.

Affected Versions and Products 

Caveats that matter: distribution packages may backport fixes without changing upstream version numbers - and conversely, a package "built from Node 24.22.1 source" by a distro still needs the Brotli side patched if it links the system library.

Active Exploitation and the CISA KEV Listing

CISA added CVE-2026-111497 to KEV on October 27, 2026, naming it the "Google Brotli Unchecked Return Value Vulnerability," with a November 10, 2026 due date and a BOD 26-04-based required action covering risk-based patching and forensic triage. Ransomware-campaign association is listed as Unknown.

What defenders should read into this:

• KEV inclusion means CISA has evidence of active exploitation - it is stronger than "a PoC exists." CISA's SSVC enrichment records Exploitation: active, Automatable: no, Technical Impact: total.

• It does not mean you have been attacked, and the entry identifies no actor, campaign, or victim. No confirmed compromises, outages, or losses have been publicly attributed as of October 29, 2026. Threat-actor attribution remains unidentified.

• The "automatable: no" signal is meaningful. Exploitation appears to require crafted conditions and, per Imperva, repeated attempts - consistent with targeted rather than wormable activity. That can change as exploit research matures; the first public PoC appeared roughly one day after patches.

• The due date binds federal civilian agencies under BOD 26-04 and is the de facto planning deadline for critical-infrastructure operators. For everyone else, it remains the strongest available signal of remediation urgency.

Keep the evidentiary categories separate: a public PoC ≠ observed attack attempts ≠ confirmed exploitation ≠ confirmed victim compromise ≠ measured damage. Today, categories one and three are documented; two is plausible but unconfirmed publicly; four and five are not.

Realistic Attack Paths

The following are illustrative scenarios, not documented incidents.

Path A - Inbound API attack (best documented).

plain

Attacker → POST /api (Content-Encoding: br, crafted stream)

        → Express 5 / body-parser 2 decompresses

        → node:zlib Brotli decoder → OOB write

        → crash | memory leak | RCE as Node.js process user

        → env vars, secrets, IAM creds, internal network access

Preconditions: internet-facing Node service with Brotli body parsing. Controls: reject br at the WAF/proxy, patch, egress filtering.

Path B - Outbound fetch betrayal. A server-side feature calls a URL it doesn't control (webhook, URL preview, integration). The hostile server responds Content-Encoding: br. The application's own fetch() decodes it. Inbound filtering does nothing here - only the runtime fix or disabling automatic decompression helps.

Path C - Gateway pivot. Envoy/Istio or another proxy with the vulnerable decoder processes attacker traffic. A compromised edge component is a far better pivot position than an app container: it sees many services' traffic and often holds broader network reach.

Path D - Supply-chain propagation. A vulnerable Node runtime is baked into a base image or build artifact and deployed fleet-wide. One unpatched image tag can mean hundreds of vulnerable services. The Docker pin node:24.22.0 stays vulnerable no matter how often you rebuild - you must move the pin.

Path E - Industrial support application (see next section). The pattern is identical, but the prize differs: service accounts, remote-access brokers, and a network position adjacent to the OT DMZ.

Industrial OT and Critical Infrastructure Risk

No industrial vendor has confirmed an affected product or incident tied to this CVE as of this writing. What follows is architectural assessment, clearly labeled as such.

Where the exposure plausibly sits

Industrial environments increasingly run the same web stack as everyone else. Places to check for Node.js/Brotli exposure:

• OT asset inventory and monitoring applications, OT security consoles

• Historian web interfaces and operations dashboards

• Manufacturing execution systems (MES) and industrial analytics platforms

• Remote maintenance and third-party vendor access portals

• Industrial API gateways, reverse proxies, and Kubernetes-based edge services

• Cloud-connected IIoT and digital-twin platforms

• Centralized logging/reporting front ends

These are investigation targets, not confirmed affected products. Each requires vendor confirmation.

The IT/OT boundary is the real risk

A compromised web application does not reach a PLC by magic. But industrial support applications frequently hold what an attacker needs for the next hop: credentials for jump hosts and remote-access brokers, VPN sessions, service accounts with access to engineering workstations, and network reach into the industrial DMZ. If a Node.js-based vendor portal at Level 3.5 runs as a service account that can reach the remote-access gateway, Path A becomes a route toward Path OT:

plain

Crafted br request → RCE on vendor portal (L3.5)

→ harvest portal credentials / session tokens

→ remote access broker or jump host

→ engineering workstation (L3) [requires further weakness/creds]

→ control network (L2/L1) [requires segmentation failure]

Each arrow needs additional access, privileges, or segmentation gaps. Strong IT/OT segmentation, one-way data architectures where appropriate, least-privilege service accounts, network allowlisting, and monitored IT/OT boundary chokepoints break the chain at every stage.

Operational consequences - ranked by directness

• Direct: loss of the compromised application's availability (crash-loop DoS is repeatable), exposure of its data and in-memory secrets.

• Indirect: loss of monitoring/reporting the application provides; disruption to engineering or vendor-maintenance workflows; credential exposure forcing emergency rotation of remote-access accounts.

• Conditional: lateral movement toward OT - requires the trust relationships above plus segmentation weaknesses.

• Speculative: any claim that this CVE has disrupted a plant or damaged physical equipment. No such incident is verified.

Patching safely in OT

Do not push untested Node upgrades into production support applications. Follow change control: test in an engineering mirror, plan a maintenance window, prepare rollback, coordinate with operations. Where an application cannot be patched promptly, apply compensating controls - inbound br rejection at the DMZ proxy, tightened egress from the application, isolation of the service account - and document the exception with an expiry date. Our guide to operationally safe OT patching covers the full workflow.

Detection and Threat Hunting

Network monitoring alone will not save you here: the trigger is a malformed Brotli stream, which inside TLS looks like ordinary compressed traffic, and no confirmed CVE-specific signature exists. Hunt behaviorally instead. 

Illustrative SIEM pseudocode (not a product-specific query):

plain

alert when: process.name == "node"

  AND (event.type == "crash" OR signal == "SIGSEGV")

  AND within 5m: (network.outbound == true OR child_process.spawned == true)

  AND host.node_version in ["<22.23.4 (22.x)", "<24.22.1 (24.x)", "<26.12.1 (26.x)", EOL lines]

MITRE ATT&CK mappings (behavioral, verified against public technique definitions): T1190 Exploit Public-Facing Application (initial access), T1059 Command and Scripting Interpreter (execution), T1003 OS Credential Dumping / in-memory secret theft (credential access), T1021 Remote Services (lateral movement), T1499 Endpoint DoS (impact).

Remediation Playbook

Phase 1 - Triage (hours 0–4)

• Confirm advisories: Node.js security release, GHSA-9v8h-qqgm-4m35, CISA KEV entry.

• Sweep for runtimes: node --version on hosts and CI runners; docker run --rm <image> node --version per image (package inventories miss embedded runtimes).

• Flag EOL lines (25/23/20/18/16 and earlier) - no fix exists; they need migration plans, not patch tickets.

• Identify internet-facing services decoding untrusted Brotli (Express 5/body-parser 2, fetch-to-untrusted-URL, direct zlib).

• If suspicious crashes coincide with this inventory, open an IR case now.

Phase 2 - Containment (hours 4–24)

• Patch to 22.23.4 / 24.22.1 / 26.12.1 (or newer) - priority order: internet-facing decoders → internal multi-tenant → everything else.

• Rebuild and redeploy container images; move the pin (node:24.22.0 → node:24.22.1).

• Bridge control where upgrades can't complete: reject inbound Content-Encoding: br at the reverse proxy/WAF. Effective only for inbound paths - outbound fetch exposure needs the runtime fix or a proxy intermediary that decompresses on the app's behalf.

• Restrict egress from Node services to required destinations only; review service-account privileges.

• Distribution-packaged Node: check the distro tracker, not the version string. Debian's nodejs+brotli were unfixed as of Oct 23.

Phase 3 - Validation and investigation (hours 24–72)

• Verify the running process, not the package manager: a patched package with an old process still decodes maliciously. Restart services after upgrade; confirm with node -p process.versions.brotli where supported.

• Check vendor backports and provenance for distro builds.

• Review crash logs, EDR telemetry, and egress flows around vulnerable services for the prior 30 days.

• Where evidence warrants, rotate application secrets, DB credentials, cloud keys, and - in industrial settings - remote-access and service accounts reachable from affected hosts.

• Document decisions, exceptions, and evidence.

Phase 4 - Long-term resilience

• SBOMs (SPDX/CycloneDX) and SCA across repos and images; include the runtime itself, not just npm deps.

• Continuous CVE-to-inventory reconciliation; runtime lifecycle policy with EOL tracking (this CVE's harshest lesson: 20.x users have no fix). HeroDevs and similar vendors offer extended-support patches for EOL Node lines.

• Image scanning in CI, pinned-and-tracked base images, egress-deny app tiers, and tested rollback playbooks.

• For industrial environments: fold web-facing support applications into OT vulnerability management with compensating-control expiry dates.

Remediation ownership table: 

Dependency and Asset Discovery

node --version alone undercounts: runtimes hide inside containers, Electron apps, single-executable bundles, and CI runners. A practical sweep:

bash

# Hosts and runners

node --version

# Every container image your org builds or runs

docker run --rm <image> node --version

# npm dependency signals (exposure hints, not the vulnerability itself)

npm ls express body-parser

# Direct decoder use in code

grep -rn "brotliDecompress\|createBrotliDecompress" .

# Distribution builds: check the distro tracker, e.g.

# Debian: https://security-tracker.debian.org/tracker/CVE-2026-111497

Then check npm ls brotli expectations: the npm brotli package is unrelated to the bundled decoder - a green SCA report on npm deps can coexist with a vulnerable runtime. Cross-reference SCA, SBOMs (SPDX/CycloneDX), image inventories, and cloud workload lists.

What Security Leaders Should Do Now

CISOs

• [ ] Commission an all-runtime inventory sweep (incl. containers, CI, EOL) with a 48-hour deadline

• [ ] Set November 10 as the planning boundary where BOD 26-04 applies; align internal SLAs

• [ ] Require evidence of running-process patch verification, not ticket closure

• [ ] Track EOL Node migrations as a named risk-acceptance item with expiry

Application & infrastructure teams

• [ ] Upgrade to 22.23.4 / 24.22.1 / 26.12.1; rebuild images; move pins

• [ ] Map every service that accepts br bodies or fetches untrusted URLs

• [ ] Test and stage; verify post-restart versions

SOC & IR

• [ ] Hunt the crash → egress → credential-use sequence on unpatched hosts

• [ ] Preserve evidence and triage against KEV forensic guidance where compromise is suspected

• [ ] Raise alerting priority on Content-Encoding: br request anomalies to JSON/API endpoints

OT security teams

• [ ] Identify Node.js-based support applications adjacent to the OT DMZ

• [ ] Coordinate changes through operations; never push untested upgrades to production support apps

• [ ] Apply compensating controls (inbound br rejection, egress restriction, account isolation) with documented expiry

• [ ] Monitor IT/OT boundary chokepoints for movement consistent with a web-tier compromise

Frequently Asked Questions

What is CVE-2026-111497? A buffer overflow (out-of-bounds write) in Google's Brotli decompression library, in the decoder file c/dec/decode.c. A crafted Brotli stream can corrupt adjacent decoder memory, crash the process, leak memory, or potentially execute code.

Is it actively exploited? CISA added it to the KEV catalog on October 27, 2026, with exploitation marked "active" in CISA's assessment - but no actor, campaign, or victim has been publicly identified, and no confirmed compromises are documented as of October 29, 2026.

What is Node2Shell? And is it different from HTTP2Shell or Broccoli2Shell? No - all are nicknames for the same CVE. Node2Shell (Imperva) references Node.js; HTTP2Shell reflects that the bug reaches HTTP software broadly; Broccoli2Shell and Brotli2Shell are variants. One CVE, several names.

Which Node.js versions are affected, and what are the fixes? 22.x before 22.23.4, 24.x before 24.22.1, 26.x before 26.12.1 - plus every end-of-life line, which will never be fixed. Upgrade to the fixed releases or newer.

Does the flaw allow remote code execution? Node.js says it can. Imperva demonstrated RCE on the official 24.22.0 Linux arm64 image (multiple attempts needed; x86-64 and other lines untested; exploit not public). A public PoC achieves crash + limited memory read on standard builds. Treat RCE as demonstrated-in-lab, not universally reliable.

Is authentication or user interaction required? No - the CVSS vector specifies no privileges and no user interaction. The requirement is network reachability to a decoder processing attacker-controlled Brotli data.

Is every application using Brotli vulnerable? No. The decoder must actually process untrusted input. A service that neither accepts br bodies nor fetches external content may carry the vulnerable code but be unreachable.

Does updating the npm brotli package fix it? No. The vulnerable code is compiled into the Node.js runtime under deps/brotli. Only a fixed runtime build removes the flaw.

Could this affect industrial applications? Plausibly, where Node.js-based support applications (portals, historians' web UIs, monitoring consoles, vendor-access systems) decode untrusted Brotli near the IT/OT boundary. No industrial product compromise is confirmed; verify with your vendors and assess your segmentation.

How can we detect exploitation? Behaviorally: crashes/SIGSEGV in node processes, followed by unexpected egress or child processes; unusual inbound br request bodies at APIs; metadata/credential access by service accounts. No reliable CVE-specific network signature exists; traffic is typically encrypted. See the detection table.

What if we can't patch - or run an EOL Node version? Bridge controls: reject inbound Content-Encoding: br at the edge (covers inbound only), restrict egress, isolate service accounts. EOL lines need migration or extended-support patches (e.g., HeroDevs NES); no upstream fix is coming.

Does a patched OS package fix bundled copies too? Not necessarily. Distribution builds that link the system Brotli need the Brotli package patched; builds that bundle the decoder need the runtime patched. Check both, and verify distro trackers - several distributions had no fix as of late October.

What if we suspect compromise? Preserve evidence (memory, logs, image digests), isolate the host, rotate credentials reachable from it - OT remote-access accounts first - and engage incident response. CISA's KEV entry references forensic triage requirements for applicable organizations.

Conclusion

CVE-2026-111497 rewards discipline more than panic. The bug is serious - memory corruption in a decoder that sits on the path of everyday web traffic, now KEV-listed with exploitation assessed as active - but your exposure is knowable and finite: find every runtime, check whether each service actually decodes untrusted Brotli, patch what does, bridge what can't be patched yet, and treat EOL Node.js as unfixable by design rather than by accident. For industrial operators, the parallel task is verifying that web-tier support applications near the IT/OT boundary aren't quietly holding the credentials that matter most.

If you want help mapping vulnerable dependencies and exposure paths across your OT environment - without disrupting production - talk to a Shieldworkz industrial cybersecurity specialist.