HTTP2Shell: the Brotli flaw reaches far beyond Node.js

On 23 October, Node2Shell became HTTP2Shell – a new name, not a new flaw. It still means CVE-2026-111497 in the Brotli decoder, whose consequences for Node.js are covered in yesterday's post. What is new is how far the same library reaches: into Python packages, Bun, Envoy, curl and Git for Windows. There it becomes dangerous under one condition that many warnings leave out. The software has to decompress Brotli data from an untrusted source.

What is HTTP2Shell?

HTTP2Shell is the name the security firm Aikido gave, on 23 October 2026, to the reach of CVE-2026-111497 beyond Node.js: an out-of-bounds write in Google's Brotli decoder, affecting releases 1.0.3 to 1.2.0. The name shifts the focus from the runtime to the protocol. Any software that decompresses Brotli-compressed HTTP data can be affected. The bug, the fix and the corrected releases 1.0.10, 1.1.1 and 1.2.1 are the same as on 21 October. Google itself issued the CVE record.

Who is affected – and under which condition

Software is affected only if it contains a vulnerable Brotli release and uses it to decompress data an attacker can supply. For most of the projects now being named, exactly that is optional:

For Python, GitHub published a separate advisory on 22 October, GHSA-9v8h-qqgm-4m35. The packages often enter an environment as an indirect dependency. Istio shipped the fix on 15 October, before disclosure. Copies built into a program need a new build: Git for Windows 2.56.0.windows.3, released on 22 October, still lists brotli 1.2.0-1 in its package list.

Server and client: direction decides

The flaw works in both directions, and the second is easy to miss. On the server side, an application decompresses Brotli-compressed requests – in Node.js, for example, through the Express 5 parsers. On the client side, it decompresses the response of a server it calls itself. Bun and Node's fetch() do this automatically; urllib3, and with it requests, does so based on the response's Content-Encoding.

On the client side, an attacker does not need to attack a server. They need to run one. Every feature that fetches an external address is such a route: webhooks, link previews, avatar imports, a git clone from an unknown server. A test published by the blog lilting.ch on 24 October shows urllib3 decoding a Brotli response even when the client asked for no compression with Accept-Encoding: identity. A reverse proxy that rejects requests carrying Content-Encoding: br does not protect this direction.

Bun's advisory states explicitly that there is no process-wide workaround; individual calls can be protected with decompress: false. The common web servers, on the other hand, are rarely the route. Apache and nginx compress with Brotli but, according to Aikido, do not decompress by default.

Version numbers do not show the fix

Whether a component contains the fix cannot be read reliably from its Brotli version string. In 24.22.1 and 26.12.1, Node.js took over only the fix commit. The version file in its source tree still says 1.2.0, in 22.23.4 it says 1.1.0, and process.versions.brotli reports those values. Debian backported the fix: 1.0.9-2+deb12u1 for Bookworm (DLA-4855-1) and 1.1.0-2+deb13u1 for Trixie (DSA-6582-1), both dated 23 October. Anyone comparing only the upstream version will report patched systems as vulnerable.

Then there is the timeline. The fix commit 0ed4268 has been public in the Brotli repository since 27 February 2026, described as "Detect and report invalid stream earlier." A release followed only on 21 October. For almost eight months the correction sat in the source code, but in no release that distributions and package managers ship. It was a silent fix, like Fortinet's recent hardening release, only longer.

How critical the flaw really is

The situation has not escalated since 21 October; it has become clearer. It is now known where the decoder sits, and there are still no known attacks. Google rates the flaw CVSS 9.2 under version 4.0, but the vector contains AT:P: a successful attack depends on specific deployment conditions of the system. Others rate it lower. Node.js and Bun call it "high", Amazon Linux scores it 8.1 under CVSS 3.1, and Ubuntu gives it priority "medium".

CISA's assessment in the CVE record reads "none" for exploitation and "no" for automatable. As of 24 October, the flaw is not in the KEV catalogue. The only documented code execution remains Imperva's exploit against Node.js, which did not succeed on every attempt. Since 21 October, more than 30 repositories with proofs of concept, test labs and check scripts for the CVE have appeared on GitHub. Whether any of them is a reliable exploit is unknown.

What to do now

The work shifts from asking about the version to asking who decompresses untrusted data:

• Check Python environments, not just the project files. Bring brotli and brotlicffi to 1.2.1 and 1.2.1.0, in container images too.
• Rebuild embedded copies. According to Bun, programs built with bun build --compile stay vulnerable until rebuilt with 1.4.4. The same applies to statically linked curl.
• Search proxy configurations. Envoy and Istio reach the decoder only with an active Brotli decompressor; where one is configured, the update comes first.
• Include outbound requests. Services that fetch user-supplied addresses decompress responses from servers they do not control.
• Update distribution packages and restart processes. As of 24 October, Ubuntu lists the flaw as "needs evaluation" and Amazon Linux 2023 its Brotli package as "pending fix". Dynamically linked programs such as curl benefit from the library update without a release of their own.
• Check version findings against the fix level. Brotli 1.2.0 in Node 24.22.1, or 1.0.9 in Debian Bookworm, is not a finding.

What helps – and why visibility decides

With HTTP2Shell, what matters is less which Brotli version is installed than which systems decompress untrusted data: public APIs, proxies, services that fetch user-supplied addresses. Through Attack Surface Management, blacklens.io continuously discovers from the outside which services and web applications are reachable and which technologies, in which versions, run on them. The Threat Center matches new CVEs against that inventory in real time and shows for each hit whether it rests on the exact version or only on the product.

The limit is narrower here than with Node2Shell. The CVE record names only Brotli as the affected product, a library that no service displays to the outside. What can be recognised are its carriers, such as Node.js applications and proxies. A Brotli package in a Python environment or a compiled program is found only by a check on the system. From the outside, you can narrow down where that check is needed first.