117 pointsby cowlevel4 hours ago20 comments
  • ataraxia9372 hours ago
    This one again feels overblown, at least for servers. I just checked an org of over 200 GitHub repos. Node, Python, and C#. None of them are vulnerable... because none of them actually call the Brotli decoder. It's just not enabled by default on the server side, by the platforms themselves. This is much like the PHP bugs, where specific conditions have to be in play before you're actually vulnerable.

    For clients? Sure, that's a bigger risk. Patch them. But bad guys aren't attacking your clients unless the clients connect to them. Don't stay up late to fix this.

    (And yes, .NET is included here, because Microsoft's Brotli module is a binding for Google's vulnerable reference implementation.)

    • guac10 minutes ago
      Doesn't node's fetch call the decoder automatically for `br` responses? So any attacker controlled content that a server fetch's may be vulnerable?
    • babuskovan hour ago
      How did you check? Is there are PoC or some kind of command to run?
    • bboran hour ago
      I mean, I dare say the 4,200,000 Python servers built yesterday alone with this package might disagree...? https://pypistats.org/packages/brotli

      I can't find download numbers for extras, but it comes in the pretty dang innocuous-seeming `aiohttp[speedups]`, as well. Also `urllib3[brotli]`. Many, many people will be running these servers without recognizing the name of the library, especially in the agentic era.

      I might be missing something obvious in your message, cause I don't see why server/client is relevant. Why would a frontend app speak a protocol that the backend doesn't?

      • deathanatosan hour ago
        That's just the total number of times that package was downloaded, which is completely unrelated to how many servers it appears in? Same with `aiohttp`: aiohttp can be used as a client library.

        Sure, people should check their dependency trees, and make informed decisions.

      • an hour ago
        undefined
      • vinyl729 minutes ago
        The whole package manager system is a complete disaster. A huge number of dependencies are pulled in that go unused in most projects, so the number of downloads is an extremely unreliable number. I'd be surprised if more than 10% of those downloads actually use the brotli decoder.
  • anonymous9082133 hours ago
    I could do without every memory bug getting a cute sensational name and marketing push, I have to say.
    • aaronbrethorstan hour ago
      We should start naming them like hurricanes: NIST creates a list of alphabetical names and assigns any CVE >= 9.0 with a name. Vulnerability Alex (CVE 9.4)
      • ks204838 minutes ago
        Vulnerability Zzyzx in a week
        • nevir8 minutes ago
          Tomorrow
    • lovich2 hours ago
      that ship sailed a while ago. Rowhammer is the first one I can remember
      • card_zero3 minutes ago
        Rowhammer was kind of special, surely, what with being based on a physical design flaw?
      • vinkelhake2 hours ago
        Let's not forget about heartbleed!
        • judge20202 hours ago
          Back in the email days the virus authors named them, e.g. YouAreAnIdiot, ILoveYou
        • mhio2 hours ago
          That was the first exploit logo I can recall
          • weinzierl2 hours ago
            The most memorable one for me is DirtyCOW.
  • rvanlaar3 hours ago
    It looks like brotli <= 1.2.0 is vulnerable.

    The python package has already been updated to 1.2.1. https://pypi.org/project/brotli/1.2.1/

  • hatthewan hour ago
    I feel like normal security issues don't get much publicity. The PHP and eMudhra issues seemed severe, and worth publicity. But then with things like this, I'm not sure. Is this a severe issue? Or is it just a run of the mill issue that's only newsworthy because web security is on people's minds right now?
    • Gigachadan hour ago
      The whole industry is on edge right now, and numbers wise the CVE count has exploded beyond belief. It's probably to take the side of caution, treat everything as important and update everything promptly rather than the old way of doing things where libraries are left months or years out of date until something happens.
  • kccqzy2 hours ago
    There’s apparently no writeup on exactly what was the fix. So I’m going to make a guess that this is the chromium commit that fixed the problem: https://source.chromium.org/chromium/chromium/src/+/224140d4...

    And this commit contained a refactoring from BROTLI_BOOL to BrotliDecoderErrorCode so the situation was that probably one of the error conditions previously simply returned false but needed more detail about what went wrong to continue safely.

    Well okay this change from `if (prev_ix < cur_ix)` to `if (prev_ix < cur_ix && cached_backward <= max_backward)` is also suspicious and could be an related or unrelated hardening fix.

  • adzm3 hours ago
    Interestingly the commit that fixes this in brotli dates back to February https://github.com/google/brotli/commit/0ed4268a4401abcb4472...
    • cowlevel3 hours ago
      OpenAI's tweet says it wasn't recognized as security relevant so wasn't important enough to make a release - until their agent realised it was.

      https://nitter.jaydenha.uk/OpenAI/status/2113766354386084338

      • dofm2 hours ago
        Until their agent realised there was a good chance of a press release in it.
        • robswc24 minutes ago
          I am just amazed at how many people are blind to this.

          Every single time one of these labs does something it is almost always sensationalized. They absolutely cannot refrain from describing how incredible their models are, it has to be injected into everything. I get this is basic grow-your-company stuff but it is getting obnoxious.

        • SV_BubbleTime2 hours ago
          Chat, we need to constantly be justifying our absolutely absurd IPO. Use UltraMegThink and reference the ExploitToGetUsRegualtoryCapture.md. kkthnx
  • Sytten3 hours ago
    Since I checked Rust servers should be fine since the brotli crate is not a binding on the C.
    • doodlesdevan hour ago
      Apparently it doesn't contain a binding to the C library, but it does contain some compatibility and shares design decisions with it. In other words, it's not a clean-room implementation from the spec, but rather it's a port. Since this RCE is triggered by a OOB access, it's unlikely to have made it into the crate, but it's good to keep these things in mind.
  • VladVladikoff22 minutes ago
    >A significant blast radius

    Is it really so hard to write a 2 sentence tweet that you need an AI to do it for you?

  • 40 minutes ago
    undefined
  • kylepomykala2 hours ago
    They just keep coming, don't they?
    • Gigachad2 hours ago
      For as long as we still have C code accessible to the internet.
    • hoppp2 hours ago
      Never gonna stop. Consider it normal. Hey, at least humans still have a job. Incident response
      • awakeasleep2 hours ago
        Let's not kid ourselves, llm's are already doing the incident response for this in many infrastructure teams
        • chelmzyan hour ago
          I would love to hear your definition of this. Are llms used to aid in incident response? 100%. Why would I sit there and manually review data from multiple sources when I could have an agent pull from all and summarize? But to hand it off end to end? I haven't seen anyone accomplish this.
        • hoppp2 hours ago
          But they don't respond with fear and flailing arms!
  • csiegertan hour ago
    Is Deno affected, too? It uses brotli by default. But I don’t know how it is implemented.
    • gnabgiban hour ago
      Deno is dead (baby)

      > We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development

      https://deno.com/blog/cloudflare

      • csiegert43 minutes ago
        I know that it is dead but since they provide security updates for another year I haven’t migrated off of it immediately. Anyways, the Deno runtime uses a brotli Rust crate that does not wrap C code, and with unsafe off, so I assume it is safe.
        • gnabgib40 minutes ago
          So a person of rhetorical questions? Great
          • csiegert27 minutes ago
            No. After your unhelpful answer I started investigating if my deployment is affected.
    • Amsozzeran hour ago
      I doubt it
  • cowlevel4 hours ago
    Likely mitigation: disable brotli (br) content-encoding on both sides
    • thayne2 hours ago
      Unfortunately, AFAICT, there is no way to do this for node's fetch. I suspect there are other client libraries that don't have a way to disable it.
  • dboreham2 hours ago
    This is a better article: https://www.aikido.dev/blog/python-packages-vulnerable-node2...

    and this is the actual CVE report, which doesn't say much: https://www.cve.org/CVERecord?id=CVE-2026-111497

  • QuadmasterXLII3 hours ago
    is flask hello world with gunicorn behind apache vulnerable?
    • cpburns20092 hours ago
      Only decompression with Google's brotli library is affected. So if you use "Brotli" or "brotlicffi" in your Python app to decompress brotli, you're vulnerable. Compressing responses with brotli from Apache is safe.
    • TZubiri3 hours ago
      what I can say is that a 5 liner hello world starting with ‘import socket’ is not affected

      whether a hello wolrd in fastapi is affected might also be interesting

  • bogomind3 hours ago
    [flagged]
  • bibekadhikari3 hours ago
    [flagged]
    • thayne2 hours ago
      > refusing br content-encoding at the edge seems like the fastest mitigation.

      That's pretty difficult if you make outbound requests, and don't already have a TLS interception proxy set up.

    • cowlevel2 hours ago
      This is an AI karmabot comment, it should remain flagged
  • DogeGode3 hours ago
    Another day, another buffer-overflow vulnerability in C code …
  • userbinatoran hour ago
    Brotli, another one of those pseudostandards[1] from Big G that I was avoiding all along. Dodged another bullet.

    [1] When more than half of the "standard" https://www.rfc-editor.org/info/rfc7932/#page-44 is an opaque binary blob, they're really not encouraging independent implementations.

    • johncolanduoni18 minutes ago
      How do you suggest they provide the static compression dictionary?