Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Does anybody have a source for the "actively exploited" part of the HN title?
    by thenewnewguy
  • "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."
    by esseph
  • This line, I think? >This CVE is in CISA's Known Exploited Vulnerabilities Catalog
    by crtasm
  • 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."

    by john_strinlai
  • So basically, Edge, Brave and any other browser built on Chromium. Nice.
    by snorbleck
  • Running Firefox on all my OSes. Nice.
    by chinathrow
  • Monocultures are great!
    by anonymars
  • Isn't this exactly why there is a sandbox? What can the RCE actually do or obtain within the sandbox?
    by mikeweiss
  • Yes, it says right in the CVE

    > allowed a remote attacker to execute arbitrary code *inside the sandbox*

    by socalgal2
  • Doesn’t any <script> tag let you run arbitrary code inside a sandbox anyway?
    by nikanj
  • Why is this 8.8?

    It's because User Interaction is Required. CVSS 10 would be the case where everyone can be exploited without interaction.

    Interestingly the 8.8 is more alert-worthy than the 9.8 and 10 cvss, because there is a need to be alerted of the current security risk, whereas with a cvss 2 vuln, there is nothing to be done by users, only admins.

    by TZubiri
  • 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.

    by Cider9986
  • The release version just now updated to 152.0.7977.83 which has the fix.
    by chuckadams
  • This issue is already fixed in Google Chrome (152.0.7977.83)
    by d2kx
  • Is graphene even affected? JIT is disabled in default configurations.
    by anon109
  • I’m so tired. I think I’m just going to get a job as a garbage man and cancel my internet.
    by throwatdem12311
  • Just in time.
    by tclancy
  • You've not watched the poor guy have to reboot his truck, have you?
    by bombcar
  • There's been a Chrome CVE like every week ever since it came out.
    by jesse_dot_id
  • They just released a CVE for a garbage truck vulnerability where an attacker could brick the vehicle by exploiting the telemetry system these things now have preinstalled in factory.
    by iammrpayments
  • Don't. Garbage Collector hurts your memory
    by Sha1rholder
  • Not to downplay the severity (patch your browsers!), but there have been 5-10 actively-exploited V8 type confusion vulnerabilities in the last year. I'd be curious if this one blew up because it was the only one that was posted, or if it barely crossed some line in the collective consciousness this time around.
    by pertique
  • I think it's the first one where the Chrome version fixing it has no Manifest V2 support at all.
    by RA2lover
  • Is the HN title true that it affects all "all Chromium versions"?

    Per OP link, it only affects Chrome versions prior to .82; .82 was released as stable 2 days ago. [1]

    (HN title also does not match the original title, which is the CVE ID -- not particularly intuitive.)

    [1] https://chromereleases.googleblog.com/2026/09/stable-channel...

    by no-name-here
  • "only"
    by cubefox
  • Ubuntu still considers 152.0.7977.64 stable.
    by turpentine
  • How many Heartbleeds[1] must software users and our national security interests endure before the industry treats memory safety as a best practice for systems with exposure to the Internet?

    The V8 vulnerability being exploited today, CVE-2026-85046, is listed in NVD under CWE-843, "Access of Resource Using Incompatible Type ('Type Confusion')."[2] On this class of vulnerabilities, MITRE explains:

    > When a memory buffer is accessed using the wrong type, it could read or write memory out of the bounds of the buffer

    Memory safety is specifically intended to prevent errors like these from becoming arbitrary out-of-bounds memory access and native code execution. Even type safety --- from the 1970s --- can prevent type confusion.

    The CISA and the NSA have called for the adoption of memory-safe languages.[3] We exercise poor engineering judgment and poor ethics, as an industry, when we continue to expose users to classes of wholly avoidable security weaknesses in Internet-facing software.

    [1] https://en.wikipedia.org/wiki/Heartbleed

    [2] https://cwe.mitre.org/data/definitions/843.html

    [3] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...

    by odyssey7
  • There's more to it than just using a memory safe language.
    by dchest
  • How do you write a performant memory-safe JS JIT?
    by Retr0id
  • This was a type confusion bug in generated JIT code, not in C++ code.
    by wavemode