0-Day RCE for Firefox A single-character typo in the SpiderMonkey JavaScript engine's WebAssembly garbage collection code led to a critical Remote Code Execution (RCE) vulnerability in Mozilla Firefox This article explores rce vulnerability firefox. . The developer had typed "&" (bitwise AND) rather than "|" (bitwise OR).

Erge, a security researcher, found the vulnerability while looking through the Firefox 149 Nightly source code to get ideas for a CTF challenge. He was able to successfully exploit it to get code execution inside the Firefox renderer process. During the refactoring of WebAssembly GC array metadata in the file js/src/wasm/WasmGcObject.cpp, the vulnerability was introduced in commit fcc2f20e35ec. Instead of reading oolHeaderOld->word = uintptr_t(oolHeaderNew) & 1;, the problematic line should have read oolHeaderOld->word = uintptr_t(oolHeaderNew) | 1;.

The code stores zero instead of the intended forwarding pointer with its least significant bit set because of pointer alignment, which causes the bitwise AND operation with 1 to always evaluate to 0. By mistagging out-of-line (OOL) WebAssembly arrays as inline (IL) arrays, this single character error led to the garbage collector handling memory references incorrectly, creating a memory-corruption vulnerability. RCE Vulnerability in Firefox SpiderMonkey's WebAssembly GC implementation contains the bug, which primarily impacts the WasmArray.When the garbage collector moves, the Object::obj_moved() function is called.

arrays of wasm between memory locations. To enable Ion (SpiderMonkey's JIT compiler) to locate the data at the new location, the GC must leave a forwarding pointer in the header of the old buffer when moving an OOL array.

By setting its LSB to 1, the forwarding pointer can be identified from regular headers. Because of the typo, the forwarding pointer was set to 0, which unintentionally met the isDataInline() function's requirement to identify an array as inline: return (headerWord & 1) == 0;. Because the mechanism is absent from the Baseline compiler, this vulnerability can only be triggered within WebAssembly functions that have been optimized by Ion.

Erge, the researcher, created a proof-of-concept exploit that used the following procedures to obtain full RCE and arbitrary read/write primitives: triggered a small garbage collection, which resulted in the forwarding pointer storing 0. Ion's wasm:Because of the zero forwarding pointer, the Instance::updateFrameForMovingGC function misidentified the array as inline. The function prevented stack frame updates by returning the old array address rather than the new one.

established a use-after-free (UAF) circumstance as Ion kept using the array memory that had been released. To recover freed memory, heap spraying was done using values like 0x41414141. controlled the interpreted data to achieve arbitrary read/write Address of the OOL array base sprayed objects with binary-relative pointers to get around ASLR To take over RIP and run arbitrary system commands, a vtable was overwritten. The last exploit was successful in creating a shell.

(/bin/sh) through the use of the system() function.

Timeline for Disclosure and Patching The disclosure of the vulnerability happened quickly: Date of Event: January 19, 2026; vulnerability introduced by commit fcc2f20e35ec Bug 2013739 was filed by an independent researcher on February 3, 2026 (estimated). Within 72 hours, Erge filed bug 2014014 February 3, 2026 On February 9, 2026, vulnerability was fixed with commit 05ffcde. On February 11, 2026, a security bounty was awarded and divided.

Widespread exploitation was prevented because the vulnerability only affected Firefox 149 Nightly builds and never made it to any release version. LinkedIn, X for daily cybersecurity updates, and Mozilla's security team acted swiftly to patch the vulnerability. The two security researchers who independently found the bug were each given a split bounty reward. To have your stories featured, get in touch with us.