IonStack Part I: Unsound IonBanana Peel in Ion Compiler, Slipping Through Firefox's SpiderMonkey JIT

Despite Anthropic Mythos’s extensive auditing of Firefox, our agent VEGA still managed to uncover CVE-2026-10702, a subtle SpiderMonkey IonMonkey just-in-time miscompilation that can be exploited to achieve arbitrary code execution in the Firefox renderer process. To our knowledge, this is the first SpiderMonkey JIT CVE after Firefox’s last-minute pre-Pwn2Own update, which fixed a large batch of vulnerabilities. We also used it to pwn Tor Browser, showing that even after heavy auditing, JIT compilers still have plenty of places for a banana peel to hide.

Background

SpiderMonkey’s JIT Compiler

Similar to other JavaScript engines used in modern browsers, Firefox’s SpiderMonkey engine employs a multi-tier just-in-time (JIT) compiler. The highest tier is WarpMonkey. This compiler translates JavaScript code into optimized machine code at runtime, significantly improving performance.

CacheIR

CacheIR is a simple typed linear intermediate representation (IR) specializing for compiling inline caches. For example, in a JavaScript function,

1
function f(o) {
2
  return o.x + 1;
3
}

the function may be compiled into bytecode like this:

1
GetArg 0          ; push argument o
2
GetProp "x"       ; compute o.x
3
Int8 1            ; push 1
4
Add               ; add the two values
5
Return

let’s focus on JSOp::GetProp here. In pure js::Interpret, GetProp directly performs the semantic operation:

1
  CASE(GetProp) {
2
    ReservedRooted<Value> lval(&rootValue0, REGS.sp[-1]);
3
    MutableHandleValue res = REGS.stackHandleAt(-1);
4
    ReservedRooted<PropertyName*> name(&rootName0, script->getName(REGS.pc));
5
    if (!GetProperty(cx, lval, name, res)) {
6
      goto error;
7
    }
8
  }
9
  END_CASE(GetProp)

As the script warms up, MaybeEnterJit increments the warm-up counter. Once the Baseline Interpreter threshold is reached, SpiderMonkey creates a JitScript, JitScript owns an ICScript. ICScript owns the IC entries and fallback stubs. This is the main bridge between bytecode and CacheIR.

Initially, each IC entry is set to a fallback stub, so for a GetProp operation, the IC entry will point to the GetProp fallback stub. .

1
ICEntry.firstStub -> GetProp fallback stub

For the GetProp operation, the Baseline Interpreter will call:

1
bool BaselineCodeGen<Handler>::emit_GetProp() {
2
    frame.popRegsAndSync(1);
3

4
    if (!emitNextIC()) {
5
        return false;
6
    }
7

8
    frame.push(R0);
9
    return true;
10
}

the emitNextIC function will generate a call to ICStubReg + ICStub::offsetOfStubCode(). If the first IC entry is a fallback stub, it will reach DoGetPropFallback, which will attach the CacheIR to this stub. If o is an object, the CacheIR can look like this:

1
GuardToObject        inputId 0
2
GuardShape           objId 0, shapeOffset 0
3
LoadFixedSlotResult  objId 0, offsetOffset 8
4
ReturnFromIC

Finally, the IC entry will point to the CacheIR stub:

The CacheIR stub can form a chain of stubs, so the CacheIR can handle different types of objects.

Ion/Warp and MIR

WarpBuilder is the new frontend of the Ion JIT compiler. It compiles the bytecode into MIR (Mid-level Intermediate Representation), and consumes the CacheIR as a source of type information.

As the CacheIR is typed, the WarpBuilder can generate the corresponding MIR instructions directly with type guards, for the bytecode it compiles to MIR with the weaving process. Putting it together, we can have the following diagram:

Then the MIR will be optimized and lowered to LIR (Low-level Intermediate Representation), which is then compiled to machine code.

We will then go through the MIR optimization passes that are relevant to this vulnerability.

Scalar Replacement

Scalar replacement removes an object allocation when the JIT proves the object does not escape. For example, the following code:

1
function f(a, b) {
2
  let o = {x: a, y: b};
3
  return o.x + o.y;
4
}

