An ostensibly vast attack surface*, a theoretical risk of arbitrary code execution, PoCs, but no widespread exploitation: as of the latest reports, we are roughly there with P2P2Shell.
The situation is similar for another vulnerability newly disclosed. It was successively dubbed Node2Shell, HTTP2Shell… and finally Brotli2Shell. And for good reason: it affects the Brotli decompression library.
An Error Code Not Granular Enough
The issue lies in the decoder. To maximize compression, Brotli splits the stream of decompressed data into three categories. Each can switch between several statistical sub-models (“block types”) optimized for a given context. As soon as a block expires, the decoder must call this function to determine how to interpret the following symbols.
The function that handles this context switch returns a simple boolean that does not allow distinguishing incomplete streams from corrupted streams. Facing a stream requesting a block-type change that is impossible, the decoder, seeing the failure without a granular error code, assumes it is dealing with an incomplete stream. The engine continues to write bytes into a small fixed buffer. An out-of-bounds write eventually occurs. It overwrites metadata and adjacent internal structures that keep the decoder’s state. The attacker can then modify internal pointers, create an arbitrary read primitive (useful for leaking memory addresses) and divert the execution flow.
The fix adds an explicit and blocking error code. Google – which maintains Brotli – added it to the source code at the end of February, without an explicit note of severity. More importantly, it hadn’t published a new tagged version of the library (the last release remained dated October 2025). Unless you build from the main branch, downstream applications remained vulnerable.
From Node2Shell to Brotli2Shell, Several Stages of Understanding
Initially, people thought the vulnerability affected Node.js; hence the name Node2Shell. Then it became clear that it was not confined to Node. It actually affects the C reference implementation of Brotli. Hence the name Brotli2Shell (you may also see Broccoli2Shell). Between the two, there was HTTP2Shell, based on the idea that the flaw concerns all applications using HTTP.
The threat isn’t so much on web servers, which rarely decompress incoming requests. It is primarily a client-side issue. On paper, any application that consumes URLs (link previews, webhooks, file imports…) is exposed to receiving a crafted response.
As of now, there is no evidence of active exploitation, despite partial demos. More globally, there is a lack of a complete PoC. There are demonstrations circulating, but they target deliberately weakened configurations.
A (R)Call to Transition to Rust
For those who cannot patch, the two main mitigations are to disable automatic Brotli decompression in HTTP clients and to reject, at the frontend, requests that include the Content-Encoding: br header.
7-zip, Bun, ClickHouse, Envoy, Firefox, Istio and Mozilla, among others, have been patched. It is in the process of being rolled out in Apache Arrow and DuckDB.
Coupled with PHP2Shell, this memory-related vulnerability fuels the debate over a shift from C to Rust. Dropbox has developed a port in this language, but its implementation trades off performance for safety.
* W3Techs, which analyzes the market share of web technologies, estimates that 38.4% of sites use Brotli compression. By comparison, roughly 70% use PHP.
