{"id":1196,"date":"2026-02-19T12:38:33","date_gmt":"2026-02-19T12:38:33","guid":{"rendered":"https:\/\/netguide.io\/news\/?p=1196"},"modified":"2026-02-19T12:40:47","modified_gmt":"2026-02-19T12:40:47","slug":"the-fatal-character-how-a-single-typo-triggered-an-rce-vulnerability-in-firefox","status":"publish","type":"post","link":"https:\/\/netguide.io\/news\/en\/2026\/02\/19\/the-fatal-character-how-a-single-typo-triggered-an-rce-vulnerability-in-firefox\/","title":{"rendered":"The Fatal Character: How a Single Typo Triggered an RCE Vulnerability in Firefox"},"content":{"rendered":"\n

Mountain View\/London – In the high-stakes world of software engineering, the difference between a secure system and a total compromise can be a single keystroke. Security researcher “Erge” has documented how a simple typo in SpiderMonkey-Firefox’s JavaScript engine-created a critical Remote Code Execution (RCE) vulnerability, allowing attackers to execute arbitrary code within the browser’s renderer process.<\/strong><\/p>\n\n\n\n

The flaw was discovered in February 2026 while the researcher was auditing the Firefox source code for an upcoming “Capture The Flag” (CTF) competition. The bug resided in the WebAssembly (Wasm) component, specifically within the memory management for Garbage-Collected (GC) arrays.<\/p>\n\n\n\n

The “Guilty Commit”: An &<\/code> Instead of a |<\/code><\/h3>\n\n\n\n

The root cause of the vulnerability traces back to a refactoring of Wasm array metadata. In the file js\/src\/wasm\/WasmGcObject.cpp<\/code>, a classic logical error occurred during bitwise manipulation:<\/p>\n\n\n\n

\n

The flawed code snippet:<\/strong><\/p>\n\n\n\n

C++<\/p>\n\n\n\n

\/\/ Intended to use a bitwise OR (|) to set a flag.\noolHeaderOld->word = uintptr_t(oolHeaderNew) & 1; \/\/ The error: '&' instead of '|'\n<\/code><\/pre>\n<\/blockquote>\n\n\n\n
As noted in the technical write-up, the code was intended to store a “forwarding pointer” by setting its least significant bit (LSB) to 1. However, because pointers in modern 64-bit systems are 8-byte aligned, their LSB is always 0. Performing a bitwise AND (&<\/code>) with 1 effectively forced the stored value to 0<\/strong> every time.<\/p>\n\n\n\n
Inline vs. Out-of-Line: A Memory Misunderstanding<\/h3>\n\n\n\n
To understand the severity, one must look at how Firefox stores Wasm arrays. The engine uses two distinct layouts:<\/p>\n\n\n\n
    \n
  1. Inline (IL):<\/strong> Data is stored directly within the object (optimized for small arrays).<\/li>\n\n\n\n
  2. Out-of-Line (OOL):<\/strong> The object contains a pointer to a separate memory block (used for larger arrays).<\/li>\n<\/ol>\n\n\n\n
    Because of the typo, the engine failed to correctly tag moved OOL arrays. When the system checked the header, the missing bit led it to believe a large, relocated array was still an “Inline” array.<\/p>\n\n\n\n
    From Logic Error to Full System Takeover<\/h3>\n\n\n\n
    The researcher demonstrated that this confusion leads to a Use-After-Free (UAF)<\/strong> condition. When the Garbage Collector (GC) moves an array, it frees the old memory. However, SpiderMonkey’s JIT compiler (Ion), misled by the faulty header, continues to access the old, now-freed memory address.<\/p>\n\n\n\n
    By utilizing “heap spraying”-a technique where the memory is flooded with attacker-controlled data-Erge was able to:<\/p>\n\n\n\n