Join the discussion

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

  • Hacker News
  • 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.

  • I’m so tired. I think I’m just going to get a job as a garbage man and cancel my internet.
  • 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.
  • 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...

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

  • > Type confusion in V8

    Fortunately I disabled js by default. Unfortunately, it breaks about 30% of the web. Including nvd.nist.gov, which shows a completely blank page without js enabled, even though with js it’s just a simple page with only static content.

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

Explore Birbla archives