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.)

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.

Well, don't worry. libjxl includes the brotli library, too, so it's also vulnerable to this.

https://github.com/libjxl/libjxl/pull/5062/commits/269661f71...

Brotli reduces their compute costs, whereas JPEG XL reduces storage which at least historically is cheaper than compute?

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.

Mozilla found and reported it as an RCE in April: https://bugzilla.mozilla.org/show_bug.cgi?id=2029458

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.

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.

Why would request compression be obscure? When you support posting big forms, requests get big too, so why not compress them?

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.

Ok, we've belatedly changed to that from https://www.aikido.dev/blog/python-packages-vulnerable-node2.... I'll put the other link in the top text as well.

Not when you're prioritising sensationalism over accuracy. Everyone's heard of HTTP, but hardly anyone's heard of brotli.

There's this other name for the same vuln: https://broccoli2shell.com/

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.

Mozilla reported it as an RCE in April

https://bugzilla.mozilla.org/show_bug.cgi?id=2029458

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...

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.

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.

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

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.

Nah man. We were on casual mode all along. This is the new normal.

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.

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.

[dead]

They’ll have it for few months and then make you pay to get the update.

Side point from going to pypi:

> 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?

...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.

why is this downvoted? are any of those not accurate?

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.

Sorry, I find the supply chain risks of Rust much more worrying than these memory safety issues. So how about we get rid of Rust? At least cargo is a problem.

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.

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.

Because these applications were created long before Rust existed.

There is a cost to conversion.

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.

"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

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.

Would you also apply this to cryptography or, well, really any security library? Because I hope the answer will be no...

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.

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]

[0] https://www.bugsink.com/blog/http2shell-timeline/

[1] https://news.ycombinator.com/item?id=50230362

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?!"

A better name is Konduktsemmel, which is a bread roll (Semmel) which you eat on a funeral (Kondukt) in Austria. Fits to Brotli, doesn't it?

(Actually you eat cake and drink coffee on a funeral, but it's still called like that in some parts of Austria.)

Feels like the goal was sensationalism.

Just call it CVE-2026-111497. More accurate and much easier to remember and to talk about with your boss.

Actually it does, if the server is willing to decompress POST bodies.

I immediately thought HTTP/2 was having a bad day somehow. Might I suggest Software2Shell to be less confusing.

The author clearly used super intelligence.

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.

All these names are silly. It's just marketing.

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.

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.

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.

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...

This has been the case for more than a decade, Heartbleed was probably the one which really created the trend.

Small static websites are effectively free (Cloudflare, GCP free tier, etc)..

We detached this subthread from https://news.ycombinator.com/item?id=50220841.

I'm certainly not complaining about some selfless guy making a helpful website without expecting anything in return!

Are you asking why do we name things? In a programming forum?

It is annoying (and ironic) because larger companies, that will benefit from this information the most, blocks newly registered domains.

You remember CVEs by heart? Do you even bother using DNS?

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

"by default its a new socket for each message" is misinformation - keepalive is the default since HTTP 1.1 (1999).

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.