The Brotli decoder in Google's Brotli library, versions 1.0.3 through 1.2.0, does not stop when a compressed stream contains an invalid block switch. A crafted Brotli stream makes the decoder continue with corrupted state and write past its buffer. A remote, unauthenticated attacker can use this to crash the process, read memory or potentially run code.
Any software that decompresses Brotli data from an untrusted source is exposed, in both directions: a server that decodes request bodies sent with Content-Encoding: br, and a client that decodes Brotli responses from a server it does not control. A client is exposed even if it does not advertise br in Accept-Encoding, because a malicious server can send a Brotli response anyway. Affected software includes the system Brotli library (libbrotli) and everything that loads it, Node.js, Bun, Envoy and Istio, .NET, the Python Brotli and brotlicffi packages (which urllib3/requests, httpx and aiohttp use automatically when installed), Java brotli4j, the Ruby brotli gem and PHP brotli extension, and curl/libcurl builds with Brotli support. Applications that bundle or statically link Brotli stay vulnerable until they are rebuilt with a fixed version.
Several Linux distributions have no fixed package yet. Until you can update, block the path to the decoder:
Content-Encoding contains br before the body is decoded. Match case-insensitively, including inside lists of encodings.br from Accept-Encoding and also disable Brotli response decoding, or reject responses with Content-Encoding: br before they are decoded. Changing Accept-Encoding alone is not enough.--compressed, and leave CURLOPT_ACCEPT_ENCODING unset (NULL) in applications. curl -V lists brotli under Features when the build can decode...1.1.1-r01.0.7-2+deb10u21.0.9-2+deb11u11.2.1-1.fc43Exploitability
AV:NAC:LAT:PPR:NUI:NVulnerable System
VC:HVI:HVA:HSubsequent System
SC:NSI:NSA:N9.2/CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N