crixpwn/cve-2026-8389 — explained in plain English
Analysis updated 2026-05-18
Study how a missing bounds check in a background compiler path led to memory corruption.
Learn how browser exception handling can be hijacked by a truncated internal offset.
Reference this write-up when researching or teaching browser JIT exploitation techniques.
| crixpwn/cve-2026-8389 | 0xsha/cve-2026-6307 | ebookfoundation/without-a-net | |
|---|---|---|---|
| Stars | 38 | 38 | 38 |
| Language | HTML | HTML | HTML |
| Setup difficulty | hard | hard | easy |
| Complexity | 5/5 | 5/5 | 1/5 |
| Audience | researcher | developer | general |
Figures from each repo's GitHub metadata at analysis time.
This is a vulnerability analysis document, not runnable software, understanding it requires familiarity with JIT compilers and C++ browser internals.
This repository documents a security vulnerability in Firefox's SpiderMonkey JavaScript engine. It was prepared for the Pwn2Own 2026 Berlin competition but was patched in Firefox version 150.0.3 before the competition took place. The vulnerability is a bitfield truncation in the baseline JIT compiler. SpiderMonkey's JIT stores the bytecode offset for each compiled call site in a 28-bit field inside a data structure called RetAddrEntry. The maximum allowed script length was sized to match those 28 bits. However, that length check only ran on the main-thread compilation path. A separate eager off-thread baseline compilation path skipped the check entirely, so a JavaScript script whose bytecode exceeded 256 MB could pass through the off-thread path without being rejected. When that happened, the stored offset was silently truncated to fit the 28-bit field. The truncated offset is read back during exception handling. SpiderMonkey converts the stored offset to a bytecode pointer and passes it to the exception handler to match try-note entries for the current execution point. Because the truncated offset is still within the bounds of the script's bytecode buffer, the access does not immediately crash. Instead, the exception handler works with the wrong bytecode position, reads an incorrect stack slot, and treats a non-object value as if it were a JavaScript object. That type confusion is the starting point for further exploitation. The repository includes annotated C++ code excerpts from the affected source files, showing the construction and storage of the offset, the gating check that was missing on the off-thread path, and the call chain through which the truncated value reaches the exception handler.
A write-up explaining a now-patched Firefox JavaScript engine bug where a size limit check was skipped, letting a corrupted internal value cause a type confusion.
Mainly HTML. The stack also includes SpiderMonkey, C++, Firefox.
Setup difficulty is rated hard, with roughly 1day+ to a first successful run.
Mainly researcher.
This repo across BitVibe Labs
Verify against the repo before relying on details.