HN

Comments (94)

• Menu

  netsharc
  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...
• Menu

  pimterry
  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.
• Menu

  Rapzid
  > 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 nowI'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?
• Menu

  bawolff
  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)
• Menu

  nairboon
  Brotli2Shell seems to be a more appropriate name for this.
• Menu

  cowsandmilk
  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.
• Menu

  flyingjoe
  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.
• Menu

  tetha
  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?
• Menu

  semiquaver
  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?
• anttihaapala
  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.
• upofadown
  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...
• skeledrew
  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.
• Menu

  est
  wtf Python is also effected. https://pypi.org/project/brotli/ not sure about shell
• Menu

  jgalt212
  How may web servers only serve brotli?How many clients only accept brotli?
• Menu

  davedx
  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?
• Menu

  perching_aix
  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.
• Menu

  TacticalCoder
  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 BrotliBecause 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?
• devdudejeremy
  [flagged]
• chelseahermes
  [flagged]
• Zestymarble45
  [flagged]
• Menu

  rfgplk
  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.
• anon
  undefined
• Menu

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