Hunt or be Hunted: The Crash That Gives HTTP2Shell Away

Key takeaways

HTTP2Shell is a memory-corruption flaw in Google's Brotli decoder, the code that unpacks one of the web's most common compression formats, and it ships inside Node.js, Python HTTP clients, Bun, proxies and a long tail of products that never list it as a component.
Within about 21 hours of the flaw being re-scoped from a Node.js bug to a Brotli bug, Tanium published a guide and a tested Tanium Atlas prompt that find vulnerable copies wherever they are bundled, including inside containers.
Tanium HuntIQ fired a public exploit at deliberately vulnerable lab servers on the first morning, and learned that the attack's loudest signal is not a shell but a service that keeps crashing and restarting.
Tanium SBOM reaches the copies inventory cannot: Brotli libraries bundled inside applications and container images, and the Express 5 services that decode attacker data by default.

What Happened

Node.js shipped a fix for CVE-2026-111497 on October 21, 2026, rating it High: crafted Brotli data could write past a small buffer inside the decoder and corrupt process memory (Node.js (opens in a new tab)). Within a day, Imperva showed code execution against an official Node.js build and named it "Node2Shell" (Imperva (opens in a new tab)). Then the scope broke open. The bug lives in Google's Brotli library itself, versions 1.0.3 through 1.2.0, and Aikido showed that common Python HTTP clients load it automatically (Aikido (opens in a new tab)). The name became HTTP2Shell.

Threat	Response team	Outcome
HTTP2Shell (CVE-2026-111497): out-of-bounds write in the Brotli decoder bundled in Node.js, Python Brotli packages, Bun, Envoy and other software; CVSS 4.0 9.2; public proofs of concept; no confirmed exploitation in the wild as of October 24	HuntIQ threat hunters + Tanium Guardian + Tanium Atlas + Tanium Threat Response	Public find-and-fix guide with a tested Atlas prompt about 21 hours after the re-scope; exploit reproduced in the lab and its endpoint footprint mapped into a behavior hunt

Google's CVE record scores it 9.2 under CVSS 4.0 (CVE record (opens in a new tab)), and as of October 24 no exploitation had been confirmed in the wild (Strobes (opens in a new tab)). That left a public exploit, a fix, and no clear picture of where the vulnerable code runs.

How the first day went

Tanium Guardian re-scoped its response around the wider HTTP2Shell name late on October 23 US time and opened a war room the same hour. Field teams had an internal advisory within the hour, and an overnight research run collected every product known to bundle the decoder, along with fixed versions and the version traps.

By the next morning, HuntIQ hunters had stood up two deliberately vulnerable Node.js servers in an isolated lab, one inside a container and one installed directly on the host, and fired a public proof of concept at both. Against the container, the exploit reached code execution on most runs, each only after a string of failed attempts. Against the host install of the same Node.js version, it only ever crashed the service.

The first lesson was where the attacker's code shows up. The exploit did not make Node.js start a shell. It replaced the Node.js process outright, so a hunt that waits for "node launched a shell" would see nothing. The second lesson was louder: every failed guess kills the service, and the restart that brings it back is what lets the attacker try again. On the lab container, the runtime came back over and over within a few minutes. That pattern is visible to Tanium Threat Response long after the fact.

Hunters fed both findings into the work already underway. The Atlas prompt was tested again and again against the exploited lab hosts until it reliably found a Node.js runtime inside a container and an unpackaged copy under /opt, the two places a package inventory never looks. At 22:40 UTC on October 24, about 21 hours after the re-scope, Tanium published HTTP2Shell: Find and Fix Vulnerable Brotli Copies with Tanium, with that prompt, the manual questions behind it, and a hunt for the crash-and-restart pattern.

Why finding Brotli was the hard part

Brotli almost never appears in a software inventory, because it is compiled into other things: language runtimes, Python environments, desktop apps, proxies and container images. A patched Node.js even keeps reporting its old Brotli version number, so the obvious check gives the wrong answer. Each copy is fixed by whoever owns it, which means the first question is not "are we patched?" but "who owns every copy?"

Tanium can put every one of those copies on one list. Package inventory covers what was installed, process ancestry covers what is running in containers, and Tanium SBOM reads inside applications and image layers: the Brotli library an application ships, the Express 5 service that decodes Brotli request bodies by default, the old decoder baked into an image the host's patch never touches. What HuntIQ added was firsthand knowledge of the attack. Hunters had watched it crash and retry, so customers knew which hosts to patch first and what to watch for on the ones they could not.

Learn how you can stay ahead of the next emerging threat with Tanium Security Operations and HuntIQ
Read the full technical breakdown: HuntIQ Tradecraft: Hunting HTTP2Shell with Tanium (opens in a new tab)
Read about our research: HTTP2Shell: Same Exploit, Same Node.js, Different Outcome (opens in a new tab)