Normally, the object o would be allocated on the heap. However, if the JIT can prove that o does not escape the function (i.e., it is not returned or stored in a way that outlives the function call), it can optimize away the allocation and instead keep x and y as separate scalar values. So the optimized code would look like this:

1
function f(a, b) {
2
  let x = a;
3
  let y = b;
4
  return x + y;
5
}

This is especially useful for short-lived objects that are only used within the function, as it reduces memory allocation overhead and can improve performance, including temporary objects, temporary Object.keys arrays.

Alias Analysis

One important question in optimization is whether two references can point to the same memory location. This is known as aliasing. Alias analysis is a technique to solve this problem.

In function

1
function f(o) {
2
  let a = o.x;
3
  let b = o.x;
4
  return a + b;
5
}

The two accesses to o.x may alias, meaning they may refer to the same memory location. If the JIT can prove that o does not change between the two accesses, it can optimize the second access away, reusing the value from the first access.

But in

1
function f(o) {
2
  let a = o.x;
3
  g(o);
4
  let b = o.x;
5
  return a + b;
6
}

Now if the JIT compiler cannot prove that g(o) does not modify o.x, it must assume that g(o) can have potential side effects that may change anything, including o. Therefore, the second access to o.x cannot be optimized away, as it may yield a different value than the first access.

In Firefox SpiderMonkey JIT, AliasSet is the MIR instruction’s memory-effect summary. Defined in js/src/jit/MIR.h, it is basically a bitmask plus a load/store bit:

1
  AliasSet::None()
2
  AliasSet::Load(flags)
3
  AliasSet::Store(flags)

where flags is one or more memory categories OR’ed together. Some examples here:

1
  AliasSet::Load(AliasSet::ObjectFields)

means “reads object metadata.”

1
  AliasSet::Load(AliasSet::DynamicSlot)

means “reads values from dynamic slots.”

1
  AliasSet::Store(AliasSet::ObjectFields | AliasSet::DynamicSlot)

means “writes/clobbers object metadata and dynamic slot values.”

1
  AliasSet::Store(AliasSet::Any)

means “unknown side effects; assume it may touch everything.”

Global Value Numbering

Global Value Numbering, or GVN, is an optimization pass that removes redundant MIR computations. For example, in simple arithmetic computations like the MIR code:

1
Add1 = MAdd(a, b)
2
Add2 = MAdd(a, b)

The Add2 can be congruent to Add1. But for memory operations, it will be more complicated. For example, in the following code:

1
load1 = MLoad(o, "x");
2
maybe_write_obj();
3
load2 = MLoad(o, "x");

GVN must not replace load2 with load1 if maybe_write_obj() can modify o.x. Therefore, GVN must check the aliasing of the memory operations. This is where the AliasAnalysis matters. AliasAnalysis can set dependency on instructions. GVN can modify the code based on the aliasing information.

The Vulnerability

We already know that the reordering and removal of several critical instructions are only sound if the JIT optimizer can prove that the target code satisfies certain conditions. But what if the semantic model of the instructions is not fully correct?

Starting from an innocent example

Let’s start from a JavaScript that looks innocent, without any memory storing operation (at least, in the JavaScript source code).

1
for (let k in obj) {
2
  console.log(obj.k);
3
}

At the first glance, it looks like a simple for-in loop that iterates over the properties of obj and logs their values. There is no explicit memory store operation in this code. If you have the same idea, you now share the same idea with the optimizer! Here we should go through the path of the property access. In fact, not all properties are stored in an object’s slots from the beginning. Let us ask ourselves a question: How often do you actually use function.name and function.length? If your answer is “not often”, you are not alone. In fact, the SpiderMonkey engine does not materialize these properties when creating the objects. Instead, it lazily resolves them when they are first accessed.

Here we take a look at a more interesting path. For normal interpreter/builtin Object.keys(function), since it needs to create the list of keys, it has to access those keys, implying a underlying properties resolution. They will all call into fun_enumerate which is the enumerate hook of JSFunctionClassOps.

