This one again feels overblown, at least for servers. I just checked an org of over 200 GitHub repos. Node, Python, and C#. None of them are vulnerable... because none of them actually call the Brotli decoder. It's just not enabled by default on the server side, by the platforms themselves. This is much like the PHP bugs, where specific conditions have to be in play before you're actually vulnerable.
For clients? Sure, that's a bigger risk. Patch them. But bad guys aren't attacking your clients unless the clients connect to them. Don't stay up late to fix this.
(And yes, .NET is included here, because Microsoft's Brotli module is a binding for Google's vulnerable reference implementation.)
And this commit contained a refactoring from BROTLI_BOOL to BrotliDecoderErrorCode so the situation was that probably one of the error conditions previously simply returned false but needed more detail about what went wrong to continue safely.
Well okay this change from `if (prev_ix < cur_ix)` to `if (prev_ix < cur_ix && cached_backward <= max_backward)` is also suspicious and could be an related or unrelated hardening fix.
Only decompression with Google's brotli library is affected. So if you use "Brotli" or "brotlicffi" in your Python app to decompress brotli, you're vulnerable. Compressing responses with brotli from Apache is safe.
Worth checking how brotli actually reaches your stack. In Node it's bundled into the runtime itself (zlib's brotli support), so an audit of your package tree won't surface it the way a normal dependency would - the fix arrives with a runtime release, not a package bump. The Python package on PyPI is already at 1.2.1. Until your runtime picks up the patched brotli, refusing br content-encoding at the edge seems like the fastest mitigation.
For clients? Sure, that's a bigger risk. Patch them. But bad guys aren't attacking your clients unless the clients connect to them. Don't stay up late to fix this.
(And yes, .NET is included here, because Microsoft's Brotli module is a binding for Google's vulnerable reference implementation.)
And this commit contained a refactoring from BROTLI_BOOL to BrotliDecoderErrorCode so the situation was that probably one of the error conditions previously simply returned false but needed more detail about what went wrong to continue safely.
Well okay this change from `if (prev_ix < cur_ix)` to `if (prev_ix < cur_ix && cached_backward <= max_backward)` is also suspicious and could be an related or unrelated hardening fix.
The python package has already been updated to 1.2.1. https://pypi.org/project/brotli/1.2.1/
Another day another out of bounds access in C code.
https://nitter.jaydenha.uk/OpenAI/status/2113766354386084338
https://x.com/AikidoSecurity/status/2113759110625906950
and this is the actual CVE report, which doesn't say much: https://www.cve.org/CVERecord?id=CVE-2026-111497
whether a hello wolrd in fastapi is affected might also be interesting
That's pretty difficult if you make outbound requests, and don't already have a TLS interception proxy set up.