Rendered at 17:45:28 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
pimterry 1 days ago [-]
Much prefer the Broccoli2Shell name & site (for the same vuln): https://broccoli2shell.com/. For starters, I'm pretty sure you can hit this without HTTP if you do any manual Brotli decoding, HTTP just happens to be the most common case that comes up.
Why do critical vulnerabilities get a cutesy name and website nowadays? Who’s paying for these sites?
Flere-Imsaho 2 hours ago [-]
The same reason we name storms and hurricanes... It's easier to raise awareness, and refer to these things after the fact. More memorable then CVE-whatever.
I find it helpful at least...
cyphar 11 hours ago [-]
This has been the case for more than a decade, Heartbleed was probably the one which really created the trend.
10 hours ago [-]
sbarre 24 hours ago [-]
Small static websites are effectively free (Cloudflare, GCP free tier, etc)..
reassess_blind 22 hours ago [-]
Domains aren’t
DaSHacka 2 hours ago [-]
Most domains are only like ~$10/year. I already have a handful registered for potential project ideas because they're borderline free, for major vulnerabilities I would do the same.
mynameisvlad 22 hours ago [-]
Sure, but domains aren't going to be more than $10 or $20 for the year they're relevant.
ygjb 18 hours ago [-]
\o/
1. See a vuln domain reported, clone the site.
2. Wait for it to expire and snag it.
3. Republish the site with malware
4. Watch people dither about domain names and stuff instead of taking time to fix things.
ygjb 18 hours ago [-]
Sure they are. The domain you want isn't.
GitHub.io domains, workers.dev domains, etc are all free domains.
Clever use and abuse of some startups can get you a free domain with a signup package that you can subsequently transfer out, but those are harder to find these days.
Seriously, the bad guys figure this out all the time.
cubefox 1 days ago [-]
I'm certainly not complaining about some selfless guy making a helpful website without expecting anything in return!
nicce 23 hours ago [-]
They excpect fame and may make things look worse than they are
mynameisvlad 22 hours ago [-]
How, exactly, are they making "things look worse than they are"? By.... showing what the issue is?
nicce 21 hours ago [-]
Not particularly referencing to this link, but usually severity is made more severe than it actually is. One kind of sensationalism is usually used.
cubefox 21 hours ago [-]
No, they aren't. The website doesn't list an author, so fame is out of the question, and they say exactly how severe the bug is rated ("Rated 9.2 Critical (CVSS 4.0) by GitHub, High by Node.js.") right at the top.
nicce 20 hours ago [-]
There is named entity in the end, and "we" statement. But yeah, I was speaking in general, not so specifically about this page. It is better than most who do this.
TZubiri 1 days ago [-]
Are you asking why do we name things? In a programming forum?
solyin 11 hours ago [-]
Listen. There are TWO problems, okay‽
TZubiri 3 hours ago [-]
Wasn't it three?
yallpendantools 2 hours ago [-]
Last I heard it was 10 or 11 but definitely not 0x3.
23 hours ago [-]
tclancy 5 hours ago [-]
You remember CVEs by heart? Do you even bother using DNS?
o_m 23 hours ago [-]
It is annoying (and ironic) because larger companies, that will benefit from this information the most, blocks newly registered domains.
illusive4080 4 hours ago [-]
Yep, this website was blocked at my work all day yesterday despite me submitting it for review.
DaSHacka 2 hours ago [-]
Protip, use the Wayback Machine as a proxy to get around firewalls if you only need to view content from a static site.
My work blocks every commercial AI service, but I just want to read the static blogs and benchmarks from the large labs to keep up with recent news and developments in the space and the Wayback Machine trick works perfectly for that.
nayuki 12 hours ago [-]
I see some irony here. For a period of time, Google chose not to include JPEG XL in Chrome because vulnerabilities in the library could compromise the software - a legitimate concern. Yet, Google is the author of the Brotli data compression format a decade before the JPEG XL drama, and was happy to use it in Chrome and encourage others to use the library, despite the fact that it also increases the attack surface.
gsnedders 1 hours ago [-]
Things like Rust in Chromium weren’t even being talked about back when Brotli was introduced to Chromium.
I think Chromium as a project would be happier if they had less unsafe code in general, and holding new dependencies (especially those like media formats, which have a long history of security issues) to that standard doesn’t seem particularly surprising.
There’s always going to be trade-offs: how much benefit does this provide (users, developers) compared with how much risk does it incur (safe/unsafe code, quantity of code you’re now on the line for the security of).
(And that’s taking that reason to not support JPEG XL at face value, ignoring any debate about it.)
progbits 7 hours ago [-]
1. People change their minds over time.
2. JXL is waaay more complex than Brotli so the risk of vulnerable implementation is also higher.
They should have demanded more rigor from the Brotli library, same for countless other dependencies chromium has. But there's no irony.
cxcorp 5 hours ago [-]
Brotli reduces their compute costs, whereas JPEG XL reduces storage which at least historically is cheaper than compute?
gsnedders 1 hours ago [-]
From a browser point-of-view, the real questions are about data size (if you can get the wireless interface back to a low power state, you’re winning on power benchmarks), about decompression cost (again, power benchmarks), and decompression time (for performance benchmarks and user-perceived performance).
Storage and compression compute costs aren’t really relevant — only insofar as if there’s very little adoption, the security risk of exposing the code is there but isn’t providing user benefit.
wat10000 3 hours ago [-]
This is getting real close to "yet you participate in society, curious." Yes, Google chose not to use some software and chose to use other software. It's not ironic to decline to use some software because it increases the attack surface, and then find out that it's not enough and the software you did choose to use is vulnerable. It's just unfortunate.
Rapzid 1 days ago [-]
> reported it as unauthenticated remote code execution that works in both directions
> but it wasn't recognized as a security issue at the time and no release shipped with the fix until now
I'm always getting my dangerous RCE bugs mixed up with my harmless RCE bugs.
I'm curious how this was reported and fixed back in Feb but nobody recognized the importance. A case of AI automation and nobody at the wheel?
wavemode 23 hours ago [-]
I'm not seeing any source for the claim that OpenAI discovered this in February. The source that the article links (a tweet by OpenAI) doesn't claim that.
soiax 5 hours ago [-]
Exatly, it was patched silently, OpenaAI just discovered that patch, and that it has upstream effects in NodeJS etc.
bawolff 1 days ago [-]
To me, the surprising part is how many of these implement brotli compression of request (not just response) bodies, given how obscure a feature that is.
In any case all this sensationalism is starting to get annoying. Patch your stuff and move on.
Edit: actually, between all the sensationalism, its hard to tell from the article how many of these actually support brotli compressed request bodies in common configs vs some other use of brotli (which is bad but nowhere near as critical)
ArcHound 1 days ago [-]
I think the issue is that the servers "silently" support brotli. Then nobody uses it, but the attacker can still abuse the feature.
So as a hotfix I block this on my reverse proxy.
bawolff 1 days ago [-]
But is that actually true?
It seems like node supports it with body parser enabled.
But im having trouble finding any docs suggesting anything else supports it on inbound requests.
Obviously there are other scenarios where it is exploitable, but it is a much less severe vuln if the attacker must first force the program to make an outbound request to a server of its chosing rather than just connect to a vulnerable server.
ArcHound 1 days ago [-]
The idea is to identify brotli encoding in the content-encoding header and block that on nginx. This shouldn't reach vulnerable brotli parser in node.
I hope my assets are not connecting to malicious servers, otherwise yes, I have a problem.
Rapzid 1 days ago [-]
Asp.Net adds Brotli support if you "UseRequestDecompression" or "UseResponseCompression".
DotNet, however, has it's own C# Brotli implementation.
dboreham 24 hours ago [-]
According to Claude when I asked it to audit one of our Python applications, there are scenarios where Brolti can be used only when some Python library detects that the C library is installed on the system. So your Brolti-ness can depend on which machine your code runs on. Ymmv, it didn't look to be a practical possibility in our code so I didn't probe further.
bscphil 30 minutes ago [-]
The only reply to this criticizes the hedging, but I think it's actually true and it does make it harder to tell if you're vulnerable to this. And on top of that, quite a few systems have brotli installed by necessity. On Debian 12, for example, I have the following dependency chain on a VPS I run:
These chat bots always hedge like that. They will never give you a straight answer, it's always "depending on version and build configuration and system configuration".
Investigate yourself. Read the documentation. Grep for brotli in the source. Don't blindly trust a chat bot when it says it "might happen in certain configurations".
DaSHacka 2 hours ago [-]
I've noticed the newer frontier models are a lot better about this and are willing to give concrete answers, where before even in 90/10 scenarios they would always be wishy-washy espousing the "it depends on the circumstances" BS.
dboreham 23 hours ago [-]
Chat bot lol. It did all of those things including scanning the binary. I ran it after doing my own (albeit more limited, but maximal-human) investigation.
mort96 23 hours ago [-]
Is that meant to be a response to what I wrote or did you reply to the wrong comment
AlienRobot 1 days ago [-]
I wonder if we'll see more of this thanks to AI. Extremely complex features that nobody uses and that were easy to add, which incidentally tremendously expand the attack surface. One would hope that maintainer would be wise to avoid that, but for how long?
fock 23 hours ago [-]
https://github.com/tmux/tmux/pull/5709/changes it is already happening. Nice 50 lines of C-code to add support for kernel-keyrings which no userland software uses and literally is a one-line config-option.
ArcHound 1 days ago [-]
I think so, especially vibe coded software. I think hackers have the advantage now and defenders need to limit attack surface more rigorously.
Unfortunately that means understanding and limiting dependencies of developers... Yea, good luck.
My popcorn is ready. My servers are not.
whoanoway 1 days ago [-]
I'm not saying that my experience translates 1:1. As a child of domestic violence, all I can say is that it never gets better. Sadly, my feeling is that the violence will only escalate from here. If you look at the bright side, you can earn your stripes as a legitimate infosec engineer and prove your worth to the industry and the world.
ArcHound 1 days ago [-]
I'm sorry that happened to you. I tend to agree that the race to the bottom will continue.
And don't worry about my stripes, I'm mostly talking about my hobby self-hosted apps. If anything, should someone hack them I'll have a funny article to post on my blog. Professionally, I do things differently.
bflesch 1 days ago [-]
Cloudflare has this amazing feature where it accepts compressed payloads and forwards them to unsuspecting backends. Can be weaponized in many ways.
therein 22 hours ago [-]
My experience with Brotli is from back when all the hype was mobile first and India etc was super mobile first so all these social networks lost their mind optimizing for request success and speed. So they were going crazy over micro-wins like that.
nairboon 1 days ago [-]
Brotli2Shell seems to be a more appropriate name for this.
mkl 1 days ago [-]
Not when you're prioritising sensationalism over accuracy. Everyone's heard of HTTP, but hardly anyone's heard of brotli.
A few month ago, everyone was advising to use cool-downs in your package upgrades. Now we're constantly overriding those because security incidents will be exploited immediately.
Guess that's just how it's gonna be from now on.
gsnedders 1 hours ago [-]
A cooldown is a coarse way to deal with “supply chain security” — and that’s mostly a question of how much you trust your dependencies.
You may well (and probably should) trust the maintainers and release process of Brotli, Node.js, PHP, etc. security releases more than you trust some-random-JS package deep in your front end dependency graph.
You want to reduce the risk of introducing a compromised dependency into your product, and that’s largely a question of how much you trust upstream.
acdha 18 hours ago [-]
That's why it's important to practice your processes for both shipping quickly and overriding cooldowns. There's a baseline of things which are not easy to exploit where you want to patch on a regular cadence and the risk posed by a supply chain attack is greater than the risk of an attacker having enough of a footprint inside your systems to escalate. The fact that sometimes you have a specific situation like this where that's not true doesn't mean that 9 times out of 10 the cooldown was the better risk-reduction strategy.
medler 1 days ago [-]
It used to be a flex to say you deploy daily but it’s going to become a necessity just to keep up with the vulns
ManuelKiessling 1 days ago [-]
CI/CD — Continuous Incidents, Continuous Defense.
mort96 24 hours ago [-]
Yeah, obviously? Deploy fixes to security issues which apply to you as soon as possible, deploy random feature additions and non-critical bug fixes after some cooldown.
As always, the easiest way to manage this is to have as few dependencies as possible. If you have a lockfile with thousands of entries, you won't be able to go through them and decide which upgrades are legitimate urgent security updates and which can wait. If you have 10? You'll manage.
da_chicken 5 hours ago [-]
Exactly.
Security fixes for actively exploited vulnerabilities demand an emergency response. The risk of introducing new, unknown flaws is less than risk of having an active known exploited vulnerability.
However, absent the risk of a KEV, that changes the equation. Now the risks of code changes causing breaking changes plus the risk of supply chain attacks is greater than the risk of having to put some thought and time in to manage your software library versions.
It's not like AI created this distinction, either. Neither did CI/CD. This is standard systems administration -- literally ISO/IEC 20000 ITSM. It's exactly why, traditionally, new features are often limited to major versions. It's why binary compatibility was a huge issue with RHES 20 years ago, and why distros pin versions and backport security and selective bug fixes. A developer that doesn't know this is telling on themselves why they shouldn't have write access to production. Stability matters a lot because we like to get paychecks.
cowsandmilk 1 days ago [-]
Article claims OpenAI found this in February, but I don’t think that’s correct. I think Google made a change to the Brotli source code in February that fixes the issue, but hadn’t realized it was a security issue and therefore hadn’t cut a release.
Rapzid 1 days ago [-]
Yeah that doesn't make a lot of sense that they reported it but also nobody knew it was a security issue..
Maybe an LLM just happened to do one of those "while I'm here" fixes in Feb and because nobody reviews anything anymore..
"Fixed reading too many bytes."
LGTM!
Edit: I was close! "Detect and report invalid stream earlier." Could have been a person.
serious_angel 1 hours ago [-]
Thank you! Of course! I do believe these cases are dreams for LLM vendors to advertize themselves regardless truth, and many believe trends over actual evidence...
Please do consider sharing the actual evidence to keep in the history, and respect actual human authors involved, their effort, time, and humane attitude... for discoveries, competition, actual achievements to learn from and get inspiration...
tetha 1 days ago [-]
Well at least we know about it while or before the giant patch effort for everything else goes on. Just put it onto the pile.
Who turned on hard mode this week?
loloquwowndueo 1 days ago [-]
Nah man. We were on casual mode all along. This is the new normal.
hahn-kev 5 hours ago [-]
IMO this should be Brotli2Shell if anything
skeledrew 1 days ago [-]
I've just been pointing a Claude Code at these things as they pop up. A great time to not have to worry about chasing all these things manually.
semiquaver 1 days ago [-]
Let’s say I have a node.js app behind an Amazon elastic load balancer which terminates TLS. My understanding is that in nearly all configurations, my app would be unaffected because the ELB would handle decompression. Is that generally correct?
chrismorgan 1 days ago [-]
I don’t know about that specific software, but I would be surprised if it decoded message bodies, which is entirely unrelated to TLS termination and shouldd be entirely unrelated to routing. So I would expect you would still be vulnerable.
aleaph 1 days ago [-]
Yep, I don't think too many people are exposing their python/node servers directly, it should be always behind a proxy or a fancy cloud LB.
Apache and nginx don't handle brotli out of the box.
valleyer 7 hours ago [-]
Your two sentences basically contradict one another, no? Apache doesn't handle brotli, so it will pass the compressed body to the underlying server undecoded, which means the underlying server is effectively exposed to attacks on this bug, if it does brotli decode on the body.
thisisauserid 1 days ago [-]
[dead]
Rapzid 19 hours ago [-]
Ubuntu still has libbrotli1 patch under review as medium. This is holding up updates to libcurl and thus git and a whole bunch of other stuff.
misiek08 12 hours ago [-]
They’ll have it for few months and then make you pay to get the update.
upofadown 1 days ago [-]
An example of the cost of added complexity I suppose. Brotli is much more complicated than the gzip/deflate it replaces. ... and of course we still have to expose gzip to attack as well.
Every time you add something you lose something...
> Security notice: Upgrade certifi, pip, and uv in response to CA certificate incident
Blimey PIP is affected? That's bad. I feel like that should have been bigger news?
skeledrew 1 days ago [-]
Because pip uses it's own certificate bundle, so even if you fix the system itself pip still needs its own upgrade to handle the eMudhra episode.
zahlman 12 hours ago [-]
~~Recent versions of pip use `truststore` by default to access the system's certificates, only relying on the vendored `certifi` as a fallback or if explicitly directed.~~
Users of uv who have already updated their system certificates can use:
UV_SYSTEM_CERTS=true uv self update
tetha 1 days ago [-]
And strictly speaking you cannot trust the pip upgrade of pip with the vulnerable cert in the trust store due to certifi, which you also cannot upgrade safely with pip for the same reason. All of these are at one out of two compromises from being MITM'd during the upgrade.
So strictly we have to burn everything python to the ground and reinstall entirely.
saltcured 1 days ago [-]
Heh. This is part of why I always preferred getting my python runtime and all these core libs from my linux distro packager. But python die-hards look at me like I'm insane when I suggest this.
Even in today's LLM-addled world, I still think it's a better tradeoff for smaller system/site operators. Get the distro-level testing and regular auto-patching, rather than telling yourself it is a good idea to "freeze" your python world at the pace of your slowest app/system integrator.
It's the same reason I think docker is an anti-pattern for these small groups. You really cannot safely use these strategies to bake an image and divorce yourself from the maintained distro layer unless you are going to adopt CI/CD that does the same thing. Keep tracking all these patches to the entire runtime with all the dependencies, rebuild, re-test, and redeploy.
It's total cargo culting to adopt the freeze/image techniques and just abandon apps in place as if that is robust!
But, it's also more than just automatically updating everything. There is an editorial aspect to distro management to help secure the supply chain to your app. Most smaller orgs cannot feasibly do this as well as the regular linux distro maintainers. Some large orgs can probably do it better, but that doesn't matter if you aren't doing it large org style with dedicated security folks tracking all this against well-developed policies and procedures...
zahlman 12 hours ago [-]
> But python die-hards look at me like I'm insane when I suggest this.
They have a point. The distro is only carrying a small fraction of what's available on PyPI, and will have out-of-date versions that may lack security patches (and for projects like yt-dlp, are highly unlikely to work at all). Realistically they aren't applying security backports; there would rarely be a reason not to just use the new version, and the resources just aren't there for that scale of patching anyway.
Further, pip will interfere with your system package manager's tracking of the system environment (PEP 668), and any attempt you make to install from .deb/.rpm/etc. to a virtual environment is a hack at best. Maybe you could symlink individual package folders to the system environment while installing a superset, but ugh. Oh, and if you're a developer (like most "Python die-hards" are) then this isn't very helpful, as you aren't testing the installation of your package the way that your users will do it.
saltcured 1 hours ago [-]
The mitigation is to ignore nearly all that stuff in PyPI, realizing it is barely a step up from copy-pasting out of stack overflow. Same goes for, e.g. python-whatever RPMs that look like they were drive-by contributions.
So your trusted base is the Python runtime and maybe a few choice libraries that actually have engaged package management. Sadly, it is a trap to think you can put things on the internet as a small player by leveraging lots of third-party stuff, when you don't have the resources to actually maintain that large dependency base.
This also may mean you want a base OS like Fedora and not some crusty "enterprise" variant that tries to bundle a frozen Python from 15 years ago. This is getting a little better in recent years, with some enterprise platforms having optional package streams for parallel install of newer runtime versions, etc.
Edit to add: on the Fedora-derived platforms, pip doesn't really interfere much anymore. The platform python-* RPMs go into /usr/lib/... while pip installs into /usr/local/lib/... or your ~/.local/lib/... hierarchy. The only mysterious behavior you get is if you manage to install in both places and then you have to understand the path search order. Just like if you do strange things with user and virtual environments.
zbentley 46 minutes ago [-]
Eh, it's a personal choice and a not unreasonable position to take, but there are a lot of things on PyPi that aren't packaged by e.g. Debian. Database clients, immensely popular frameworks, scientific computing libraries ...
Basically once you leave the realm of the 5-10 most popular building blocks in an area (which OS packagers do distribute), you're still left with plenty of packages that have 10ks+ of users, sane maintainer/security/ownership models, and code that would be very difficult to just copy-paste a la stackoverflow (e.g. native/compiled deps with complex wheel build tooling).
saltcured 28 minutes ago [-]
Yes, that's why I left wiggle room for a few choice packages you track yourself.
What isn't really tenable for a small team is to drag in scores to hundreds of different third-party packages and rely on them all when you have no staff allocated to really evaluate and monitor so much upstream stuff.
graemep 22 hours ago [-]
I agree about getting libs (binaries especially) from my distro, and it generally seems to be regarded as the "wrong thing to do". Freezing anything that might mean you get security updates slower seems to be a mistake to me.
aftbit 1 days ago [-]
Or - you can just upgrade pip with a SHA hash pin, or set the magic env vars to use the system bundle.
You do need to be careful about creating new venvs with the old version of pip bundled in ensurepip in older Python releases. `uv` kindly patches that to newest pip, but not every Python binary does.
I had a pretty fun time with it myself. Rather than a system package for pip, or the `ensurepip`-provided one, I've been using the copy managed by pipx. I had to:
* Update system certificates
* Locate that pip and directly invoke it to self-update with hash pinning, rather than going through pipx
* Fix a few stray venvs that contained their own pip
* Use the fixed pipx to update uv (although I guess the uv self-update should work even for a pipx-installed copy?)
The legacy-certs hint is neat. I did it the first way but would rather not have since I'm on Mint.
tetha 22 hours ago [-]
Good to know. Does the first invocation recompute and check the hash of the wheel locally afterwards to ensure integrity?
aftbit 22 hours ago [-]
Yep! I tested it with my own vibe-coded MITM proxy that hijacks pypi installations, which I created for ~$0.30 spend on DeepSeek API.
$ python -m pip --no-cache install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
Collecting pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70
Downloading pip-26.2.2-py3-none-any.whl (1.8 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 570.0 MB/s 0:00:00
ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70 from https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70:
Expected sha256 fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70
Got 8c448177668e735cdde7d6178694b90c084ba18559348cc394c4b1546eeec89c
The second one works too:
$ PIP_USE_DEPRECATED=legacy-certs PIP_CERT=/etc/ssl/certs/ca-certificates.crt python -m pip install --no-cache --upgrade "pip>=26.2.2"
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082)'))': /simple/pip/
Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1082) - skipping
ERROR: Could not find a version that satisfies the requirement pip>=26.2.2 (from versions: none)
ERROR: No matching distribution found for pip>=26.2.2
As compared with a naive installation through the proxy:
Oh nice. Then I have to thank you for a possible non-horrible upgrade path. If you were close by, I'd invite you for some icecream or a round of pool :)
zahlman 12 hours ago [-]
> All of these are at one out of two compromises from being MITM'd during the upgrade.
This is not true; pip supports hash pinning, so an attacker would have to be able to defeat SHA256 as well (or compromise both the official Python discussion forum and PyPI itself, so as to forged the published hash). Other hashes can also be used. Instructions are provided on the Python discussion forum to self-upgrade pip with hash pinning: https://discuss.python.org/t/information-for-python-users-re...
steve1977 1 days ago [-]
Python certificate handling is a hot mess, even by Python standards.
zahlman 12 hours ago [-]
Commentary like this adds nothing to the discussion and is simply provocative. Please don't.
steve1977 9 hours ago [-]
Provocative of what? Thinking about the issues that Python has? Why would that be a problem?
It IS a mess and it's causing problems again and again in real life. And it is particularly bad with Python. I don't see why this should not be pointed out.
murderfs 1 days ago [-]
Pretty sure that's the eMudhra "private key is 4" issue.
anttihaapala 1 days ago [-]
I had to check all of our Python deployments and installation BOMs and was quite relieved - turns out that none actually installed brotli libraries. HTTP libraries like httpx, requests and frameworks consider them optional and autodetect their presence.
zbentley 38 minutes ago [-]
...which points to an area where Python has a significant drawback: optional/accelerator dependencies are loaded via try/except-ImportError. That's suboptimal for a bunch of reasons:
- If a vulnerable dependency is in your environment as a transitive of something that's not at risk (e.g. code you don't use, code that doesn't talk to untrusted sites), code that shouldn't use it will pick up that transitive.
- Autodetection of optional stuff is often silent. E.g. libxml vs. pure-python XML parsing doesn't really act any different at load time or most of runtime, besides being faster, so it's non-obvious what's being used when.
- Probing for packages that aren't listed as a concrete dependency by importable name risks loading unintended code due to name conflicts (malicious, or accidental/caused by local files with the same name or weird PYTHONPATH).
- There are plenty of ways to get an ImportError after running a lot of Python code in a dependency before giving up! That code might mutate global state/change behavior, or do insecure things, etc. Malicious actors could take advantage of ImportError being raiseable by user code to conceal naughty behavior at import time.
I really want Python to come up with a saner way to concretely identify (avoiding name conflicts) and probe for optional dependencies at import time. try/except-ImportError ain't it.
doublerabbit 4 hours ago [-]
Cool. C is going to become that cool forgotten forbidden programming language.
gok 21 hours ago [-]
This is yet another example of the incredible negative impact of Google’s pattern of crapping out open-source libraries without actually maintaining them, so that people just copy and paste them into their projects.
RachelF 21 hours ago [-]
Pretty much everything that talks http has this Brotli library linked in. A quick file search on a Windows dev box showed:
- git
- Sublime text
- VS studio
- CUDA
- .NET
- inkscape
- AzureTools
perching_aix 1 days ago [-]
git for windows is vulnerable even in its latest release (2.56.0.windows.3), careful pulling repos over https from random ass servers (prolly uncommon but hey). they already merged the fix on the repo, it's just in a snapshot build only; should prolly arrive on Monday (2.56.0.windows.4).
also affects codex (gui), which ships its own git, could be more of a problem there, when the LLMs get quirky at night. still unlikely to be a problem though.
speaking of, update codex (and wipe its cache at ~/.cache/codex-runtimes), ships its own node. update python.
stuff like wireshark and imhex remain vulnerable, even on their latest repo commits, which may or may not be spicy.
also Microsoft 365 Copilot still has its own unpatched brotlidec.dll from Oct 7, if anyone uses that. no fix available for that one afaik, not sure about how it can be made to access the vulnerable decoder.
andersonpico 1 days ago [-]
why is this downvoted? are any of those not accurate?
hiitsmyaccount 1 days ago [-]
Because a local software vuln is much less scary, less exploitable, and more common than an exploit like PHP2Shell, which requires basically no effort to exploit a large chunk of publicly exposed webservers. Basically, local vulns have been a thing forever and GP is off topic.
perching_aix 1 days ago [-]
the article above is about a defect in google's brotli compression library (CVE-2026-111497). compression libraries don't really do web serving, or communicate with networked resources at all, they're hermetic. so exposure depends on the context this library is deployed in as a dependency.
put it in the network path, it can become an RCE.
put it in a privileged context, it can become privilege escalation.
put it in a hardened environment, it can become completely inert.
in no sane perspective is me listing off the applications shipping with vulnerable versions of this codec off-topic. just because the article is hellbent on portraying this as some sort of second php2shell, the actual underlying issue here is still CVE-2026-111497.
truelson 19 hours ago [-]
So, uh, isn’t the blast radius huge here? Like ticking time bomb for unpatched servers huge once someone figures out how to craft their br payload just right?
Browsers were patched back in March, but if you can get anything else that is unpatched to decode br, and most HTTP clients do by default, and you’ve figured out the right payload (yes not easy, but still), isn’t this, well, really bad? Like Heartbleed big?
davedx 1 days ago [-]
Honestly it's time to get rid of C as a language used where security is a factor. Enough already. Why the hell is a lib like brotli that processes public general internet traffic, and maintained by google, not in rust?
thephyber 1 days ago [-]
Security is a factor everywhere. And C is everywhere. There's not going to be a "rewrite everything in Rust" project until after there is some legit penalty for selling / offering software in C that could be more secure in another language.
I think Mozilla got it right when they abandoned the effort to rewrite the entire browser in Rust and instead focused on analysis of which modules needed priority rewrites. If a module has historically had zero memory-related bugs, then there are other higher priority things to spend time on.
That said, Google Project Zero should have had Brotli on their radar. Hopefully they still have people and resources.
gsnedders 1 hours ago [-]
I’ll point out that Servo was always a research project — any thought of it replacing Gecko was an incredibly long-term stretch goal. It was _a lot_ more interested in “can we write a high-performance browser engine in Rust” (there’s a reason why it significantly predates Rust 1.0 — they were very much developed together!) and “can we implement parallelism in places where browsers historically have not” (because you have more guarantees of safety).
Chromium _has_ been replacing certain components with ones in safe languages, and it seems like that will continue slowly (with integrating them into the existing codebase, with web compatibility risk of any changes in behaviour, with the risk of performance and power regressions).
anthk 2 hours ago [-]
Asterinax. RustPyhon. PHP 8.5 rewrite in Rust. FFMPEG and Qemu might follow soon.
It's inevitable.
_flux 1 days ago [-]
I can understand why people used a C library for these apps, as when HTTP2 was specified, the C lib was the only game in down.
"In 2016, the Brotli algorithm shipped in Chrome, delivering overall better compression ratios for eligible resources."
"By the end of 2017, all modern browsers supported Brotli, and server support for it started to become more widespread."
For www users, all that data collection, surveillance and ad services traffic to enrich so-called "tech" companies acting as intermediaries, can make the www exceedingly slow
The way to "make the web faster" (or less inefficient) is to get rid of that needless traffic, and the ads it supports
SPDY,^1 HTTP/2 Server Push,^2 HTTP/3 QPACK,^3 brotli, .... make www users ("ad targets" to Google) uninformed, nonconsenting subjects in Google's failed experiments
The www already works just fine for its intended purpose (_not_ data collection, surveillance and ad services)
I agree with you, but the immediate problem here seems to be that all major browsers support Brotli, and i think they all use the Google library, so they are all vulnerable.
Most of the discussion here is about vulnerabilities in servers, but it looks like its mostly a client problem.
Is there a way to turn brotli off?
Going back to your point, if we kept things simple we would be a lot more secure.
1vuio0pswjnm7 22 hours ago [-]
"OpenAI found this in February reported it as unauthenticated remote code execution that works in both directions, so a malicious client can take over an unpatched server and a malicious server can take over an unpatched client that accepts compressed responses."
Every user is different
For me I'm a text-only user not interested in graphics
I do not use a so-called "modern" browser to make HTTP requests
I don't request brotli-compressed content/resources^1
Normally I don't send an Accept-Encoding header
Almost always servers to which I connect^2 will return uncompressed text, which is what I want. No Accept-Encoding header needed
Occasionally servers will send gzip-compressed text by default and will ignore "Accept-Encoding: identity"
However the popular so-called "modern" browsers will send an Accept-Encoding header whose value includes brotli (br) by default
Unsuspecting www users are consequently opted in to Google's brotli experiment. Me, I opt out
1. I use a text-only browser (1.3MB static binary) to read HTML. I compile it without brotli support
2. Other users may connect to different servers. Preferences vary from user to user
rfgplk 1 days ago [-]
As I've mentioned numerous times at this point, relying on third party code is a massive liability (supply chain attacks/sloppy code). My hand rolled brotli implementation is not only faster than libbrotli but also immune to this vulnerability (yes, I checked). Roll your own code people.
zbentley 34 minutes ago [-]
Please feel free to publish and/or link to your alternative implementation. Many eyes can help with identifying security/functionality issues, and if your implementation proves superior to libbrotli in general, this area of the ecosystem is in dire need of diversity.
ethin 1 days ago [-]
Would you also apply this to cryptography or, well, really any security library? Because I hope the answer will be no...
jgalt212 1 days ago [-]
How may web servers only serve brotli?
How many clients only accept brotli?
michaelbuckbee 1 days ago [-]
Well it's negotiated, right?
So say you run a SaaS that allows for something like letting people set their Avatar from an image URL which gets downloaded.
As an attacker I setup a new server that serves only brotli and then submit that URL to the SaaS.
gsnedders 1 hours ago [-]
There’s both request compression (no negotiation) and response compression (negotiated).
cowlevel 1 days ago [-]
Just send a POST with Content-Encoding:br to any URL and hope it gets decided before the URL route is checked.
jgalt212 1 days ago [-]
> So say you run a SaaS that allows for something like letting people set their Avatar from an image URL which gets downloaded.
That's a clever example, but why would you do that? The avatar should be a static resource. As such, I'd only provide an upload file dialog.
thephyber 1 days ago [-]
Gravitar was super popular for a year or two.
Quit being overly pedantic about how contrived the example is and struggle with the underlying fact that the compression type is negotiated between the client and server. If the compression happens on the HTTP request (as some of the comments here suggest), then the server must use that compression method or it fails to read the body of the request.
jgalt212 19 hours ago [-]
> how contrived the example is
That's basically one of the core ingredients of security. Build a threat model.
ceejayoz 1 days ago [-]
Lots of apps will, for example, bring in your Google avatar (i.e. they fetch its URL for ingestion) as a default avatar if you use them for SSO. Slack included, IIRC.
CJefferson 24 hours ago [-]
I can almost certainly make my browser submit its file upload POST with the compression of my choice and your server will accept it.
jgalt212 19 hours ago [-]
apache does not accept brotli by default. so while the first part is true, the second part is only true for some X% of websites.
netsharc 1 days ago [-]
Well, whoever picked the name HTTP2Shell certainly didn't use any intelligence, artificial or genuine.
It's so meaningless, broad and undescriptive of the actual issue. No it probably doesn't affect an HTTP server with nothing else behind it, so why is HTTP being blasted?
You might as well call it Exploit Pro Max...
vanschelven 6 hours ago [-]
Should have definitely been Brotli2Shell, but Google ingeniously managed to dodge that bullet by having NodeJS come out with a fix before they did (others might call that accidental exposure), and then barely communicating about that with the broader community once they finally did. Here's a timeline of events[0] and here's me more broadly complaining about Google's stance[1]
I think we've all seen where an LLM names a session, issue, or PR based on its early understanding and fails update it later.
AI isn't being asked to review the title, and it doesn't have experience or think, so of course it's not going to flag it.
No human reviews anything anymore so of course they aren't going to catch it.
Edit: AI for as good as it is at "writing" is terrible at writing and particularly at naming things. I had an AI name a client OpenAICompatibleEmbeddingClient. "Brooooo.. I think "compatible" is implied, who names stuff like that?!"
rafram 21 hours ago [-]
That means that it supports other services with OpenAI-compatible embeddings APIs (not just OpenAI's own API). Seems reasonable!
ketzu 8 hours ago [-]
`OpenAICompatible` is also a widely used phrasal description of a part/version of the OpenAI API that is supported by quite a lot of endpoints.
I can maybe remember CVE-2026. But there is no way I can remember 6 random digits.
ygjb 18 hours ago [-]
Yeah, because the six number chunk is near the limit of recall. Don't remember CVE-2026 since the year and CVE can be reconstructed from time memory. You know it came up this year. Remember that vuln 111-497 (as two chunks) came out this year, and remembering two short chunks is easier.
latexr 3 hours ago [-]
I don’t know why you’d want to remember the number, but this one seems easy if you know some memory techniques.
> Remember that vuln 111-497 (as two chunks)
Good first step. Remember it’s two sets of three numbers. The first set is all ones, meaning the first three numbers are 1, then the fourth number is 4, then you add five for the next one (9), then you have to remember to subtract two (7)¹.
May sound silly, but I bet some of you have already memorised it from that alone. Being a slightly convoluted by still logical set-by-step helps with recollection.
¹ Lot of different ways to go about that, like remembering that the first set was three of one so “two was left out”.
N19PEDL2 1 days ago [-]
Or EUVD-2026-108169.
cowlevel 1 days ago [-]
Actually it does, if the server is willing to decompress POST bodies.
croes 1 days ago [-]
Brotli bodies, so Brotli2Shell
SkiFire13 11 hours ago [-]
And only those using Google's Brotli implementation.
jwilk 8 hours ago [-]
What are the other implementations?
techpression 1 days ago [-]
I immediately thought HTTP/2 was having a bad day somehow. Might I suggest Software2Shell to be less confusing.
CharlieDigital 1 days ago [-]
Specifically Brotli2Shell
photios 1 days ago [-]
google2shell would have been nice :D
anilakar 1 days ago [-]
Alt-tabbing from browser to terminal and back has always felt exhausting. Nice.
devsda 1 days ago [-]
With ad served malware, this wouldn't be the first time though :)
reddozen 1 days ago [-]
The author clearly used super intelligence.
Stitch4223 16 hours ago [-]
You and I, my friend, are the only ones in this thread not being sent to work in the glitter mines of south Arkansas as enemies of God's Country. SI has the best names, other intelligence is vastly inferior, using it is worse than many schisms of -isms combined.
TZubiri 1 days ago [-]
It looks like marketing HTTP2Shell seems to appeal to everyone that uses HTTP, while Brotli2Shell might not wake up people that know what it is.
Now, whether it's warranted or not, that's another matter, but they know how to appeal for maximum awareness/interaction.
hulitu 7 hours ago [-]
> while Brotli2Shell might not wake up people that know what it is.
And, most of all, is damaging to Google, which are the master of software engineering. /s
llm_nerd 5 hours ago [-]
I mean...who cares? It's actually kind of strange that your comment got others talking about AI naming things.
SQL Slammer didn't actually slam anything, and applied to a single vendor among many SQL providers. Heartbleed didn't make anyone's heart bleed...I mean, at least directly. Shellshock only impacted a single shell environment, again among many. Log4Shell impacted a single logging implementation, among many. Spectre and Meltdown...I mean, who would think that related to CPU cache side channels?
These are just dumb names for people to share in referring to something. Seems silly and like a waste of time to spend effort getting upset about them.
groundzeros2015 1 days ago [-]
All these names are silly. It's just marketing.
sigmarule 1 days ago [-]
There are levels of silliness, and this has achieved a new one.
TacticalCoder 1 days ago [-]
I really don't understand how so many different things are affected by the same brotli bug/exploit.
I even read the patch for the C code (patch which, btw, seems a bit hacky to me with isSafe? methods added and whatnots but YMMV: now I understand things had to be patched in a hurry but this patch really looks like "lipstick on a buffer overflowing C pig" to me).
What's the link between Python / Node / C++ / libbrotli / Envoy / Bun: are those some all using the same C brotli encoder/decoder?
Can someone who knows more explain why all those are vulnerable?
> As for unaffected software, Apache’s standard mod_brotli does not decode Brotli
Because this one only encodes and doesn't decode and the bug is in the decoder? (for I take it mod_brotli, with such a name, still does something brotli related and isn't, say, a TOTP token generator nor a SAT solver?).
I mean overall, sheesh: could we get better explanation / better writeups when such big fuckups happen?
Rapzid 1 days ago [-]
Yes. All these language runtimes compile against common libraries. Compression libs are one of the most common common libraries that platforms like node, ruby, dotnet, python, and etc need to compile.
Google provides the Brotli implementation. Package maintainers slurp that up and create ie libbrotli-dev. When you compile node it uses that for brotli support.
thephyber 1 days ago [-]
Brotli was a library released by the Google team that developed it. There weren't lots of independent implementations; they were all from the same source code.
rfgplk 1 days ago [-]
Or you can roll your own and not rely on the literal disaster that Google developed. Brotli is trivial to implement.
thephyber 33 minutes ago [-]
Well did you?
Your comment is irrelevant to mine. I stated what is, while you stated what ought to be.
It's trivial to make any open source repo that nobody uses. It's hard to get people to adopt your library over one supported by one of the world's largest companies.
devdudejeremy 1 days ago [-]
[flagged]
chelseahermes 1 days ago [-]
[flagged]
Zestymarble45 1 days ago [-]
[flagged]
nly 7 hours ago [-]
[dead]
1 days ago [-]
austin-cheney 1 days ago [-]
Why are we still so reliant on HTTP? HTTP came out in 1990 (36 years ago) and the most common version of HTTP still in use, 1.1 (RFC2616), came out in 1999 (27 years ago)?
Yes, I know HTTP 2 and 3 and SSE are attempts to make it faster and more parallel, but its still slow. Its slow because its unidirectional with a full round trip and by default its a new socket per each message. Yes, I know the real reason HTTP became and remains popular is because its sessionless... in theory. Still, there are better options available. You can do so much more with a full duplex channel.
singpolyma3 1 days ago [-]
We don't need new versions of http or SMTP because they're already simple and great and they're dumb protocols so there's not much you could ever add
If you want something else you can take your pick based on need from dozens of other options
cowlevel 1 days ago [-]
HTTP 1 is full of parser differential vulnerabilities, which 2 fixes. That is probably its biggest flaw.
SMTP is too chatty - it uses too many round trips for efficient transfer across the internet. It can take several seconds just to get to the point of sending the email data. It also duplicates information between the SMTP envelope and the email body which creates vulnerabilities when they don't match.
For APIs that don't have to work in a browser I suggest JSON lines over TCP, or over TLS.
rfgplk 1 days ago [-]
Most header parsing bugs that affect HTTP1.1 can also affect 2+3. Not in the same style but there are quite a few overlapping ones.
gsnedders 1 hours ago [-]
Header parsing, sure. But message framing bugs are much more likely with HTTP/1.1.
cowlevel 23 hours ago [-]
Only when 2/3 translates to 1, as in request smuggling attacks at a reverse proxy.
cowlevel 1 days ago [-]
"by default its a new socket for each message" is misinformation - keepalive is the default since HTTP 1.1 (1999).
austin-cheney 1 days ago [-]
Keep alive is not default behavior, so my prior comment was still more correct.
tredre3 23 hours ago [-]
All webservers (apache, nginx, litespeed, caddy) have keep-alive enabled by default. All browsers also support it. Whether it's actually used/negotiated on most connections, I don't know, and if you want to be pedantic you're right that it can't be default by definition since you need the header to use it. But I suspect it actually is used for most connections nowadays.
Multiplexing is the default in HTTP/2 and 3. So you're still wrong.
So, for the sake of argument let’s say I am completely wrong, MDN is wrong, all of Stack Overflow is also wrong. Even still HTTP is slow. Slow as shit. Imagine trying to do a MS Teams call with 50+ participants with cameras on. It would be slow as shit for just a one-on-one call. A call with 50+ people would be ridiculously slower and would likely result in a crash from memory exhaustion.
I was also not talking about HTTP2 or 3. I was very clear about that. Reading is hard. HTTP is used in many different contexts outside the browser where 1.1 continues to dominate.
The primary reason developers want to keep HTTP around is familiarity and comfort. HTTP is great when you don’t compare to anything else or do any kind of performance tuning.
cowlevel 23 hours ago [-]
Keepalive is literally the default. You have to send an additional header if you don't want to use keepalive.
rfgplk 1 days ago [-]
Agreed. The issue with all these archaic standards is that they were rolled decades ago back when certain practices were either outright not being employed OR that hardware wasn't fast enough. Ironically, HTTP itself is a literal nightmare to parse (performance wise) on top of having like... ten? distinct vulnerability classes. The world desperately needs new standards.
cowlevel 1 days ago [-]
Just open a TCP socket and send JSON messages. Or if you want a bit more efficiency, fixed-format binary messages, but remember to include a version number.
rfgplk 1 days ago [-]
For custom server implementations, agreed. But the web still depends on HTTP and we sadly need the major infra providers to agree on a new standard otherwise HTTP isn't going anywhere
cowlevel 23 hours ago [-]
Web uses web protocols, notweb uses notweb protocols. When I write an XMPP bot it has to speak XMPP, not HTTP. I could write my video game server to use XMPP but why the heck would I do that? If I choose a badly fitting protocol, it's on me.
graemep 22 hours ago [-]
I think one problem there is that a lot of places block other ports. Was that not why websockets runs on http ports?
cowlevel 16 hours ago [-]
Websockets have to be careful not to enable a client-side SSRF by accessing anything you couldn't already access with an <img> tag. They can use any port except the ones that are generally prohibited for browser HTTP requests, such as 25 and 6667.
I find it helpful at least...
1. See a vuln domain reported, clone the site. 2. Wait for it to expire and snag it. 3. Republish the site with malware 4. Watch people dither about domain names and stuff instead of taking time to fix things.
GitHub.io domains, workers.dev domains, etc are all free domains.
Clever use and abuse of some startups can get you a free domain with a signup package that you can subsequently transfer out, but those are harder to find these days.
Seriously, the bad guys figure this out all the time.
My work blocks every commercial AI service, but I just want to read the static blogs and benchmarks from the large labs to keep up with recent news and developments in the space and the Wayback Machine trick works perfectly for that.
I think Chromium as a project would be happier if they had less unsafe code in general, and holding new dependencies (especially those like media formats, which have a long history of security issues) to that standard doesn’t seem particularly surprising.
There’s always going to be trade-offs: how much benefit does this provide (users, developers) compared with how much risk does it incur (safe/unsafe code, quantity of code you’re now on the line for the security of).
(And that’s taking that reason to not support JPEG XL at face value, ignoring any debate about it.)
2. JXL is waaay more complex than Brotli so the risk of vulnerable implementation is also higher.
They should have demanded more rigor from the Brotli library, same for countless other dependencies chromium has. But there's no irony.
Storage and compression compute costs aren’t really relevant — only insofar as if there’s very little adoption, the security risk of exposing the code is there but isn’t providing user benefit.
> but it wasn't recognized as a security issue at the time and no release shipped with the fix until now
I'm always getting my dangerous RCE bugs mixed up with my harmless RCE bugs.
I'm curious how this was reported and fixed back in Feb but nobody recognized the importance. A case of AI automation and nobody at the wheel?
In any case all this sensationalism is starting to get annoying. Patch your stuff and move on.
Edit: actually, between all the sensationalism, its hard to tell from the article how many of these actually support brotli compressed request bodies in common configs vs some other use of brotli (which is bad but nowhere near as critical)
So as a hotfix I block this on my reverse proxy.
It seems like node supports it with body parser enabled.
But im having trouble finding any docs suggesting anything else supports it on inbound requests.
Obviously there are other scenarios where it is exploitable, but it is a much less severe vuln if the attacker must first force the program to make an outbound request to a server of its chosing rather than just connect to a vulnerable server.
I hope my assets are not connecting to malicious servers, otherwise yes, I have a problem.
DotNet, however, has it's own C# Brotli implementation.
grub-pc -> grub-common -> libfreetype6 -> libbrotli1
which is really nasty.
Investigate yourself. Read the documentation. Grep for brotli in the source. Don't blindly trust a chat bot when it says it "might happen in certain configurations".
Unfortunately that means understanding and limiting dependencies of developers... Yea, good luck.
My popcorn is ready. My servers are not.
And don't worry about my stripes, I'm mostly talking about my hobby self-hosted apps. If anything, should someone hack them I'll have a funny article to post on my blog. Professionally, I do things differently.
You may well (and probably should) trust the maintainers and release process of Brotli, Node.js, PHP, etc. security releases more than you trust some-random-JS package deep in your front end dependency graph.
You want to reduce the risk of introducing a compromised dependency into your product, and that’s largely a question of how much you trust upstream.
As always, the easiest way to manage this is to have as few dependencies as possible. If you have a lockfile with thousands of entries, you won't be able to go through them and decide which upgrades are legitimate urgent security updates and which can wait. If you have 10? You'll manage.
Security fixes for actively exploited vulnerabilities demand an emergency response. The risk of introducing new, unknown flaws is less than risk of having an active known exploited vulnerability.
However, absent the risk of a KEV, that changes the equation. Now the risks of code changes causing breaking changes plus the risk of supply chain attacks is greater than the risk of having to put some thought and time in to manage your software library versions.
It's not like AI created this distinction, either. Neither did CI/CD. This is standard systems administration -- literally ISO/IEC 20000 ITSM. It's exactly why, traditionally, new features are often limited to major versions. It's why binary compatibility was a huge issue with RHES 20 years ago, and why distros pin versions and backport security and selective bug fixes. A developer that doesn't know this is telling on themselves why they shouldn't have write access to production. Stability matters a lot because we like to get paychecks.
Maybe an LLM just happened to do one of those "while I'm here" fixes in Feb and because nobody reviews anything anymore..
"Fixed reading too many bytes."
LGTM!
Edit: I was close! "Detect and report invalid stream earlier." Could have been a person.
Please do consider sharing the actual evidence to keep in the history, and respect actual human authors involved, their effort, time, and humane attitude... for discoveries, competition, actual achievements to learn from and get inspiration...
Who turned on hard mode this week?
Apache and nginx don't handle brotli out of the box.
Every time you add something you lose something...
> Security notice: Upgrade certifi, pip, and uv in response to CA certificate incident
Blimey PIP is affected? That's bad. I feel like that should have been bigger news?
The above is incorrect per the Python forum discussion (https://discuss.python.org/t/information-for-python-users-re...). Pip will trust certificates from both sources.
Users of uv who have already updated their system certificates can use:
So strictly we have to burn everything python to the ground and reinstall entirely.
Even in today's LLM-addled world, I still think it's a better tradeoff for smaller system/site operators. Get the distro-level testing and regular auto-patching, rather than telling yourself it is a good idea to "freeze" your python world at the pace of your slowest app/system integrator.
It's the same reason I think docker is an anti-pattern for these small groups. You really cannot safely use these strategies to bake an image and divorce yourself from the maintained distro layer unless you are going to adopt CI/CD that does the same thing. Keep tracking all these patches to the entire runtime with all the dependencies, rebuild, re-test, and redeploy.
It's total cargo culting to adopt the freeze/image techniques and just abandon apps in place as if that is robust!
But, it's also more than just automatically updating everything. There is an editorial aspect to distro management to help secure the supply chain to your app. Most smaller orgs cannot feasibly do this as well as the regular linux distro maintainers. Some large orgs can probably do it better, but that doesn't matter if you aren't doing it large org style with dedicated security folks tracking all this against well-developed policies and procedures...
They have a point. The distro is only carrying a small fraction of what's available on PyPI, and will have out-of-date versions that may lack security patches (and for projects like yt-dlp, are highly unlikely to work at all). Realistically they aren't applying security backports; there would rarely be a reason not to just use the new version, and the resources just aren't there for that scale of patching anyway.
Further, pip will interfere with your system package manager's tracking of the system environment (PEP 668), and any attempt you make to install from .deb/.rpm/etc. to a virtual environment is a hack at best. Maybe you could symlink individual package folders to the system environment while installing a superset, but ugh. Oh, and if you're a developer (like most "Python die-hards" are) then this isn't very helpful, as you aren't testing the installation of your package the way that your users will do it.
So your trusted base is the Python runtime and maybe a few choice libraries that actually have engaged package management. Sadly, it is a trap to think you can put things on the internet as a small player by leveraging lots of third-party stuff, when you don't have the resources to actually maintain that large dependency base.
This also may mean you want a base OS like Fedora and not some crusty "enterprise" variant that tries to bundle a frozen Python from 15 years ago. This is getting a little better in recent years, with some enterprise platforms having optional package streams for parallel install of newer runtime versions, etc.
Edit to add: on the Fedora-derived platforms, pip doesn't really interfere much anymore. The platform python-* RPMs go into /usr/lib/... while pip installs into /usr/local/lib/... or your ~/.local/lib/... hierarchy. The only mysterious behavior you get is if you manage to install in both places and then you have to understand the path search order. Just like if you do strange things with user and virtual environments.
Basically once you leave the realm of the 5-10 most popular building blocks in an area (which OS packagers do distribute), you're still left with plenty of packages that have 10ks+ of users, sane maintainer/security/ownership models, and code that would be very difficult to just copy-paste a la stackoverflow (e.g. native/compiled deps with complex wheel build tooling).
What isn't really tenable for a small team is to drag in scores to hundreds of different third-party packages and rely on them all when you have no staff allocated to really evaluate and monitor so much upstream stuff.
You do need to be careful about creating new venvs with the old version of pip bundled in ensurepip in older Python releases. `uv` kindly patches that to newest pip, but not every Python binary does.
Or alternatively, on Debian with fixed system cert chain: https://discuss.python.org/t/avoiding-compromised-certificat...* Update system certificates
* Locate that pip and directly invoke it to self-update with hash pinning, rather than going through pipx
* Fix a few stray venvs that contained their own pip
* Use the fixed pipx to update uv (although I guess the uv self-update should work even for a pipx-installed copy?)
The legacy-certs hint is neat. I did it the first way but would rather not have since I'm on Mint.
This is not true; pip supports hash pinning, so an attacker would have to be able to defeat SHA256 as well (or compromise both the official Python discussion forum and PyPI itself, so as to forged the published hash). Other hashes can also be used. Instructions are provided on the Python discussion forum to self-upgrade pip with hash pinning: https://discuss.python.org/t/information-for-python-users-re...
It IS a mess and it's causing problems again and again in real life. And it is particularly bad with Python. I don't see why this should not be pointed out.
- If a vulnerable dependency is in your environment as a transitive of something that's not at risk (e.g. code you don't use, code that doesn't talk to untrusted sites), code that shouldn't use it will pick up that transitive.
- Autodetection of optional stuff is often silent. E.g. libxml vs. pure-python XML parsing doesn't really act any different at load time or most of runtime, besides being faster, so it's non-obvious what's being used when.
- Probing for packages that aren't listed as a concrete dependency by importable name risks loading unintended code due to name conflicts (malicious, or accidental/caused by local files with the same name or weird PYTHONPATH).
- There are plenty of ways to get an ImportError after running a lot of Python code in a dependency before giving up! That code might mutate global state/change behavior, or do insecure things, etc. Malicious actors could take advantage of ImportError being raiseable by user code to conceal naughty behavior at import time.
I really want Python to come up with a saner way to concretely identify (avoiding name conflicts) and probe for optional dependencies at import time. try/except-ImportError ain't it.
- git
- Sublime text
- VS studio
- CUDA
- .NET
- inkscape
- AzureTools
also affects codex (gui), which ships its own git, could be more of a problem there, when the LLMs get quirky at night. still unlikely to be a problem though.
speaking of, update codex (and wipe its cache at ~/.cache/codex-runtimes), ships its own node. update python.
stuff like wireshark and imhex remain vulnerable, even on their latest repo commits, which may or may not be spicy.
also Microsoft 365 Copilot still has its own unpatched brotlidec.dll from Oct 7, if anyone uses that. no fix available for that one afaik, not sure about how it can be made to access the vulnerable decoder.
put it in the network path, it can become an RCE.
put it in a privileged context, it can become privilege escalation.
put it in a hardened environment, it can become completely inert.
in no sane perspective is me listing off the applications shipping with vulnerable versions of this codec off-topic. just because the article is hellbent on portraying this as some sort of second php2shell, the actual underlying issue here is still CVE-2026-111497.
Browsers were patched back in March, but if you can get anything else that is unpatched to decode br, and most HTTP clients do by default, and you’ve figured out the right payload (yes not easy, but still), isn’t this, well, really bad? Like Heartbleed big?
I think Mozilla got it right when they abandoned the effort to rewrite the entire browser in Rust and instead focused on analysis of which modules needed priority rewrites. If a module has historically had zero memory-related bugs, then there are other higher priority things to spend time on.
That said, Google Project Zero should have had Brotli on their radar. Hopefully they still have people and resources.
Chromium _has_ been replacing certain components with ones in safe languages, and it seems like that will continue slowly (with integrating them into the existing codebase, with web compatibility risk of any changes in behaviour, with the risk of performance and power regressions).
However, why not switch to the Rust lib when it was available? I suppose people at Dropbox are now pretty happy they did in 2016: https://dropbox.tech/infrastructure/lossless-compression-wit...
It's slower, though. Too high a price to pay for safety it seems.
There is a cost to conversion.
Dropbox switched to it a decade ago, so it's probably quite product-ready.
"By the end of 2017, all modern browsers supported Brotli, and server support for it started to become more widespread."
For www users, all that data collection, surveillance and ad services traffic to enrich so-called "tech" companies acting as intermediaries, can make the www exceedingly slow
The way to "make the web faster" (or less inefficient) is to get rid of that needless traffic, and the ads it supports
SPDY,^1 HTTP/2 Server Push,^2 HTTP/3 QPACK,^3 brotli, .... make www users ("ad targets" to Google) uninformed, nonconsenting subjects in Google's failed experiments
The www already works just fine for its intended purpose (_not_ data collection, surveillance and ad services)
1. "As of 2021, no major browsers supported SPDY" https://en.wikipedia.org/wiki/SPDY
2. https://en.wikipedia.org/wiki/HTTP/2_Server_Push
3. https://foxio.io/blog/header-accordions-qpack-amplification-...
Most of the discussion here is about vulnerabilities in servers, but it looks like its mostly a client problem.
Is there a way to turn brotli off?
Going back to your point, if we kept things simple we would be a lot more secure.
Every user is different
For me I'm a text-only user not interested in graphics
I do not use a so-called "modern" browser to make HTTP requests
I don't request brotli-compressed content/resources^1
Normally I don't send an Accept-Encoding header
Almost always servers to which I connect^2 will return uncompressed text, which is what I want. No Accept-Encoding header needed
Occasionally servers will send gzip-compressed text by default and will ignore "Accept-Encoding: identity"
However the popular so-called "modern" browsers will send an Accept-Encoding header whose value includes brotli (br) by default
Unsuspecting www users are consequently opted in to Google's brotli experiment. Me, I opt out
1. I use a text-only browser (1.3MB static binary) to read HTML. I compile it without brotli support
2. Other users may connect to different servers. Preferences vary from user to user
How many clients only accept brotli?
So say you run a SaaS that allows for something like letting people set their Avatar from an image URL which gets downloaded.
As an attacker I setup a new server that serves only brotli and then submit that URL to the SaaS.
That's a clever example, but why would you do that? The avatar should be a static resource. As such, I'd only provide an upload file dialog.
Quit being overly pedantic about how contrived the example is and struggle with the underlying fact that the compression type is negotiated between the client and server. If the compression happens on the HTTP request (as some of the comments here suggest), then the server must use that compression method or it fails to read the body of the request.
That's basically one of the core ingredients of security. Build a threat model.
It's so meaningless, broad and undescriptive of the actual issue. No it probably doesn't affect an HTTP server with nothing else behind it, so why is HTTP being blasted?
You might as well call it Exploit Pro Max...
[0] https://www.bugsink.com/blog/http2shell-timeline/
[1] https://news.ycombinator.com/item?id=50230362
https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c147
AI isn't being asked to review the title, and it doesn't have experience or think, so of course it's not going to flag it.
No human reviews anything anymore so of course they aren't going to catch it.
Edit: AI for as good as it is at "writing" is terrible at writing and particularly at naming things. I had an AI name a client OpenAICompatibleEmbeddingClient. "Brooooo.. I think "compatible" is implied, who names stuff like that?!"
- https://lmstudio.ai/docs/developer/openai-compat
I've seen that used as a description for 2years or so.
Which they will happily do if you ask them "why" they did something. 100% they will give their best "well actually" impression.
(Actually you eat cake and drink coffee on a funeral, but it's still called like that in some parts of Austria.)
https://github.com/google/brotli/issues/1597
> Remember that vuln 111-497 (as two chunks)
Good first step. Remember it’s two sets of three numbers. The first set is all ones, meaning the first three numbers are 1, then the fourth number is 4, then you add five for the next one (9), then you have to remember to subtract two (7)¹.
May sound silly, but I bet some of you have already memorised it from that alone. Being a slightly convoluted by still logical set-by-step helps with recollection.
¹ Lot of different ways to go about that, like remembering that the first set was three of one so “two was left out”.
Now, whether it's warranted or not, that's another matter, but they know how to appeal for maximum awareness/interaction.
And, most of all, is damaging to Google, which are the master of software engineering. /s
SQL Slammer didn't actually slam anything, and applied to a single vendor among many SQL providers. Heartbleed didn't make anyone's heart bleed...I mean, at least directly. Shellshock only impacted a single shell environment, again among many. Log4Shell impacted a single logging implementation, among many. Spectre and Meltdown...I mean, who would think that related to CPU cache side channels?
These are just dumb names for people to share in referring to something. Seems silly and like a waste of time to spend effort getting upset about them.
I even read the patch for the C code (patch which, btw, seems a bit hacky to me with isSafe? methods added and whatnots but YMMV: now I understand things had to be patched in a hurry but this patch really looks like "lipstick on a buffer overflowing C pig" to me).
What's the link between Python / Node / C++ / libbrotli / Envoy / Bun: are those some all using the same C brotli encoder/decoder?
Can someone who knows more explain why all those are vulnerable?
> As for unaffected software, Apache’s standard mod_brotli does not decode Brotli
Because this one only encodes and doesn't decode and the bug is in the decoder? (for I take it mod_brotli, with such a name, still does something brotli related and isn't, say, a TOTP token generator nor a SAT solver?).
I mean overall, sheesh: could we get better explanation / better writeups when such big fuckups happen?
Google provides the Brotli implementation. Package maintainers slurp that up and create ie libbrotli-dev. When you compile node it uses that for brotli support.
Your comment is irrelevant to mine. I stated what is, while you stated what ought to be.
It's trivial to make any open source repo that nobody uses. It's hard to get people to adopt your library over one supported by one of the world's largest companies.
Yes, I know HTTP 2 and 3 and SSE are attempts to make it faster and more parallel, but its still slow. Its slow because its unidirectional with a full round trip and by default its a new socket per each message. Yes, I know the real reason HTTP became and remains popular is because its sessionless... in theory. Still, there are better options available. You can do so much more with a full duplex channel.
If you want something else you can take your pick based on need from dozens of other options
SMTP is too chatty - it uses too many round trips for efficient transfer across the internet. It can take several seconds just to get to the point of sending the email data. It also duplicates information between the SMTP envelope and the email body which creates vulnerabilities when they don't match.
For APIs that don't have to work in a browser I suggest JSON lines over TCP, or over TLS.
Multiplexing is the default in HTTP/2 and 3. So you're still wrong.
https://stackoverflow.com/questions/36517829/what-does-multi...
So, for the sake of argument let’s say I am completely wrong, MDN is wrong, all of Stack Overflow is also wrong. Even still HTTP is slow. Slow as shit. Imagine trying to do a MS Teams call with 50+ participants with cameras on. It would be slow as shit for just a one-on-one call. A call with 50+ people would be ridiculously slower and would likely result in a crash from memory exhaustion.
I was also not talking about HTTP2 or 3. I was very clear about that. Reading is hard. HTTP is used in many different contexts outside the browser where 1.1 continues to dominate.
The primary reason developers want to keep HTTP around is familiarity and comfort. HTTP is great when you don’t compare to anything else or do any kind of performance tuning.