Actively exploited sandbox RCE in all Chromium versions

(nvd.nist.gov)

150 points | by negura 2 hours ago

8 comments

  • david_shaw 1 hour ago
    Let's take a moment to talk about the monetary value of this vulnerability.

    According to the Chrome release page (https://chromereleases.googleblog.com/2026/09/stable-channel...), Google paid a researcher $1000 for ethically reporting this.

    The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?

    Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment. But at the same time, if someone submits a critical issue like this, it makes sense to pay them what the bug's actually worth. Why should a researcher be effectively penalized for responsibly telling a vendor instead of selling the bug to a "research firm" or three-letter agency?

    It's one thing if you're an open source project maintainer just trying to put something out to the community. The math is a lot different if you're Google.

    • CookieCrisp 1 hour ago
      While I agree 1000 is hilariously low for this, worth is hard to quantify. Do you pay what it could theoretically cost your company? the amount the top bidding bad actor would be willing to pay?
      • quotemstr 38 minutes ago
        You let the market decide. Google could purchase the bugs on the same market blackhats do.
        • jsw97 27 minutes ago
          In the past I would have thought this would incentivize finding bugs that might never be found. However it is now clear that all bugs that can be found will be found. So this makes a ton of sense.
          • eru 17 minutes ago
            > In the past I would have thought this would incentivize finding bugs that might never be found.

            Isn't that a good thing?

            > However it is now clear that all bugs that can be found will be found. So this makes a ton of sense.

            If Google can find all the bugs nowadays, presumably with AI, why still pay a bug bounty? At least by this logic, bug bounties make less sense now.

            • jsw97 13 minutes ago
              Sure they make sense — you need some incentive to drive the price to zero.
      • teravor 50 minutes ago
        ideally, an auction and the vendor or a government can bid against malicious actors (which can also be a government). hard to set up though.
        • eru 19 minutes ago
          What kind of auction would you like to run?

          Remember that you can sell the same vulnerability to multiple people: it's software you can copy.

        • 27183 31 minutes ago
          it seems unlikely google's lawyers would go for this
          • aeonik 20 minutes ago
            Maybe some code is so important and heavily trafficked it becomes a public works project, and various legs can bid for pieces of the project, line how all infrastructure works.
          • teravor 20 minutes ago
            well that's why setting it up is hard, because you would want to do it in a way that what they want doesn't matter.
    • r_lee 4 minutes ago
      this is why again, researchers should just honestly sell these to vuln brokers instead of donating them to trillion dollar companies for nothing.

      nothing will change until big tech gets to rip off security researchers

    • computably 51 minutes ago
      > How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?

      On average, probably not that much. What's the amortized cost of all testing, static analysis, and audit / code review, per "prevented potential bug"?

    • esseph 58 minutes ago
      The problem is they are being flooded with both fake AND real disclosures. Imagine if they tried to pay out $250,000 or more per bug? Would the cost be worth it? Maybe, but shareholders may not be pleased... Unless they viewed it as insurance against it being more financially sound for the finder to sell the exploit on the gray or black market instead...
      • Barbing 12 minutes ago
        Pre-flood, they didn’t pay more did they?

        > viewed it as insurance

        Of course. Beyond the ethics, the social obligation, sleeping well at night by compensating hardworking people fairly.

        “We can’t pay more or we’d have to hire more human reviewers” should never be a massive company’s line of thinking.

      • r_lee 4 minutes ago
        it's such a drop in the bucket, it wouldn't make any difference
      • rglover 22 minutes ago
        They should just multiply a base rate against the severity level. Say the base rate is ranged so low-severity stuff is $500-1K base but high-severity stuff is $10K base. That would net a researcher ~$88K for this specific bug (8.8 severity).
  • Cider9986 2 hours ago
    Brave is beating GrapheneOS on update timeliness:

    https://github.com/GrapheneOS/Vanadium/releases

    https://github.com/brave/brave-browser/releases

    Only if you use Nightly wait maybe not.

    • d2kx 1 hour ago
      This issue is already fixed in Google Chrome (152.0.7977.83)
      • azakai 49 minutes ago
        TFA says

        > Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.

        So it was fixed in 152.0.7977.82 (before .83), if I read that right.

    • anon109 1 hour ago
      Is graphene even affected? JIT is disabled in default configurations.
    • chuckadams 1 hour ago
      The release version just now updated to 152.0.7977.83 which has the fix.
      • fmajid 1 hour ago
        I upgraded Vivaldi, which is reporting 152.0.7977.112
  • publlus_enigma 21 minutes ago
    Normalising running arbitrary code delivered over the internet (in the form of JavaScript and WASM), as a necessary condition for accessing most web pages may not have been one of the best decisions we have made.
    • asveikau 5 minutes ago
      I remember noticing this shift in nerd culture. In the early 2000s, it was common for people to say on places like Slashdot that they don't trust JavaScript and run their browser with it off. In the early 2010s, I noticed HN commenters thought this was insane, tinfoil hat type thinking.
    • eru 16 minutes ago
      In the future we can ask that your JaveScript and Wasm comes with a proof of being benign.
  • thenewnewguy 59 minutes ago
    Does anybody have a source for the "actively exploited" part of the HN title?
    • john_strinlai 51 minutes ago
      by nature of being in the "known exploited vulnerabilities catalog" (https://www.cisa.gov/known-exploited-vulnerabilities-catalog...)

      "CISA maintains the authoritative source of vulnerabilities that have been exploited in the wild."

    • crtasm 50 minutes ago
      This line, I think? >This CVE is in CISA's Known Exploited Vulnerabilities Catalog
    • esseph 52 minutes ago
      "Google has confirmed that an exploit exists in the wild but has not disclosed information about the threat actors, targeted organizations, or attack campaigns while the update is still rolling out."
  • petra303 2 hours ago
    Only a score of 8.8?
    • teravor 2 hours ago
      RCE inside sandbox, so requires chaining with another 0day.
      • zahlman 1 hour ago
        What exactly does "RCE inside sandbox" describe that goes beyond "the webpage can supply arbitrary JavaScript and the JavaScript engine executes it", but is still isolated from the system?
        • StilesCrisis 37 minutes ago
          Chrome runs webpages in individual sandbox processes with very low privileges, as a defense-in-depth strategy. It generally requires at least two exploits to actually affect a user--first, get RCE in a sandboxed process, then find a separate vulnerability that lets you escape the sandbox process entirely. For this bug to have actually been used in the wild, there was almost certainly a second bug as well.
        • jimrandomh 1 hour ago
          It means it can execute native code inside the sandbox, as opposed to Javascript. While still sandboxed, this lets it access some parts of the attack surface that JS would not have been able to, some of which may have other exploits that allow escaping the rest of the way.
        • jnwatson 1 hour ago
          It means it can execute arbitrary machine code in the sandbox.
          • r_lee 1 hour ago
            I think people would like to understand what the "sandbox" is here and what isolation does it provide, is it an unprivileged process? something chromium specific? a v8/JS thing? etc.
          • zahlman 1 hour ago
            Okay, and why is that more of a security risk than executing arbitrary JavaScript in the sandbox?
            • arcfour 6 minutes ago
              Among other things, JavaScript in the browser has no way to even express "kill PID 1234 on the user's machine" or "list the contents of `C:\Users\Documents` and upload all of the files" or "spawn cmd.exe on the user's machine". How would you even do these things if you could run any JavaScript in the browser? You can't.

              However, chrome.exe itself does because it's a native application, as is the sandboxed JavaScript interpreter inside of chrome.exe.

              (This is a very oversimplified explanation but I think this is the disconnect people are having)

            • insanitybit 42 minutes ago
              Because Javascript theoretically can't just access files on disk. Control over the render would let you do that, if not for the process level sandbox, which constraints things like file access, system, calls, etc.

              But the process is still more capable than the VM. The process can talk to other processes via IPC, for example.

              That's why you don't go from "javascript -> computer is taken over", instead you go from "javascript -> renderer control -> computer is taken over".

            • r_lee 56 minutes ago
              because with proper code exec you can trigger other bugs to escalate beyond the sandbox, whereas with JS you'd have to find a bug to escape from JS to native

              can't get a proper ios/Android RCE with just JS code exec

            • p-e-w 53 minutes ago
              It can do some things that JS can’t do, such as invalid pointer writes. But you are correct that this doesn’t automatically imply system access.
          • TacticalCoder 34 minutes ago
            > It means it can execute arbitrary machine code in the sandbox.

            Well which is precisely why we have sandboxes.

            To me "executing arbitrary code in the sandbox" is similar to "I don't give a flying fuck for it's what a sandbox is for".

            More information is needed. As someone commented: this has to be paired with at least another exploit to make anything remotely useful.

            A sandbox is a sandbox. We want to understand how "code running in a sandbox" is "actively exploited".

        • johnsmith1840 1 hour ago
          Memory isolation having one tab or account open on your bank and another on this page does not mean it could leak across the sandbox and steal bank account details but anything inside of your general page content can be lost
      • iririririr 1 hour ago
        what is online ad networks for $100, alex
  • Terr_ 1 hour ago
    As somebody who prefers to browse with JS off whenever possible, there's something absurd about the balance everyone takes for granted between (A) your personal safety against a devastating hack by malicious code and (B) surveillance advertising.

    "Sorry, but to enter this shop you need to take one of the used syringes from that pile some dude delivers every day and poke yourself with it."

  • colincowardly 1 hour ago
    [dead]
  • anonymousiam 1 hour ago
    Just one more reason to never use Chrome. Their removal of MV2 to prevent UBlock Origin from working is another.
    • Barbing 8 minutes ago
      Of all the reasons to use non-Chromium browsers whenever possible(!), this isn’t really on the list.
    • fidotron 38 minutes ago
      Chrome product management is horrible. Chrome software engineering is some of the best ever done.

      (And no, I don't use it except for testing).

      • noir_lord 33 minutes ago
        I don’t disagree, two or more things can be true at once.

        That said I still use Firefox for other reasons.

        I simply don’t trust google, I don’t trust Mozilla either but I do trust them more than Google and you do kinda have to have a browser to function in the modern world.

    • lima 1 hour ago
      Which browser has a better security track record?
      • Cider9986 1 hour ago
        Vanadium makes improvements on Chromium. https://grapheneos.org/features#vanadium
        • StilesCrisis 30 minutes ago
          Most of those are just changing flags, not really unique development. Like "disable JIT" is a Chromium flag. "Zero-init everything" is a Clang flag.
        • esseph 51 minutes ago
          Right, but it's value-add on a derivative, not its own standalone engine.
      • p-e-w 55 minutes ago
        Firefox with uBlock Origin. It’s astonishing how many exploits uBO stops before they ever reach your browser engine. It’s the antivirus of the 2020s.
        • Cider9986 19 minutes ago
          Brave would be a much better option if you want security and good adblocking.
        • Alifatisk 44 minutes ago
          I suggest Zen browser (fork of FF), it feels closer to chrome.
          • Barbing 5 minutes ago
            I hear about Zen. Random q:

            It can’t trick Canva into letting you use the color picker, or otherwise enable it, can it - if someone happens to know?

            (What a dumb feature to be locked to the Googlesphere.)

          • aleksandrm 3 minutes ago
            What does it mean "closer to chrome"?
          • ZiiS 40 minutes ago
            In a good way?
    • StilesCrisis 34 minutes ago
      Oh, right, because other browsers never have bugs.
    • lta 1 hour ago
      If we needed any more.