Node2Shell (CVE-2026-111497, CVSS 9.2): The Brotli RCE on CISA’s KEV — Is Your Stack Exposed?

On 27 October 2026, CISA silently dropped a bombshell into its Known Exploited Vulnerabilities (KEV) catalog: CVE-2026-111497, the vulnerability researchers have dubbed Node2Shell (and also HTTP2Shell or Broccoli2Shell). Active exploitation is confirmed. Federal civilian agencies must patch by 10 November 2026. But this is not just a U.S. government problem — virtually every enterprise running a modern application stack, from startup SaaS shops in Bengaluru to Fortune-500 SOC environments, is exposed. The flaw sits inside Google’s Brotli compression library, which is bundled silently inside Node.js, Python packages, .NET, Bun, Envoy, Istio, and dozens of other runtimes and proxies that form the backbone of contemporary infrastructure. If your environment decompresses Brotli content — and in 2026, almost every HTTP/2 stack does — you need to read this.

Why Node2Shell Is Different From Every Other Runtime CVE

Runtime-level vulnerabilities are not new — we have covered PHP2Shell and similar RCE chains on this blog. But Node2Shell has a quality that makes it uniquely dangerous: the root cause is not in Node.js, or Python, or .NET. It lives in Google’s Brotli compression library — a C/C++ library that ships embedded inside virtually every modern HTTP stack. When a single memory-safety bug infects a library that lives inside dozens of runtimes and proxies simultaneously, the blast radius is not linear — it is exponential.

Enterprise environments rarely track second-order dependency exposure. Your Node.js application may be patched. But is the reverse proxy in front of it — running Envoy or Istio — also patched? Is the Python-based analytics worker that fetches external API responses also patched? This is why CISA’s KEV listing matters: it signals that attackers have already understood and operationalised this exposure chain. The window to act is now, not the next monthly patching cycle.

Technical Breakdown: The Out-of-Bounds Write in DecodeBlockTypeAndLength()

The vulnerability (CWE-787: Out-of-Bounds Write, paired with CWE-252: Unchecked Return Value) lives inside the Brotli decoder function DecodeBlockTypeAndLength(). This function handles transitions between compression blocks in a Brotli stream. In affected versions (Brotli 1.0.3 through 1.2.0), the function returns a simple boolean — BROTLI_TRUE or BROTLI_FALSE. The problem: BROTLI_FALSE carries two distinct meanings that callers cannot distinguish:

• Meaning A: “This stream is malformed — abort.”
• Meaning B: “I need more input — continue.”

A crafted Brotli stream exploits this ambiguity. By carefully constructing block-switch sequences, an attacker can cause the decoder to misinterpret a malformed-stream signal as a “need more data” signal, causing it to continue accepting attacker-controlled bytes into a fixed-size internal buffer and write past the buffer’s end. The result is a controlled out-of-bounds write in heap memory — a primitive that sophisticated threat actors know how to leverage for code execution.

The upstream fix adds a distinct error code: BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH (-17). This makes block-switch failures unambiguous, and callers now propagate the error correctly. The Node.js fix wraps this corrected library, and Microsoft, Bun, and others have done the same. The advisory identifiers to track are GHSA-9v8h-qqgm-4m35 (Brotli upstream) and the Node.js October 21 Security Release Blog.

Affected Runtime / Product	Vulnerable Through	Fixed Version
Google Brotli (upstream)	1.0.3 – 1.2.0	1.0.10 / 1.1.1 / 1.2.1
Node.js 22.x	≤ 22.23.3	22.23.4
Node.js 24.x	≤ 24.22.0	24.22.1
Node.js 26.x	≤ 26.12.0	26.12.1
Node.js 20.x / 18.x (EOL)	All versions	No official fix — must migrate
Bun	≤ 1.4.3	1.4.4
Python brotli / brotlicffi	Pre-fix packages	brotli 1.2.1 / brotlicffi 1.2.1.0
.NET / Envoy / Istio	Various	Vendor-specific advisories

The Exploitation Window: From Brotli Stream to Shell

Brotli is not an obscure protocol. Since Chrome’s HTTP/2 and HTTP/3 stacks adopted it as a default compression algorithm, the vast majority of modern web traffic now uses Brotli encoding — including API responses, microservice calls, and CDN-cached content. Any service that decompresses Brotli content it did not originate is a potential target.

The primary exploitation surfaces are:

• Reverse-proxy response decompression: An attacker who controls a backend origin (or an upstream CDN response) can serve a malicious Brotli stream to a proxy that decompresses it — such as Envoy or Istio sidecar containers in your Kubernetes cluster.
• Node.js HTTP clients: Any fetch() or http.get() call in Node.js that receives an attacker-controlled Brotli-encoded response.
• Python requests with Brotli support: Applications using the brotli or brotlicffi packages (commonly added to augment the httpx or aiohttp stacks).
• Supply-chain vectors: Third-party SDK calls, webhook processors, or data-pipeline workers that fetch external content can relay attacker-controlled Brotli payloads into your runtime. This mirrors the supply-chain attack patterns we documented with Storm-0940.

CISA’s KEV listing on 27 October confirms that at least one threat actor group has weaponised this. Honeypot logs reported by SecurityWeek show active scanning and exploitation attempts in progress. The November 10 federal deadline should be treated as the outer limit — not a comfortable planning horizon — for any organisation whose risk posture puts national-security-grade infrastructure at parity.

What You Should Do: Sanjay’s Actionable Defence Playbook

As a zero-trust and network-security practitioner working with enterprises across India, this is the sequence I recommend:

