Comment by ataraxia937
7 hours 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.)
Doesn't node's fetch call the decoder automatically for `br` responses? So any attacker controlled content that a server fetch's may be vulnerable?
How did you check? Is there are PoC or some kind of command to run?
Is your Brotli library built from older than the February commit? (The last tagged release is before then.)
If so, might be vulnerable.
Don't have Brotli enabled? Not vulnerable to this.
The PHP thing is exploitable by now. No specific conditions needed. Stop spreading misinformation.
There were no known breaches or end-to-end exploits as of Friday. I've seen LLM hallucinations purporting to be exploits and real exploits missing pieces (address leaks), but nothing complete. Friends at some of the bigger IR practices (CrowdStrike CAO, Unit 42, Talos) have said the same thing.
It'll happen sooner or later, but all signs are that this was first and foremost a process nightmare. It wasn't another Log4Shell.
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.
Ok putting aside the "client" thing again assuming I'm just behind the times on python client-server architecture norms: What kind of vulnerability would concern you?
Sure, we can't say for sure that all 4 million of the jobs who downloaded (not built-with, but downloaded to cache anew) this library yesterday are running public-facing servers. But what subset of them might be? How much would it take before it's a concern?
Python feels particularly worrisome to me, as those are the kind of casually-setup servers on local dev boxes for some random little tool that are the most fertile ground for an exploit like this, where creds could be spread around in plaintext and malware could go unnoticed for a long time. And, of course, where the developers responsible probably aren't in the habit of watching the CVE list (yet...).
I hope I'm not coming across as rude -- I am honestly curious!
The whole package manager system is a complete disaster. A huge number of dependencies are pulled in that go unused in most projects, so the number of downloads is an extremely unreliable number. I'd be surprised if more than 10% of those downloads actually use the brotli decoder.
Well first off I love PyPI and am greatly offended on the behalf of thew newly-formed (forming?) council to fix it, but also I don't think that applies in this case. If your server is capable of decoding brotli packets it's at risk -- you don't have to actually use that functionality regularly.