1
static const JSClassOps JSFunctionClassOps = {
2
    .enumerate = fun_enumerate,
3
    .resolve = fun_resolve,
4
    .mayResolve = fun_mayResolve,
5
    .trace = fun_trace,
6
};

However, in this function we can see that, several properties have special treatment. When resolving length, name and prototype properties, the engine will call into HasOwnProperty.

1
static bool fun_enumerate(JSContext* cx, HandleObject obj) {
2
  MOZ_ASSERT(obj->is<JSFunction>());
3

4
  RootedId id(cx);
5
  bool found;
6

7
  if (obj->as<JSFunction>().needsPrototypeProperty()) {
8
    id = NameToId(cx->names().prototype);
9
    if (!HasOwnProperty(cx, obj, id, &found)) {
10
      return false;
11
    }
12
  }
13

14
  if (!obj->as<JSFunction>().hasResolvedLength()) {
15
    id = NameToId(cx->names().length);
16
    if (!HasOwnProperty(cx, obj, id, &found)) {
17
      return false;
18
    }
19
  }
20

21
  if (!obj->as<JSFunction>().hasResolvedName()) {
22
    id = NameToId(cx->names().name);
23
    if (!HasOwnProperty(cx, obj, id, &found)) {
24
      return false;
25
    }
26
  }
27

28
  return true;
29
}

Finally, this call will reach

1
template <AllowGC allowGC,
2
          LookupResolveMode resolveMode = LookupResolveMode::CheckResolve>
3
static MOZ_ALWAYS_INLINE bool NativeLookupOwnPropertyInline(
4
    JSContext* cx, typename MaybeRooted<NativeObject*, allowGC>::HandleType obj,
5
    typename MaybeRooted<jsid, allowGC>::HandleType id, PropertyResult* propp) {
6
  // Native objects should should avoid `lookupProperty` hooks, and those that
7
  // use them should avoid recursively triggering lookup, and those that still
8
  // violate this guidance are the ModuleEnvironmentObject.
9
  MOZ_ASSERT_IF(obj->getOpsLookupProperty(),
10
                obj->template is<ModuleEnvironmentObject>());
11

12
  // .........
13

14
  // If there is no resolve hook, the property definitely does not exist.
15
  if (obj->getClass()->getResolve()) {
16
    if constexpr (!allowGC) {
17
      return false;
18
    } else {
19
      return CallResolveOp(cx, obj, id, propp);
20
    }
21
  }
22

23
  propp->setNotFound();
24
  return true;
25
}

If the shape does not contain the property, the lookup function will call the resolve hook. The behavior of the resolve hook is related to the type of objects. For example, if the object is a JSFunction, the CallResolveOp will call fun_resolve.

1
static bool fun_resolve(JSContext* cx, HandleObject obj, HandleId id,
2
                        bool* resolvedp) {
3
  if (!id.isAtom()) {
4
    return true;
5
  }
6

7
  // .........
8

9
  bool isLength = id.isAtom(cx->names().length);
10
  if (isLength || id.isAtom(cx->names().name)) {
11
    MOZ_ASSERT(!IsInternalFunctionObject(*obj));
12

13
    RootedValue v(cx);
14

15
    if (isLength) {
16
        // .........
17
    }
18

19
    if (!NativeDefineDataProperty(cx, fun, id, v,
20
                                  JSPROP_READONLY | JSPROP_RESOLVING)) {
21
      return false;
22
    }
23
    // .........
24
  }
25

26
  return true;
27
}

The properties length, name and prototype are lazily resolved. The first time they are accessed, the resolve hook will be called to define them with NativeDefineDataProperty. Similar to other JavaScript engines, SpiderMonkey uses a properties buffer. What if the current property buffer is full? We definitely need to allocate a new property buffer for the new slot.

The ObjectKeysReplacer scalar-replaces an unescaped Object.keys(obj) result with an MObjectToIterator instruction and sets skipRegistration_:

1
bool ObjectKeysReplacer::run(MInstructionIterator& outerIterator) {
2
  MBasicBlock* startBlock = arr_->block();
3

4
  objToIter_ = MObjectToIterator::New(alloc_, objectKeys()->object(), nullptr);
5
  objToIter_->setSkipRegistration(true);
6
  arr_->block()->insertBefore(arr_, objToIter_);
7

8
  // .........
9

10
  if (!graph_.alloc().ensureBallast()) {
11
    return false;
12
  }
13

14
  return true;
15
}

