Out of bounds memory access in V8 in Google Chrome prior to 120.0.6099.224

CVE mapping and patches

• Commenters try to locate the exact git diff; multiple candidate commits and bug IDs are mentioned, with some confusion between CVE-2024-0517, -0518, and -0519.
• One participant notes Chrome’s release notes tie 0519 to a different issue number than a suggested commit, so the precise mapping remains somewhat unclear.
• Fedora advisories mention three separate V8 CVEs (type confusion, OOB read, OOB write), indicating multiple compiler/runtime issues around the same time.

Affected versions and products

• NVD’s CPE list suggests impact back to Chrome 9, but people stress these ranges are often unvalidated and can be obviously wrong (example: a WebGPU bug “affecting” versions before WebGPU existed).
• Since the bug appears related to the Maglev compiler, which arrived around Chrome 114, older Chrome versions (e.g., 60) likely aren’t affected, though this is inferred rather than confirmed.
• Because all three CVEs are in V8, anything embedding V8 (Node.js, Electron apps, custom embedders, serverless/edge platforms) may be exposed if they run untrusted or semi‑trusted JavaScript.

Untrusted code, sandboxing, and impact

• Debate over what “untrusted code” means:
  • One view: any code not thoroughly audited is untrusted, so typical Node dependency stacks qualify.
  • Another view: if you run it in your process, you are de facto trusting it; “untrusted” is code you expect might be malicious and must be sandboxed.
• Browsers and many apps rely heavily on V8 as a sandbox for hostile input; bugs like this erode that assumption.
• The exploit writeup (for 0517) achieves powerful read/write within the V8/“Ubercage” sandbox via a Wasm-based chain; Chrome’s outer OS-level sandbox does not appear to be broken in the public chain.
• Some note that even sandbox-only code execution can leak or deanonymize users, depending on platform details.

JIT, fuzzing, and language safety

• Several comments emphasize that fuzzing, while heavy in Chrome/V8, is stochastic and can miss deep bugs for years.
• Others argue that JIT engines can miscompile regardless of implementation language; memory-safe languages don’t eliminate this class, though they remove many raw memory errors elsewhere.
• There is discussion of alternative designs: safer interpreters, disabling JIT (supported in major browsers), and higher-level JIT frameworks (e.g., Graal/Truffle-style) to reduce manual IR manipulation.
• Consensus: no one knows how to build large, high-performance JITs and browsers with zero security bugs; memory-safe languages help but are not a complete solution.

Threat models and operational risk

• Distinction is drawn between “bored five-year-olds” (low-effort attackers) and nation-states; the latter can often succeed despite strong defenses.
• Most real-world breaches still stem from trivial mistakes (unpatched software, bad passwords) rather than fresh V8 0-days, so timely updates matter more for most organizations.
• There is unease about exploit brokers selling such bugs to governments and about the scale of unpatched browsers.

Legacy systems and long-term exposure

• Chrome on Windows 7 is stuck at version 109; these systems won’t receive fixes for new V8 bugs.
• Some argue anyone running Windows 7 on the network “doesn’t care about security”; others counter that an isolated, firewalled Windows 7 machine may mainly be exposed via its browser.
• Observations that Windows 7/8/XP still hold non-trivial market share lead to concern about a large, permanently vulnerable install base.