I feel as though this should be googlebrotli2shell, not http2shell. Google deserves to take a bit of a reputational hit for this. This is a basic memory safety violation, from the same organization that does wuffs, that promotes Rust for memory safety, that has Carbon. zstd has high quality rust implementations and is from roughly the same time.
On top of that, the brotli library saw no releases for almost a full year, with the fix for this vulnerability being committed back in February. Google builds from main for all their projects, so were unaffected, but open source releases are a complete afterthought. Over 100 commits with miscellaneous fixes left languishing until a security incident forces a release.
On the decompression side yes, on the compression side the first good zstd rust port was announced yesterday. Until then, brotli was better supported in Rust than zstd.
But I agree, decompression libraries should be (mostly) memory safe nowadays, since that side is both easier to implement and more likely to be vulnerable.
Is there ever a demo of the "2shell" aspect here? Seems like the issue was fixed because it was thought to produce a hang. Has it ever been confirmed that the issue could result in an RCE? Or is this just hypothetical?
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.)
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.
The RCE was a know thing on Wednesday, without too much info. People started putting mitigation and orgs with valuable websites were shutting down servers.
Look at liveoverflow channel. Took him a good day with LLMs to find an exploit against a vanilla PHP instance.
It isn't a straightforward hack. But it is possible.
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.
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)
CVSS is a terrible proxy for vulnerability real world impact. Not to mention, that CVE with CVSS 10.0 in Bob's Flower Names library with 5 users is probably not that important.
mirashii 1 day ago
On top of that, the brotli library saw no releases for almost a full year, with the fix for this vulnerability being committed back in February. Google builds from main for all their projects, so were unaffected, but open source releases are a complete afterthought. Over 100 commits with miscellaneous fixes left languishing until a security incident forces a release.
CodesInChaos 1 day ago
On the decompression side yes, on the compression side the first good zstd rust port was announced yesterday. Until then, brotli was better supported in Rust than zstd.
But I agree, decompression libraries should be (mostly) memory safe nowadays, since that side is both easier to implement and more likely to be vulnerable.
kccqzy 18 hours ago
mirashii 13 hours ago
https://www.imperva.com/blog/node2shell-from-brotli-data-to-...
There's also a public POC here, though with the caveat that they demonstrated it only on builds with weaker configurations. https://github.com/dimasma0305/CVE-2026-111497-POC
All that said, we haven't heard the major cloud providers or security labs saying they've seen exploitation in the wild yet.
pjmlp 23 hours ago
However I guess testing isn't that great, probably.
ataraxia937 1 day ago
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.)
guac 1 day ago
babuskov 1 day ago
shakna 1 day ago
If so, might be vulnerable.
Don't have Brotli enabled? Not vulnerable to this.
Koffiepoeder 1 day ago
FreakLegion 1 day ago
It'll happen sooner or later, but all signs are that this was first and foremost a process nightmare. It wasn't another Log4Shell.
olabyne 19 hours ago
FreakLegion 10 hours ago
bbor 1 day ago
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?
deathanatos 1 day ago
Sure, people should check their dependency trees, and make informed decisions.
bbor 1 day ago
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!
vinyl7 1 day ago
bbor 1 day ago
anonymous908213 1 day ago
aaronbrethorst 1 day ago
ks2048 1 day ago
nevir 1 day ago
cowlevel 1 day ago
duxup 1 day ago
I actually kinda like how that works.
my-huge-pony 1 day ago
lovich 1 day ago
vinkelhake 1 day ago
judge2020 1 day ago
Waterluvian 1 day ago
mhio 1 day ago
weinzierl 1 day ago
card_zero 1 day ago
rvanlaar 1 day ago
The python package has already been updated to 1.2.1. https://pypi.org/project/brotli/1.2.1/
Gigachad 1 day ago
Another day another out of bounds access in C code.
ks2048 1 day ago
red75prime 1 day ago