Bye Bye Brotli? Google's Compression Library Is a Security Mess

What it is

A blog post by the Bugsink author arguing that Google's Brotli reference implementation (C library plus Python bindings) has a slow, ad hoc security release process, and that teams should question whether they need to accept Brotli at all. The author's own vote is to drop it where possible.

How it works

Two incidents carry the argument.

The first is the memory-corruption bug in the Brotli decoder, triggered by a crafted Brotli payload. The post says it is the real flaw behind Node's "HTTP2Shell" (first called Node2Shell). Attacker-controlled input can run past the end of an eight-byte buffer into adjacent process memory. The fix landed on 27 February 2026 and a release followed on 21 October 2026. Node published its advisory before the Brotli release.

The second is the decompression-bomb fix of 2025. Small Brotli inputs expand in memory to very large outputs, causing memory-exhaustion DoS. The fix added an optional output_buffer_limit argument to Decompressor::process and a Decompressor::can_accept_more_data method. The post says the change was undocumented, and that the only other package that had worked out what to do, Scrapy, had not yet applied it.

Timeline in days, from the post:

• Day 0 (17 September 2024): fix first committed publicly.
• Day 113 (8 January 2025): fix merged.
• Day 122: release notes committed, containing the words "SECURITY" and "mitigation of unexpectedly large output".
• Day 405 (27 October 2025): C library released as version 1.2.0.
• Day 414: Python package released to PyPI.

urllib3 adopted the new limit on 5 December 2025. It had to fix its own implementation 153 days later, because that implementation introduced another high-severity decompression-bomb vulnerability.

Preconditions / Affected

• Any service that decodes Brotli from untrusted input. The post notes this can happen on any request for a web server accepting Content-Encoding: br.
• Bugsink accepted Content-Encoding: br and was open to the memory-exhaustion DoS. The Python Sentry SDK sends Brotli-encoded messages, so Sentry-compatible receivers must decode them.
• Open at time of writing: three out-of-bounds read PRs in the Brotli repository, and a CPU exhaustion issue in the .NET implementation that is over a year old. Google publishes no official NuGet package for .NET, but the post says the code is used through copy-paste.

What to do

• Check which Brotli version you ship. Releases on 27 October 2025 (1.2.0) and 21 October 2026 carry the fixes described.
• Where you decode Brotli, pass output_buffer_limit. The post says this is undocumented.
• Review whether you need to support Brotli at all (the author's recommendation).
• Bugsink's approach: add a setting to turn off Brotli decoding for self-hosters who do not need it, and ask upstream Sentry whether the SDK can stop sending it. A Python wrapper around a Rust Brotli implementation is floated as a fallback, not built.

Caveats

The post is opinion. It gives no CVE identifiers and does not say whether the three out-of-bounds read PRs are exploitable. It also does not say which Brotli release first contains the February 2026 fix beyond giving the October 2026 date.