A remote code execution vulnerability affecting Google Chrome’s WebAssembly engine has been publicly disclosed, along with a fully functional exploit.
The flaw, discovered and reported during TyphoonPWN 2025, involves a regression in the canonicalization logic for indexed reference types in WebAssembly and a novel sandbox bypass via JavaScript Promise Integration (JSPI).
Researchers from SSD Secure Disclosure demonstrated that by combining a nullability confusion bug with a sophisticated birthday-attack-based hash collision technique, it is possible to gain arbitrary read/write primitives within the V8 sandbox and ultimately execute native code.
Credit for the finding goes to Seunghyun Lee (0x10n), who achieved first place in the Chrome RCE category.
Vulnerability Overview
The root cause lies in a regression introduced by commit 44171ac (Chrome M135), where CanonicalEqualityEqualValueType failed to consider nullability for indexed reference types (ref t0 vs. ref null t0).
This oversight allows two WebAssembly type groups that differ only in nullability to canonicalize to the same internal representation, enabling an attacker to craft a hash collision via a birthday attack on MurmurHash64A.
Once two colliding reference types are created, a recast primitive effectively removes null checks, leading to a caged read/write capability in Memory.
Simultaneously, a JSPI stack-switching bug introduced in commit d4700da (Chrome M137) can be exploited to bypass the V8 sandbox.
By manipulating nested secondary stack chains, the exploit skips inactive frames and clobbers suspended stack contents, regaining control of the central JS stack with attacker-controlled values.
This component of the chain grants full arbitrary code execution without relying on legacy PartitionAlloc attacks.
Exploit Mechanics
- Hash Collision Generation: Using a WebAssembly module builder, the attacker defines two recursive type groups (t1null, t1nonnull) with varying nullability combinations. A birthday attack over 2^32 attempts yields a candidate collision in seconds, masking nullability differences.
- Null-to-Non-Null Cast: The collision allows a null reference to be recast as a non-null reference, stripping implicit guard-page protections and enabling a controlled object to read and write raw memory.
- Caged Read/Write Primitive: By mapping the controlled object to a large WasmArray, the exploit obtains an arbitrary offset read/write primitive (addrof and fakeobj) within the sandbox memory cage.
- JSPI Sandbox Bypass: The crafted payload triggers nested WebAssembly.promising calls. Malformed stack unwinding steps skip over suspended frames, granting direct stack control. After spraying a ROP chain, the exploit pivots to a VirtualProtect shellcode stub and executes arbitrary native commands (e.g., spawning calc.exe).
- Delivery: The fully assembled exp.html and WebAssembly module are served over a local HTTP server. Launching Chrome with –no-sandbox and visiting the page results in immediate code execution.
This flaw impacts all Chrome stable channel builds from M135 through M137 without the proper null-equivalence checks, and M137+ for the JSPI bypass.
Google has released an emergency patch reverting the faulty canonicalization logic and enforcing stricter stack-state checks in JSPI.
Recommendations
- Immediate Update: Apply the latest Chrome update from October 2025 or later, which includes the null-equivalence fix and hardened JSPI checks.
- Avoid –no-sandbox: Never run Chrome with the –no-sandbox flag unless absolutely necessary for debugging.
- Defense in Depth: Employ endpoint protection solutions that monitor anomalous WebAssembly usage and unexpected process behaviors.
- Audit WebAssembly Usage: Review in-application WebAssembly modules for untrusted code execution paths.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
