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?

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)

Installing the update isn't enough. A running process keeps the old decoder until it restarts, and a container keeps it until you rebuild the image on a patched base and redeploy

Claudeslop aside, it really is a whole new world we’re in now, where the audience of a run-of-the-mill RCE CVE announcement really does need this stated.

Who turned on hard mode this week?

Every time you add something you lose something...

- git

- Sublime text

- VS studio

- CUDA

- .NET

- inkscape

- AzureTools

Real carreer starter.

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.

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?

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

How many clients only accept brotli?

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

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?

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.