Nomios Threat Intelligence update: Node2Shell

Last updated:  23rd October 2026, 13:00

At a glance

 Summary

A flaw in Google's Brotli decompression library lets an unauthenticated attacker corrupt memory by sending compressed data that an application decodes, either in a request or in a response to an outbound call. It is not known to be exploited in the wild, but lab exploits work, including one against a standard Node.js build, and scanning has begun. Brotli is built into runtimes and proxies, so fixing it means updating those runtimes, rebuilding images and restarting services.

What has happened

The flaw

Brotli versions 1.0.3 to 1.2.0 mishandle an illegal "block switch" in a compressed stream. Instead of rejecting it as a format error, the decoder treats it as a temporary need for more input. On streaming paths it then keeps appending input to an 8-byte internal buffer and writes past the end of it.

The result can be a crash, a hung process, disclosure of process memory or, in some conditions, code execution. The trigger is small: Google Threat Intelligence describes a crash payload of 22 to 86 bytes.

Fixes and how quickly the picture has moved

• The flaw was reported by OpenAI Codex Security. A fix was committed to Brotli in February 2026 but not released as a security fix until 21 October, alongside Node.js 22.23.4, 24.22.1 and 26.12.1.
• The first public proof of concept achieved code execution only on a deliberately weakened build. On a standard build it caused a crash and a limited memory read.
• On 23 October Imperva's red team reported code execution on the official Node.js 24.22.0 image for Linux arm64, with no debugger or custom build. It took several attempts and the exploit has not been released.
• Google Threat Intelligence considers reliable code execution difficult in practice, because the flaw gives no built-in way to defeat memory randomisation (ASLR) and depends on specific memory layout. Crashing a service is much easier.
• The scope has widened daily, from Node.js to Python, Bun, PHP and Ruby extensions, Envoy, Istio and, on 25 October, .NET.
• CVE-2026-111497 was not in CISA's Known Exploited Vulnerabilities catalogue as of 26 October.

Who is affected

The flaw is in the decoder, so the question is not "do we run Node.js?" but "does anything we run decompress Brotli data that someone else controls?". There are two routes in.

• Inbound. A request body marked Content-Encoding: br that middleware decodes, such as Express 5 and body-parser 2 ( express.json() , express.raw() ), ASP.NET Core request decompression, or an Envoy Brotli decompressor.
• Outbound. A Brotli response from a server you do not control, decoded automatically by Node.js fetch() or node:zlib , Python urllib3, requests, httpx, aiohttp or Scrapy when Brotli is installed, or .NET HttpClient with decompression enabled. Webhooks, link previews, crawlers and third-party integrations are typical.

Not affected by default: Apache mod_brotli (compresses only), Nginx (does not decode request bodies by default), a plain Node.js HTTP server with no decoding middleware, and .NET Framework.

Still catching up: as of 25 October, bundled copies in products such as DuckDB, ClickHouse, Apache Arrow bundled builds and several 7-Zip forks were unpatched. Check vendor advisories for any product or appliance that bundles Brotli.

What the world is seeing

• No confirmed exploitation. Google Threat Intelligence reports zero confirmed compromises across perimeter, endpoint and passive network telemetry. No vendor or agency has attributed an attack to the flaw, and it is not in CISA's Known Exploited Vulnerabilities catalogue.
• Reconnaissance has started. Google's passive sensors have seen limited, opportunistic scanning of generic ingestion and upload endpoints, such as /api/ingest , /api/v1/upload and /api/webhook, sending Content-Encoding headers and an http2shell proof-of-concept user agent. Separately, ELLIO reports a scanner using the user agent node2shell-check/1.0 to catalogue which hosts decompress Brotli. Neither achieved code execution.
• Exploit code. Several proofs of concept are public. Crashing a service is reliable and easy. Code execution has been shown only in the lab, and the one demonstrated against a standard build has not been released. Treat denial of service as the realistic near-term risk and code execution as the worst case.
• Wide exposure. Wiz reports that 91 per cent of cloud environments contain resources vulnerable to CVE-2026-111497 and 82 per cent have publicly exposed Node.js instances.
• Severity ratings differ. Node.js and Google rate it High. The CVE record gives CVSS v4.0 9.2, Critical. Red Hat rates it Important, Ubuntu Medium, and Amazon gives a CVSS v3 score of 8.1. The difference reflects how hard code execution is in practice, not doubt about the flaw.
• Inventory blind spots. Brotli built into Node.js, Bun or .NET binaries does not show up as a libbrotli package, so scanners can miss it. Patched distribution packages can be wrongly flagged because they keep the old version number. As of 23 October, pip-audit, Dependabot and Safety were not yet flagging the affected Python packages.
• WAF coverage is partial. Cloudflare, Azure, Imperva and Vercel have added rules. These inspect inbound requests only and do not protect an application that fetches a malicious response from an outside server.

What an attack looks like

Node.js, Google and published research give enough detail to explain the shape of an attack, and this bulletin keeps to that level. Payloads, offsets and stream contents are deliberately not shown.

DETECTION CHALLENGE: Decompression usually happens in the runtime or middleware before application logic runs, so application validation and logging never see the decoded payload. A WAF only inspects inbound traffic: a malicious response to an outbound fetch() never passes it.

A crash is the most likely trace, because failed attempts bring the process down. Google advises checking crash logs and core dumps for unexpected SIGSEGV exits in ProcessCommandsInternal or BrotliDecoderDecompressStream. Sysdig recommends watching for a Node.js crash followed by new program execution in the same workload.

After a successful attack the attacker runs as the service account. In containers that includes service account tokens, mounted secrets and cloud credentials.