Skip to main content
HTTP2Shell (CVE-2026-111497), also called Node2Shell and Broccoli2Shell, is a buffer overflow in Google’s Brotli decoder library. An attacker who gets an application to decompress a crafted Brotli stream can crash it, expose memory and potentially run code on it. The stream can arrive in a compressed request sent to a server, or in a compressed response an application fetches. Despite the name, it isn’t specific to HTTP/2. It was first found in Node.js, which bundles Brotli, and also affects Python HTTP clients with Brotli support, .NET and other software that uses a vulnerable Brotli decoder. Your vulnerability scanner is the best way to find vulnerable software. ThreatAware helps most by showing the servers and workstations that scanner isn’t covering, where a vulnerable install could go unnoticed.

​
Are you affected?

Updating the system Brotli library doesn’t fix Node.js, or any application that bundles its own copy. Update each one. Python HTTP clients are affected when they use a vulnerable Brotli decoder: urllib3[brotli], requests, httpx and aiohttp[speedups]. Updating the brotli or brotlicffi package fixes them. An application is exposed when it decompresses Brotli data an attacker controls. The common cases:
  • Servers that decode request bodies sent with Content-Encoding: br, such as Express 5 and body-parser 2.x on Node.js.
  • Outbound requests whose client decompresses Brotli responses automatically, such as fetch() in Node.js and the Python clients above. Webhooks and features that call user-supplied URLs are the typical targets.
  • Direct use of a Brotli decoder on untrusted input.
Then check your scanner for findings on CVE-2026-111497:
  • A finding: vulnerable.
  • Recent credentialed scan, no finding: likely fixed.
  • No recent credentialed scan: unknown. Treat it as vulnerable until it’s scanned.
A scan from before 21 October 2026 can’t confirm the fix.

​
What ThreatAware can do on your plan

​
Find affected devices

​
1. Find the gaps in your scanner’s coverage

This works exactly as for PHP2Shell: use the integration columns in Devices on Connect, and Vitals on Discover. For example, with Microsoft Defender as your scanner: Swap in your scanner: type system. in the query bar and autocomplete lists your integrations.

​
2. Spot likely installs with software inventory

Treat it as a guide, not a vulnerability check. A software query only matches where a connected tool lists the software as installed, so many installs never appear (see Blind spots). Software data refreshes about every two days. The query bar is case sensitive, so the queries below check the common spellings with OR.
Node.js, Brotli or .NET on a device with no working scanner is where a vulnerable install is most likely to go unnoticed:
To list Node.js installs that aren’t on a fixed release:
On Linux, run it again with nodejs* in place of Node.js*. If a later patch release comes out in the same line, add it to the query. To list Brotli library packages that aren’t on a fixed release, such as libbrotli1 on Linux:
As with PHP, Linux distribution packages can carry a fix without changing the version number, so check your distribution’s advisory before treating a version as vulnerable. For .NET, compare the versions you find against Microsoft’s advisory.

​
Track the fix

  1. Run a query from step 1 or step 2 and click Track View. Choose Snapshot and set a Deadline. See Tracked Views.
  2. In Action Center, build a flow triggered by that tracked view to email the device owners or open tickets.
  3. Save the query as a view and send a daily Scheduled Report of it until it’s empty.

​
Blind spots

Much of the vulnerable code lives where ThreatAware can’t see installed software: If you can’t update straight away, block incoming Brotli-compressed requests at your proxy or firewall, and remove Brotli support from Python applications. Blocking incoming requests doesn’t protect against malicious compressed responses your applications fetch from other servers.
An empty list doesn’t mean you’re done. Check the blind spots above, rebuild and redeploy container images, and restart every affected process after updating. A running process keeps the old code until it restarts.

​
Sources