
POC available soon
A critical remote code execution vulnerability in Google Chrome (versions 123 and earlier) affecting WebAssembly (WASM) garbage-collection type handling. The bug allows type confusion that can be escalated to arbitrary memory read/write and ultimately code execution.
The vulnerability stems from confusion between WASM isorecursive canonical type IDs and the wasm::HeapType / wasm::ValueType representations used in the JavaScript-to-WASM conversion functions.
Critically, a canonical type ID is not bound to kV8MaxWasmTypes in any way — it can grow as large as the host memory supports.
The ValueType class encodes heap types in a 20-bit field, but canonical type IDs can exceed this limit. When a canonical type ID such as:
tn = t0 + 0x100000 * n
is truncated to 20 bits, it aliases with t0, enabling a type-confusion attack.
Additionally, canonical type IDs matching kAny + 0x100000 * n (where kAny = 1000005) bypass type checks and permit arbitrary WASM type confusion.
The advisory describes the exploitation in three phases:
Crafting WASM modules with 1,000,000+ types causes canonical type IDs to wrap, enabling confusion between struct types and reference types. Struct types crafted to alias with kAny bypass the JS-to-WASM type checks.
By modifying ArrayBuffer backing-store fields, the attacker gains an arbitrary address write where the written value is the metadata address. This exploits SlotSpanMetadata structures to leak chrome.dll addresses and achieve arbitrary memory writes.
The exploit hijacks the CodePointerTable and pivots execution to a ROP chain that marks shellcode regions executable.
The PoC demonstrates:
kAny to bypass the JS-to-WASM type checks.This is a variant of CVE-2024-2887, discovered by Manfred Paul and presented at Pwn2Own Vancouver 2024. It exploits a similar type-canonicalization weakness through a different vector.
Google Chrome 123 and prior.
Fixed in Google Chrome 124.
Seunghyun Lee (Xion, @0x10n), participant in TyphoonPWN 2024.