For the MObjectToIterator instruction, the alias set is:

1
AliasSet getAliasSet() const override {
2
  return skipRegistration_
3
             ? AliasSet::Load(AliasSet::ObjectFields | AliasSet::Element)
4
             : AliasSet::Store(AliasSet::Any);
5
}

When skipRegistration_ is true, the alias set is a load of object fields and elements. However, as we discussed above, the MObjectToIterator instruction can allocate a new property buffer, which is not a load operation. This creates a situation where the optimization passes become unsound.

Exploit the Unsoundness

We now know that, under the conditions discussed above, this optimization is unsound. The next question is how to turn this incorrect optimization into an exploitable vulnerability. Back to the MObjectToIterator, we first need to carefully consider what is the side effect of it here. The MObjectToIterator instruction can allocate a new property buffer, if we can reuse the old property buffer after the allocation, this can be turn into a use-after-free vulnerability. With this idea in mind, we would like to see a MIR sequence like this:

1
  Start#0
2

3
  # Load some dynamic-slot property before Object.keys
4
  GuardMultipleShapesToOffset
5
  Slots#1 = MSlots(obj)
6
  LoadDynamicSlotFromOffset#2 = MLoadDynamicSlotFromOffset(Slots#1, offset1)
7

8
  # Scalar-replaced Object.keys(obj)
9
  ObjectToIterator#22 = MObjectToIterator(obj, skipRegistration=true)
10

11
  # Load another dynamic-slot property after Object.keys
12
  GuardMultipleShapesToOffset#3
13
  Slots#4 = MSlots(obj)
14
  LoadDynamicSlotFromOffset#5 = MLoadDynamicSlotFromOffset(Slots#4, offset2)

The two Slots#1 = MSlots(obj) and Slots#4 = MSlots(obj) all depend on Start#0, as the optimizer thinks there is no side effect between them. Therefore, after GVN and elimination, the MIR sequence can be optimized to:

1
  Start#0
2

3
  # Load some dynamic-slot property before Object.keys
4
  GuardMultipleShapesToOffset
5
  Slots#1 = MSlots(obj)
6
  LoadDynamicSlotFromOffset#2 = MLoadDynamicSlotFromOffset(Slots#1, offset1)
7

8
  # Scalar-replaced Object.keys(obj)
9
  ObjectToIterator#22 = MObjectToIterator(obj, skipRegistration=true)
10

11
  # Load another dynamic-slot property after Object.keys
12
  GuardMultipleShapesToOffset#3
13
  LoadDynamicSlotFromOffset#5 = MLoadDynamicSlotFromOffset(Slots#1, offset2)

however, Slots#1 is now a dangling pointer after the MObjectToIterator instruction.

Unsoundness to unreal object

As we mentioned in our previous research blog post, we would like to convert the unsoundness into two important primitives: addrof and fakeobj. The addrof primitive allows us to get the memory address of a JavaScript object, while the fakeobj primitive allows us to create a JavaScript object at a specific memory address. An intuitive way to achieve this is using a crafted or corrupted array. However, there is no pointer compression in SpiderMonkey (which can make the object pointer more predictable), we need to figure out a way to perform our initial data leak.

Let’s say we pre-fill all slots in the property buffer, as shown in the figure below.

Since MObjectToIterator will trigger a lazy property resolution and the property buffer is full, it will allocate a new buffer.

Since we have 3 lazy properties, the Function.name can safely jump over to the nearby spray object and read out the Hidden Class pointer.

Now resolving the Function.name property will actually return the Hidden Class pointer to the JavaScript code.

Depending on the sprayed data, it also be interpreted as an object pointer, which can be used to create a fake object. By crafting a fake Uint8Array object later, we can expand our arbitrary memory read/write primitive to full memory region in SpiderMonkey.

Appendix

Timeline

