sneakynachos/cve-2026-2764-but-with-wasmProof-of-concept exploit chain for Firefox JIT CVE-2026-2764, chaining JIT miscompilation and use-after-free into arbitrary read/write and WASM shellcode execution.
Status: analysis + validated PoC. Primitive weaponization in progress.
A WasmBlazeFox-style chain built on a 2026 bug this time: CVE-2026-2764, an IonMonkey/baseline "JIT miscompilation + use-after-free" in the JavaScript Engine: JIT component, fixed in Firefox 148 (MFSA 2026-13, CVSS TBD). Same endgame as CVE-2024-29943-but-with-wasm: feed the primitive into a WASM JIT page full of shellcode constants.
Bugzilla bug 2012608 is restricted, but the fix landed in public:
hg 1b58f51668d3 — "Bug 2012608: Call CreateThis directly from PBL":
PortableBaselineInterpret.cpp stopped routing scripted-constructor
this-creation through CreateThisFromIC (which re-read IC state) and now
calls js::CreateThis directly with properly rooted values.hg 3adad00d0042 — formatting/docs on 's
contract (argc must include spread arguments).BaselineCacheIRCompiler.cppcreateThishg 57885d520e85 — the regression tests (our PoCs).Failure mode: on new Ctor(...arr) / Reflect.construct with a Proxy as
newTarget, the proxy's get trap runs while the engine is between
spreading the arguments and creating this. That callback can mutate or
free the very array the engine is spreading, and the engine continues with
stale assumptions:
arr[0] swapped int -> object after the spread snapshot
(poc-typeconfusion.js)arr.length = 0; gc() frees the elements store mid-spread
(poc-uaf.js)Against the 2026-02-09 mozilla-central nightly jsshell (JavaScript-C149.0a1,
linux x86-64, pre-fix), in an x86_64 Docker container:
./js poc-typeconfusion.js -> Error: Assertion failed: got "oops", expected 1
./js poc-uaf.js -> Segmentation fault
Both PoCs are Mozilla's own regression tests, verbatim.
poc-typeconfusion.js (controllable argument-value confusion, no crash)
-> Ion-optimize a constructor that makes baked type assumptions on its
spread arguments; swap in an object where an int32 was proven
-> addrof / fakeobj
-> corrupt TypedArray length -> arbitrary R/W
-> WASM JIT shellcode stage (same as CVE-2024-29943-but-with-wasm:
f64.const immediates, FuncExport entry-offset overwrite)
The WASM stage and offset-walk code port over unchanged except for offsets
to re-derive against the FF149-era build (see
CVE-2024-29943-but-with-wasm/test.gdb for the recipe).
1b58f51668d3, 3adad00d0042, tests 57885d520e85