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.)
I can't find download numbers for extras, but it comes in the pretty dang innocuous-seeming `aiohttp[speedups]`, as well. Also `urllib3[brotli]`. Many, many people will be running these servers without recognizing the name of the library, especially in the agentic era.
I might be missing something obvious in your message, cause I don't see why server/client is relevant. Why would a frontend app speak a protocol that the backend doesn't?
That's just the total number of times that package was downloaded, which is completely unrelated to how many servers it appears in? Same with `aiohttp`: aiohttp can be used as a client library.
Sure, people should check their dependency trees, and make informed decisions.
We should start naming them like hurricanes: NIST creates a list of alphabetical names and assigns any CVE >= 9.0 with a name. Vulnerability Alex (CVE 9.4)
I feel like normal security issues don't get much publicity. The PHP and eMudhra issues seemed severe, and worth publicity. But then with things like this, I'm not sure. Is this a severe issue? Or is it just a run of the mill issue that's only newsworthy because web security is on people's minds right now?
The whole industry is on edge right now, and numbers wise the CVE count has exploded beyond belief. It's probably to take the side of caution, treat everything as important and update everything promptly rather than the old way of doing things where libraries are left months or years out of date until something happens.
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.
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development
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.
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.)
I mean, I dare say the 4,200,000 Python servers built yesterday alone with this package might disagree...? https://pypistats.org/packages/brotli
I can't find download numbers for extras, but it comes in the pretty dang innocuous-seeming `aiohttp[speedups]`, as well. Also `urllib3[brotli]`. Many, many people will be running these servers without recognizing the name of the library, especially in the agentic era.
I might be missing something obvious in your message, cause I don't see why server/client is relevant. Why would a frontend app speak a protocol that the backend doesn't?
That's just the total number of times that package was downloaded, which is completely unrelated to how many servers it appears in? Same with `aiohttp`: aiohttp can be used as a client library.
Sure, people should check their dependency trees, and make informed decisions.
How did you check? Is there are PoC or some kind of command to run?
I could do without every memory bug getting a cute sensational name and marketing push, I have to say.
that ship sailed a while ago. Rowhammer is the first one I can remember
Let's not forget about heartbleed!
That was the first exploit logo I can recall
The most memorable one for me is DirtyCOW.
Back in the email days the virus authors named them, e.g. YouAreAnIdiot, ILoveYou
The Blaster virus was a fun one.
We should start naming them like hurricanes: NIST creates a list of alphabetical names and assigns any CVE >= 9.0 with a name. Vulnerability Alex (CVE 9.4)
I feel like normal security issues don't get much publicity. The PHP and eMudhra issues seemed severe, and worth publicity. But then with things like this, I'm not sure. Is this a severe issue? Or is it just a run of the mill issue that's only newsworthy because web security is on people's minds right now?
The whole industry is on edge right now, and numbers wise the CVE count has exploded beyond belief. It's probably to take the side of caution, treat everything as important and update everything promptly rather than the old way of doing things where libraries are left months or years out of date until something happens.
It looks like brotli <= 1.2.0 is vulnerable.
The python package has already been updated to 1.2.1. https://pypi.org/project/brotli/1.2.1/
This is the fix commit https://github.com/google/brotli/commit/b418fa81c48262a86a95...
Another day another out of bounds access in C code.
There’s apparently no writeup on exactly what was the fix. So I’m going to make a guess that this is the chromium commit that fixed the problem: https://source.chromium.org/chromium/chromium/src/+/224140d4...
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.
Interestingly the commit that fixes this in brotli dates back to February https://github.com/google/brotli/commit/0ed4268a4401abcb4472...
OpenAI's tweet says it wasn't recognized as security relevant so wasn't important enough to make a release - until their agent realised it was.
https://nitter.jaydenha.uk/OpenAI/status/2113766354386084338
Until their agent realised there was a good chance of a press release in it.
Chat, we need to constantly be justifying our absolutely absurd IPO. Use UltraMegThink and reference the ExploitToGetUsRegualtoryCapture.md. kkthnx
Since I checked Rust servers should be fine since the brotli crate is not a binding on the C.
Is Deno affected, too? It uses brotli by default. But I don’t know how it is implemented.
Deno is dead (baby)
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development
https://deno.com/blog/cloudflare
They just keep coming, don't they?
Never gonna stop. Consider it normal. Hey, at least humans still have a job. Incident response
Let's not kid ourselves, llm's are already doing the incident response for this in many infrastructure teams
But they don't respond with fear and flailing arms!
For as long as we still have C code accessible to the internet.
Likely mitigation: disable brotli (br) content-encoding on both sides
Unfortunately, AFAICT, there is no way to do this for node's fetch. I suspect there are other client libraries that don't have a way to disable it.
Here's the normal link:
https://x.com/AikidoSecurity/status/2113759110625906950
This is a better article: https://www.aikido.dev/blog/python-packages-vulnerable-node2...
and this is the actual CVE report, which doesn't say much: https://www.cve.org/CVERecord?id=CVE-2026-111497
is flask hello world with gunicorn behind apache vulnerable?
what I can say is that a 5 liner hello world starting with ‘import socket’ is not affected
whether a hello wolrd in fastapi is affected might also be interesting
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.
> refusing br content-encoding at the edge seems like the fastest mitigation.
That's pretty difficult if you make outbound requests, and don't already have a TLS interception proxy set up.
This is an AI karmabot comment, it should remain flagged
Another day, another buffer-overflow vulnerability in C code …
No language is safe, not even Rust
https://news.ycombinator.com/item?id=50069499
Edit: why flagged
> Edit: why flagged
Rust Derangement Syndrome is at epidemic levels here.
Check history, unconstrained
https://x.com/AikidoSecurity/status/2113759110625906950
Brotli, another one of those pseudostandards[1] from Big G that I was avoiding all along. Dodged another bullet.
[1] When more than half of the "standard" https://www.rfc-editor.org/info/rfc7932/#page-44 is an opaque binary blob, they're really not encouraging independent implementations.