explaingit

crixpwn/cve-2026-8389

Analysis updated 2026-05-18

38HTMLAudience · researcherComplexity · 5/5Setup · hard

TLDR

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.

Mindmap

mindmap
  root((CVE write-up))
    What it does
      Documents a Firefox bug
      Already patched in 150.0.3
    Root cause
      28-bit position field
      Missing size check
      Background compile path
    Consequence
      Wrong exception handling
      Type confusion
    Tech stack
      SpiderMonkey
      C plus plus
      JIT compiler
    Audience
      Security researchers
      Browser engineers

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

What do people build with it?

USE CASE 1

Study how a missing bounds check in a background compiler path led to memory corruption.

USE CASE 2

Learn how browser exception handling can be hijacked by a truncated internal offset.

USE CASE 3

Reference this write-up when researching or teaching browser JIT exploitation techniques.

What is it built with?

SpiderMonkeyC++Firefox

How does it compare?

crixpwn/cve-2026-83890xsha/cve-2026-6307ebookfoundation/without-a-net
Stars383838
LanguageHTMLHTMLHTML
Setup difficultyhardhardeasy
Complexity5/55/51/5
Audienceresearcherdevelopergeneral

Figures from each repo's GitHub metadata at analysis time.

How do you get it running?

Difficulty · hard Time to first run · 1day+

This is a vulnerability analysis document, not runnable software, understanding it requires familiarity with JIT compilers and C++ browser internals.

In plain English

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.

Copy-paste prompts

Prompt 1
Explain in simple terms how the pcOffset truncation bug in crixpwn/CVE-2026-8389 leads to a type confusion.
Prompt 2
Walk me through the code path from MaybeDoEagerBaselineCompilations to HandleExceptionBaseline described in this CVE write-up.
Prompt 3
Summarize why the eager off-thread baseline-compile path was missing the size check that the main-thread path had.

Frequently asked questions

What is cve-2026-8389?

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.

What language is cve-2026-8389 written in?

Mainly HTML. The stack also includes SpiderMonkey, C++, Firefox.

How hard is cve-2026-8389 to set up?

Setup difficulty is rated hard, with roughly 1day+ to a first successful run.

Who is cve-2026-8389 for?

Mainly researcher.

Open on GitHub → Explain another repo

This repo across BitVibe Labs

Verify against the repo before relying on details.