• 2026-05-20: We reported the vulnerability with exploitation to Mozilla.
• 2026-05-20: Mozilla acknowledged the report and started investigating.
• 2026-05-20: Mozilla identified the root cause and finished the fix.
• 2026-06-02: The fix was released in Firefox 151.0.3.
• 2026-07-21: We published this blog post.

Mitigation

The alias set of MObjectToIterator was refined.

1
--- a/js/src/jit/MIR.h
2
+++ b/js/src/jit/MIR.h
3
@@ -9348,22 +9348,16 @@ class MObjectToIterator : public MUnaryI
4
   }
5

6
  public:
7
   NativeIteratorListHead* enumeratorsAddr() const { return enumeratorsAddr_; }
8
   INSTRUCTION_HEADER(ObjectToIterator)
9
   TRIVIAL_NEW_WRAPPERS
10
   NAMED_OPERANDS((0, object))
11

12
-  AliasSet getAliasSet() const override {
13
-    return skipRegistration_
14
-               ? AliasSet::Load(AliasSet::ObjectFields | AliasSet::Element)
15
-               : AliasSet::Store(AliasSet::Any);
16
-  }
17
-
18
   bool wantsIndices() const { return wantsIndices_; }
19
   void setWantsIndices(bool value) { wantsIndices_ = value; }
20

21
   bool skipRegistration() const { return skipRegistration_; }
22
   void setSkipRegistration(bool value) { skipRegistration_ = value; }
23
 };
24

25
 class MPostIntPtrConversion : public MUnaryInstruction,
26

27
--- a/js/src/jit/MIROps.yaml
28
+++ b/js/src/jit/MIROps.yaml
29
@@ -2370,16 +2370,17 @@
30
   can_recover: custom
31
   possibly_calls: true
32
   generate_lir: true
33

34
 - name: ObjectKeysFromIterator
35
   operands:
36
     iterator: Object
37
   result_type: Object
38
+  alias_set: none
39
   can_recover: true
40

41
 - name: LoadUnboxedScalar
42
   gen_boilerplate: false
43

44
 - name: LoadDataViewElement
45
   gen_boilerplate: false
46

47

48
--- a/js/src/jit/ScalarReplacement.cpp
49
+++ b/js/src/jit/ScalarReplacement.cpp
50
@@ -4113,16 +4113,17 @@ bool ObjectKeysReplacer::escapes(MElemen
51
   return false;
52
 }
53

54
 bool ObjectKeysReplacer::run(MInstructionIterator& outerIterator) {
55
   MBasicBlock* startBlock = arr_->block();
56

57
   objToIter_ = MObjectToIterator::New(alloc_, objectKeys()->object(), nullptr);
58
   objToIter_->setSkipRegistration(true);
59
+  objToIter_->stealResumePoint(arr_);
60
   arr_->block()->insertBefore(arr_, objToIter_);
61

62
   // Iterate over each basic block.
63
   for (ReversePostorderIterator block = graph_.rpoBegin(startBlock);
64
        block != graph_.rpoEnd(); block++) {
65
     if (mir_->shouldCancel("Scalar replacement of Object.keys array object")) {
66
       return false;
67
     }
68
@@ -4147,17 +4148,16 @@ bool ObjectKeysReplacer::run(MInstructio
69
       }
70
     }
71
   }
72

73
   assertSuccess();
74

75
   auto* forRecovery = MObjectKeysFromIterator::New(alloc_, objToIter_);
76
   arr_->block()->insertBefore(arr_, forRecovery);
77
-  forRecovery->stealResumePoint(arr_);
78
   arr_->replaceAllUsesWith(forRecovery);
79

80
   // We need to explicitly discard the instruction since it's marked as
81
   // effectful and we stole its resume point, which will trip assertion
82
   // failures later. We can't discard the instruction out from underneath
83
   // the iterator though, and we can't do the trick where we increment the
84
   // iterator at the top of the loop because we might discard the *next*
85
   // instruction, so we do this goofiness.

For uses, please update to the latest version of Firefox.

Acknowledgements

We would like to thank the SpiderMonkey team for their quick response and thorough investigation of this issue.

Disclosure policy

For all bugs found by Vega, we follow our standard 90+30 days disclosure policy as described on our About page.