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?
ataraxia937 17 minutes ago [-]
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?
anonymous908213 1 hours ago [-]
I could do without every memory bug getting a cute sensational name and marketing push, I have to say.
lovich 1 hours ago [-]
that ship sailed a while ago. Rowhammer is the first one I can remember
vinkelhake 1 hours ago [-]
Let's not forget about heartbleed!
mhio 58 minutes ago [-]
That was the first exploit logo I can recall
weinzierl 15 minutes ago [-]
The most memorable one for me is DirtyCOW.
judge2020 44 minutes ago [-]
Back in the email days the virus authors named them, e.g. YouAreAnIdiot, ILoveYou
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.
is flask hello world with gunicorn behind apache vulnerable?
cpburns2009 29 minutes ago [-]
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.
TZubiri 2 hours ago [-]
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
DogeGode 2 hours ago [-]
Another day, another buffer-overflow vulnerability in C code …
cowlevel 1 hours ago [-]
[flagged]
bogomind 2 hours ago [-]
[flagged]
bibekadhikari 1 hours ago [-]
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.
thayne 40 minutes ago [-]
> 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.
cowlevel 28 minutes ago [-]
This is an AI karmabot comment, it should remain flagged
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?
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.
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.
https://nitter.jaydenha.uk/OpenAI/status/2113766354386084338
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.
https://x.com/AikidoSecurity/status/2113759110625906950