CVE-2024-4947: V8 Type Confusion in Chrome — Renderer Compromise via JavaScript
A type confusion vulnerability in Google Chrome's V8 JavaScript engine allowed attackers to achieve arbitrary code execution within the renderer process through specially crafted JavaScript, affecting versions prior to 125.0.6422.60.

TL;DR
A type confusion bug in V8's Maglev optimizing compiler allowed attackers to bypass type safety guarantees, leading to out-of-bounds memory access and arbitrary code execution in Chrome's renderer process. Exploited in the wild before patch release.
Affected versions
Google Chrome versions prior to 125.0.6422.60 (Stable channel, released May 2024) across all platforms (Windows, macOS, Linux, Android). Chromium-based browsers using vulnerable V8 versions were also affected, including Microsoft Edge prior to 125.0.2535.51 and Brave prior to 1.66.115. The vulnerability existed in V8's Maglev JIT compiler, introduced in V8 version 11.0, making Chrome versions from approximately 108.0 onwards potentially vulnerable.
Root cause
The vulnerability stemmed from incorrect type tracking in V8's Maglev mid-tier optimizing compiler during property access operations on JavaScript objects. Maglev performs speculative optimizations based on assumed object shapes (hidden classes/maps). The bug occurred when handling polymorphic property accesses where an object could have multiple possible maps.
Specifically, when Maglev compiled code accessing properties on objects with CheckMaps nodes (which verify object shape), it failed to properly invalidate type assumptions after certain map transitions. If an object's hidden class changed through property addition/deletion, but Maglev-compiled code still assumed the old map, subsequent property accesses would use incorrect offsets.
This created a type confusion state where the engine treated one JavaScript type as another. For example, a doubles-only array could be confused with an object-pointer array, or object properties could be accessed at wrong offsets, reading/writing adjacent memory regions.
The core issue was in the MaglevGraphBuilder::TryBuildPropertyAccess function, which didn't properly track map deprecation chains when optimizing polymorphic access sites.
Exploitation primitive
Exploitation required triggering the type confusion to achieve arbitrary read/write primitives:
- Trigger compilation: Create objects with specific property access patterns that Maglev would optimize
- Induce type confusion: Perform map transitions that Maglev didn't properly track, causing outdated type assumptions
- Out-of-bounds access: Use confused types to read/write beyond object boundaries (e.g., treating a SMI as a pointer or vice versa)
- addrof/fakeobj primitives: Leak object addresses and create fake objects by confusing pointer and non-pointer arrays
- Arbitrary R/W: Build read/write primitives using ArrayBuffer backing stores or similar structures
- Code execution: Overwrite JIT code regions, WebAssembly tables, or function pointers
The exploit typically required:
- Precise heap feng shui to position attacker-controlled data adjacent to target objects
- Multiple rounds of JIT optimization to ensure Maglev compilation of vulnerable code paths
- Careful object shape manipulation to trigger the specific type confusion without crashing
Attackers likely used TypedArrays or ArrayBuffers as the final target for arbitrary R/W since their backing store pointers provide direct memory access once corrupted.
Mitigation
Update Google Chrome to version 125.0.6422.60 or later immediately. For Chromium-based browsers, update to versions incorporating V8 11.5.150 or later.
The fix modified Maglev's map checking logic to properly handle map deprecation and polymorphic cases. Specifically:
- Added stricter map dependency tracking in
MaglevGraphBuilder - Enhanced
CheckMapsnode to verify map stability throughout the optimization pipeline - Improved invalidation of optimized code when underlying maps change
Organizational mitigations:
- Deploy Chrome updates through managed policies within 24-48 hours
- Enable site isolation (default since Chrome 67) which limits renderer compromise impact
- Consider disabling JavaScript JIT for highest-security environments via
--js-flags="--jitless" - Implement browser isolation solutions (remote browser isolation) for high-risk users
- Monitor for Chrome processes exhibiting abnormal memory patterns
For developers building Chromium embeddings:
- Backport V8 security patches if using custom V8 versions
- Enable Control-Flow Integrity (CFI) and other exploit mitigations in build configuration
- Implement additional sandboxing layers beyond Chrome's default sandbox