What Is Brotli Compression and Where Does It Run?

Brotli compression is a lossless data format developed by Google and published as RFC 7932 in 2016. Web servers use it to shrink HTML, CSS, JavaScript and JSON before sending them, and browsers and HTTP clients decompress the data on arrival. Because the decoder runs on whatever bytes arrive, a flaw in it can be reached by anyone who can send compressed data to your software, as the October 2026 Brotli CVE-2026-111497 KEV listing showed.

What is Brotli compression?

Brotli is a general-purpose compression algorithm that combines LZ77 matching, Huffman coding and a built-in dictionary of common web strings. It usually produces smaller output than gzip for text content, which is why most browsers and CDNs support it for HTTPS traffic.

The built-in dictionary is the main difference from gzip. It holds common words and HTML, CSS and JavaScript fragments, so short text files compress well even without much repeated content of their own.

How does Brotli work in HTTP?

A client advertises the formats it accepts in the Accept-Encoding request header, and the server marks a compressed response with Content-Encoding: br. The client then decodes the body before handing it to the application.

The same header can appear on a request. Some APIs and proxies accept Brotli-compressed request bodies and decompress them before the application sees them. That means a decoder can sit in two places:

• On the server side, decoding request bodies that clients upload.
• On the client side, decoding responses from servers your code contacts.

The second case is easy to miss. A server can send a Brotli response even when the client did not ask for one, so dropping br from Accept-Encoding does not reliably keep a vulnerable client safe.

Where does Brotli run in a typical environment?

Brotli runs anywhere software compresses or decompresses web traffic, and it is usually bundled inside other software instead of installed on its own. A server that never had a "brotli" package installed can still run several copies.

Common places it hides, based on the products named in the CVE-2026-111497 advisories:

• JavaScript runtimes. Node.js and Bun each ship a Brotli decoder in their compression modules.
• Proxies and service meshes. Envoy can decompress Brotli traffic, and Istio ships Envoy as its sidecar.
• Application frameworks. .NET includes Brotli support for request decompression and HttpClient.
• Language packages. In Python, the Brotli and brotlicffi packages are picked up automatically by urllib3, requests, aiohttp and httpx when installed.
• Tools and libraries. curl builds, Git for Windows, FFmpeg (through libjxl), ClickHouse and Apache Arrow have all bundled Brotli code.
• Operating system packages. Linux distributions ship a shared libbrotli that some programs link against.

Why is a decompression library a security risk?

A decompressor parses untrusted input, often before any authentication or validation happens. Parsers written in memory-unsafe languages such as C are a common source of buffer overflows, and Brotli's reference decoder is written in C.

Decompression also tends to run early in a request pipeline. A proxy may decode a request body before your application code, your input validation or your logging sees it. If the decoder is the vulnerable component, the controls behind it never get a chance to act.

In CVE-2026-111497, the decoder treated an invalid block switch as a temporary shortage of input instead of a format error, and kept appending data to an eight-byte internal buffer. The fix in Brotli 1.0.10, 1.1.1 and 1.2.1 makes the decoder fail cleanly.

Brotli compression vs gzip: does the choice matter for security?

Both formats need a decoder that parses attacker-supplied data, so neither is safe by default. The real security question is how many copies of each decoder you run and how quickly each one gets patched.

Gzip relies mostly on zlib, which is widely shared through system packages. Brotli is more often vendored into runtimes, proxies and packages, so a single Brotli flaw can mean a long list of separate updates. Our guide on how to find vulnerable Brotli copies on your systems covers how to inventory them.

What should you do with this?

• Know where Brotli decoding happens. List the services that accept compressed request bodies and the services that fetch external URLs. Those are the two exposure paths.
• Track Brotli as a dependency. Make sure your software composition analysis or SBOM tooling reports bundled copies, not just the system package.
• Turn off what you do not use. If a proxy or framework decompresses request bodies and your application never receives compressed uploads, disabling that feature removes a parser from the attack path.

Bundling makes patching slower, and the reasons go beyond Brotli. We cover the planning side in why patching bundled libraries takes more than one update.