1. Inventory all Brotli consumers immediately. Run grep -r "brotli\|br-compress\|brotlicffi" package.json requirements.txt *.csproj Gemfile across every repository. For containerised workloads, scan images with syft or grype to surface embedded Brotli library versions. Do not rely on manual reviews — this is an SBOM problem.
2. Patch the upstream Brotli library first. The Node.js, Python, and .NET fixes are all wrappers around the corrected Google Brotli core. Ensure the underlying libbrotli on your Linux hosts is also updated via your OS package manager (apt update libbrotli1 libbrotlidec on Debian/Ubuntu).
3. Update every affected runtime. Upgrade Node.js to 22.23.4, 24.22.1, or 26.12.1. Update Python Brotli packages via pip install --upgrade brotli brotlicffi. Rebuild and re-push any Docker images that bundle these runtimes.
4. Migrate off EOL Node.js 20 and 18 immediately. There is no official patch path. If you cannot migrate before November 10, engage a commercial extended-support vendor (HeroDevs and others have back-ported fixes), or disable Brotli decompression entirely as a stopgap.
5. Restrict Brotli at your WAF/proxy boundary. Configure your reverse proxy or CDN to strip the Accept-Encoding: br header from outbound requests to untrusted origins, preventing your services from negotiating Brotli with attacker-controlled endpoints.
6. Add detection to your SIEM/EDR. Look for anomalous process spawning from Node.js, Python interpreter, or Envoy processes. Sophos, Sysdig, and SOC Prime have published detection rules for Node2Shell exploitation signatures — ingest these into your threat intelligence pipeline now.
7. Zero-trust micro-segmentation check. If your service mesh uses Istio or Envoy (both affected), verify your mTLS policies prevent lateral movement even if a sidecar is compromised. A compromised proxy sidecar with workload identity credentials is a serious blast-radius event in a flat network. This is precisely the scenario zero-trust architecture is built to contain — as we have explored with recent GitLab critical RCEs.

India-Specific Considerations

Indian enterprises face a compounding challenge: the pace of digital transformation means that Node.js and Python microservice stacks have proliferated rapidly, often without robust dependency governance. Government-sector entities governed by CERT-In’s Information Security Practices and Procedures for Protected System Rules, 2023 are required to patch actively-exploited vulnerabilities within 6 hours of awareness — CISA’s KEV addition on 27 October 2026 constitutes exactly that level of advisory. Financial sector organisations subject to RBI’s Master Direction on IT Governance should treat this as a P1 vulnerability requiring immediate change advisory board (CAB) review and emergency patching authorisation.

Additionally, Brotli-based compression is widely used by Indian CDN and cloud providers. Any application hosted on AWS ap-south-1, Azure Central India, or GCP Mumbai that uses an API gateway with Brotli decompression should be audited for Envoy and SDK exposure.

Frequently Asked Questions

Is Node2Shell (CVE-2026-111497) actually exploitable to get a shell in practice?

CISA’s KEV listing confirms active exploitation, which means at least one real-world attack has succeeded beyond a PoC. Early public PoC reports showed reliable code execution on Node.js 24.22.0 Linux arm64 Docker images. Researchers note that exploitation reliability varies by architecture and configuration, but a CVSS 4.0 score of 9.2 and KEV confirmation should be treated as sufficient evidence to act — organisations should not wait for a production exploit screenshot to patch.

We are running Node.js 20, which is EOL. What can we do right now?

You have three options: (a) migrate to Node.js 22 LTS or 24 LTS — this is the correct long-term action; (b) engage a commercial extended-support vendor (HeroDevs, OpenLogic) who have back-ported Brotli fixes to EOL lines; or (c) as a short-term risk mitigation, disable Brotli decompression in your application by removing the brotli package, stripping Accept-Encoding: br from outbound HTTP headers, and filtering it at your load balancer. Option (c) does not fix the underlying vulnerability but removes the main attack surface.

Does this affect cloud-managed runtimes like AWS Lambda or Azure Functions?

Managed runtimes typically use provider-maintained Node.js and Python images, and major cloud providers (AWS, Azure, GCP) have updated their base images. However, custom Lambda layers and container-based functions are your responsibility. Any Lambda function or Azure Function that packages its own Node.js runtime or uses a custom container image must be updated and redeployed separately. Check your deployment pipelines now.

What is the difference between Node2Shell, HTTP2Shell, and Broccoli2Shell?

These are all informal names for the same CVE-2026-111497 vulnerability, coined by different researchers as the scope of affected products expanded. Node2Shell was the original name when the Node.js exposure was first publicised. HTTP2Shell emerged when researchers confirmed that the HTTP/2 Brotli decompression path in multiple stacks was affected. Broccoli2Shell is a whimsical variant playing on “Brotli.” The CVE is singular — the fix is always the same: update the Brotli library and all runtimes that bundle it.

The Bigger Picture: Dependency Blindness Is the Real Vulnerability

Node2Shell is a symptom of a structural problem that goes beyond any single CVE: modern software supply chains embed critical C/C++ libraries multiple layers deep, and most organisations have no reliable inventory of them. Google’s Brotli library is not something your developers chose — it was chosen by the Node.js maintainers, who bundled it because it is fast and widely deployed. Your developers then chose Node.js. The transitive risk was invisible until a KEV listing surfaced it.

This is the argument for Software Bill of Materials (SBOM) adoption — not as a compliance checkbox, but as an operational tool. An SBOM would have allowed any organisation to immediately query: “Do we have Brotli <1.0.10 in production?” and get an accurate answer in minutes. Without it, teams are running grep queries across hundreds of repositories, checking Docker image layers manually, and hoping nothing falls through the cracks.

The organisations that will come through the Node2Shell window cleanly are those with mature asset inventory, runtime SBOM generation in CI/CD, and zero-trust segmentation that limits blast radius even when a runtime is compromised. The ones who will not are those still treating dependency governance as someone else’s problem.