A newly disclosed memory corruption vulnerability called HTTP2Shell (CVE-2026-111497) in Google’s Brotli compression library is raising serious security concerns, following closely on the heels of the PHP2Shell disclosure. Also referred to as Brotli2Shell, Broccoli2Shell, and Node2Shell, the HTTP2Shell vulnerability targets the decoder component of the Brotli library, which is responsible for unpacking compressed data. Because Brotli is widely used across the web, its decoder is embedded in a significant amount of software that most users and even many administrators rarely consider.
HTTP2Shell Flaw: How the Brotli Vulnerability Works and Why It Is Dangerous
According to Satnam Narang, Senior Staff Research Engineer for Security Response at Tenable, the HTTP2Shell vulnerability is triggered when an application decompresses Brotli data that an attacker is able to control. This can occur through a compressed request sent to a server, or a compressed response returned to a client that automatically decompresses it. Successful exploitation could allow an attacker to crash an application, read its memory, or in the worst case, execute arbitrary code on the system.
Researchers have already demonstrated code execution against official Node.js builds, specifically version 24.22.0, though achieving this has required repeated attempts tuned to that particular build. Public proof-of-concept code is available on GitHub, raising the risk of broader exploitation.
On 26 October, threat intelligence firm ELLIO reported active exploitation attempts targeting Node.js in the wild. The following day, CISA added HTTP2Shell to its Known Exploited Vulnerabilities (KEV) catalogue. Akamai’s telemetry data indicates that 61% of networks are running affected Node.js versions.
One reason the vulnerability is particularly difficult to address is that it hides inside other software. Brotli does not always appear as a standalone entry on an asset inventory, because it ships bundled inside runtimes and libraries. Official Node.js builds and the Bun runtime carry their own copy of the library, which means updating the operating system’s Brotli package does not resolve the issue for those environments.
Applying an update is also not immediately effective for already-running processes. The fix only takes effect after the application or container image is rebuilt, redeployed, and restarted.
Steps Organisations Can Take to Address the HTTP2Shell Vulnerability
The recommended first step is identifying where the Brotli decoder is present across systems. Fixed releases are now available for Brotli itself, Node.js, .NET, Bun, Envoy Proxy, Istio, Python’s Brotli packages, and PHP for Windows.
Node.js release lines that have reached end-of-support, including versions 20, 23, and 25, will not receive a patch from the Node.js project. Its guidance is to migrate to a supported release line. For environments where an immediate update is not possible, rejecting Brotli-compressed requests before they are decompressed closes one attack avenue, though this does not protect applications that fetch Brotli-encoded responses from external servers.
Where the HTTP client supports it, such as in .NET’s HttpClient, automatic Brotli decompression can be disabled as a temporary mitigation. The Node.js project does not offer a comparable workaround for its built-in fetch implementation, making an update the only effective solution for those environments.
Pokdepinion: A compression library quietly sitting inside half the internet’s runtimes is not exactly the threat model most IT teams had on their bingo card.
