V8 Heap Sandbox: In-Process Isolation

• V8 Heap Sandbox is a software-based fault isolation mechanism that confines untrusted JavaScript and WebAssembly heap memory to protect the engine's critical internals.
• It employs pointer elimination, 40-bit offset representation, and translation tables to create a strict boundary between untrusted and trusted memory domains.
• Empirical fault injection analysis revealed 19 security vulnerabilities, highlighting the need for rigorous boundary enforcement and defensive coding practices.

Searching arXiv for the provided paper and closely related work on browser SFI / heap sandboxing. The V8 heap sandbox is an in-process software-based fault isolation (SFI) mechanism in Google’s V8 JavaScript engine that confines JavaScript and WebAssembly heap memory used by untrusted code, with the objective of preventing memory-corruption vulnerabilities from escalating into the engine’s security-critical internals or the host system. It is described as the primary SFI defense in V8 and as a prominent example of modern SFI deployment in Chromium-based browsers, Node.js, and Electron. In the formulation studied in "Empirical Security Analysis of Software-based Fault Isolation through Controlled Fault Injection" (Bars et al., 9 Sep 2025), the heap sandbox divides the process address space into a trusted domain and an untrusted heap sandbox, removes raw pointers from sandbox-accessible heap data structures, and uses translation tables to resolve references to trusted objects. Within that threat model, an attacker may fully control sandbox memory, but is not supposed to corrupt trusted data unless code at the boundary mishandles sandbox-derived values (Bars et al., 9 Sep 2025).

1. Definition and security objective

The V8 heap sandbox is intended to contain memory corruption: even if a bug permits arbitrary reads or writes inside JavaScript’s heap, the mechanism is designed to prevent attacker access to, or corruption of, trusted data outside that region. The trusted domain contains security-sensitive components such as metadata, the C stack and heap, code, and JIT artifacts, while the untrusted domain contains most JavaScript and WebAssembly heap objects.

This design addresses a specific attack surface in modern browsers. Because browsers process scripts, media, and executable code from unknown sources, they form a critical security boundary. JavaScript engines are especially relevant because they expose a large attack surface arising from the complexity of contemporary engine implementations. The paper situates the heap sandbox as a mitigation against that attack surface, particularly for vulnerabilities that arise from logic bugs in JIT code generation, which the summary notes cannot be fully prevented by memory-safe languages or hardware mitigations (Bars et al., 9 Sep 2025).

The security objective is therefore not to make the JavaScript heap itself free of corruption. Rather, the objective is to prevent corruption within that heap from crossing into the trusted domain. The paper’s threat model explicitly assumes that untrusted JavaScript or WebAssembly can fully corrupt its own objects; the security question is whether such control can be transformed into memory corruption affecting trusted memory outside the cage.

2. Isolation architecture and address-space organization

The heap sandbox splits the address space into two fault domains.

1. Untrusted Heap Sandbox: this region contains most JavaScript and WebAssembly heap objects and is treated as fully attacker-controllable under the threat model.
2. Trusted Domain: this region contains metadata, the C stack and heap, code, and JIT artifacts, and is the region for which integrity and confidentiality guarantees are required.

In the technical summary, the sandboxed JavaScript heap is described as a 1 TiB cage. The key architectural property is that memory reachable by untrusted code is structurally separated from trusted metadata and runtime state. The paper’s description emphasizes that the protection boundary is not provided by a separate process, but by in-process SFI mechanisms applied to object representation and reference resolution.

This organization is central to the sandbox’s security model. The isolation boundary is meaningful only insofar as trusted code treats all data imported from the heap sandbox as hostile input. The summary therefore presents the sandbox not merely as a region of memory, but as an interface discipline: any data passed from the sandboxed heap to trusted code must be validated or sanitized.

A plausible implication is that the heap sandbox is best understood as a hybrid of memory-layout isolation and API-level boundary enforcement. The first constrains the addresses that corrupted heap data can name directly; the second governs whether sandbox-derived values can influence trusted allocations, control flow, or access to protected metadata.

3. Pointer elimination, offsets, and translation tables

The principal implementation technique is the removal of raw pointers from heap data structures accessible to the sandbox. This is paired with a two-level reference model.

For intra-sandbox references, V8 represents references as 40-bit offsets relative to the sandbox base. If $\text{BASE}$ is the heap-cage start and $\text{offset}$ is the encoded value, then address reconstruction is described as

$\text{Real Address} = \text{BASE} + \text{offset}$

Because these offsets are bounded to the sandbox representation, attacker-overwritten offsets are intended to grant access only within the cage.

For references to trusted objects, such as JIT code or internal structures, the paper states that V8 uses protected lookup tables. These translation tables map safe indices to full 64-bit addresses and are stored outside attacker control. As summarized in the paper, all accesses to the trusted domain outside the heap must go through checked translation tables.

The intended consequence of this design is explicit in the summary:

• raw pointers are eliminated from sandbox-accessible heap data;
• large offsets are not permitted in sandbox-region data;
• outside-data references are indirected through translation tables rather than encoded directly in heap-controlled structures.

This arrangement is meant to ensure that pointer corruption in the sandbox does not directly become pointer corruption into trusted memory. The abstract states the intended guarantee succinctly: even with full control of sandboxed data, an attacker cannot corrupt trusted data unless there is a bug in how code handles data from the sandboxed heap (Bars et al., 9 Sep 2025).

4. Boundary enforcement as software-based fault isolation

The heap sandbox is an instance of software-based fault isolation. In the paper’s formulation, SFI is enforced by the absence of raw pointers in attacker-controlled heap objects and by mandatory mediation through translation tables for trusted references. The security boundary therefore lies at every point where data flows from the sandboxed heap into trusted C++, JIT-generated code, or CSA-generated code.

The summary describes the relevant interface in concrete terms. Testing scope includes all code paths where attacker-controlled heap data is:

1. passed into C++ or JIT/CSA-generated trusted code, or
2. used to access translation tables or allocate buffers in trusted memory.

This formulation clarifies that the heap sandbox does not protect against all misuse of sandbox-derived data. If trusted code reads a sandbox value and interprets it as a length, enum discriminant, or translation-table index without adequate validation, the SFI boundary can be violated even though raw pointers remain absent from heap memory.

A common misconception is that an SFI mechanism of this kind is “set and forget.” The summary directly rejects that interpretation, stating that the heap sandbox is a powerful mitigation, but that its security relies critically on perfect boundary enforcement at all points where untrusted data is interpreted in the trusted domain (Bars et al., 9 Sep 2025). The resulting picture is one in which isolation is only as strong as the code that consumes sandbox-controlled values.

5. Empirical security analysis and controlled fault injection

The paper introduces SbxBrk, a fault-injection fuzzer tailored to the SFI boundary in V8. Its purpose is to model a post-exploitation setting in which the attacker already has full control of sandbox memory and attempts to induce memory corruption in the trusted domain.

The methodology proceeds in several stages.

First, the implementation instruments memory loads in V8 that may cross from sandbox memory to the trusted domain. Loads from stack or globals in the trusted domain are ignored. The summary states that both statically compiled C code and dynamically generated JIT code are covered by modifying compilation passes and V8’s assembler as needed.

Second, an Interceptor component checks at runtime whether the source address of a load is inside the sandbox. If so, the loaded value may be mutated to simulate attacker-controlled corruption. The summary describes this as applying a bitwise XOR or other mutation to the loaded value.

Third, the injected faults are persistent: the mutated value is stored back so that subsequent loads observe the same corruption. Inputs consist of JavaScript or WebAssembly programs together with fault bitmasks, and these are mutated under a coverage-guided fuzzing loop.

Fourth, standard coverage instrumentation is used to retain and further mutate faults that reach new code paths.

The threat model is deliberately strong. The attacker controls all data in the untrusted heap sandbox, and the testing setup includes controlled concurrency via JavaScript Worker threads in order to model race conditions and double-fetch bugs. This is significant because the paper treats concurrency not as an incidental complication but as part of the realistic attack surface at the SFI boundary (Bars et al., 9 Sep 2025).

A plausible implication is that the method is less a generic browser fuzzer than a boundary-specific adversarial execution model. The summary states that existing fuzzers, including engine test suites and advanced JavaScript fuzzers such as Fuzzilli, fail to exercise the precise attack surface introduced by SFI domain crossings unless fault injection is performed at that boundary.

6. Discovered vulnerabilities, bug classes, and security implications

In a comprehensive evaluation, the paper reports 19 previously unknown V8 security vulnerabilities that enable an attacker to bypass the sandbox and compromise the trusted domain. All were responsibly disclosed to Google (Bars et al., 9 Sep 2025).

The attack surface is characterized broadly: any code that copies or interprets data from the heap sandbox without careful validation is a potential bug site. The summary identifies several bug classes and representative examples.

Bug class	Example	Result
Double-Fetch/TOCTOU	TypedArraySortFast double fetch	OOB Write
Stack/Heap Buffer Overflow	JSON.stringify on huge string	OOB Write
Use-after-free	URIError serialization	Use-after-free
Unsafe Enum Construction	Discriminant from heap data	UB/Corruption
Translation Table Index Injection	Unvalidated index to trusted table	Arbitrary write

The paper describes double-fetch / TOCTOU bugs as cases in which heap data such as a length field is fetched twice without sufficient synchronization or copying, allowing an attacker to change the contents between reads and thereby cause heap or stack buffer overflows or other out-of-bounds writes. The cited example is TypedArraySortFast, where a buffer is allocated based on a stale size and later used under an attacker-updated size.

It also reports use-after-free behavior, with URIError serialization given as an example in which copying data to a new buffer can trigger a use-after-free and enable heap corruption.

For stack or heap overflows, the summary cites integer-overflow conditions during string conversion, including JSON.stringify or BigInt() on giant strings, producing incorrectly sized buffers that are subsequently overflowed.

Another category is unsafe enum discriminant construction. Here, sandbox-derived data is used to construct enum values fed into switch statements. If the attacker can synthesize an unsupported variant, the execution may enter undefined behavior, for example via a missing return path.

Finally, the paper identifies lookup-table indexing via unvalidated heap data, including out-of-bounds writes through unvalidated translation-table indices. In these cases, attacker-supplied heap data is used as an index into trusted translation tables without bounds checks, potentially yielding arbitrary writes with trusted pointers.

The paper’s attack-path description is structured as a three-step progression: maliciously prepared heap data is passed to trusted code; trusted code interprets the value as a length, enum, or index without adequate validation; and the resulting behavior triggers buffer overflow, use-after-free, or undefined behavior in the trusted region, thereby violating the heap sandbox’s isolation guarantees.

The broader significance is twofold. First, the findings show that mature sandboxes can still harbor boundary bugs severe enough to permit escape. Second, the summary notes that some vulnerabilities are compiler-version or optimization dependent, because register allocation, heap loads, and lowering strategy may expose or hide particular bugs. This suggests that the security properties of the heap sandbox are partly conditioned by the surrounding build and code-generation pipeline, not solely by the abstract design.

7. Hardening guidance and broader relevance

The recommendations in the summary are operational and narrowly targeted at the boundary between sandbox and trusted code.

The first recommendation is rigorous auditing and automated testing of all code handling data that crosses the SFI boundary. Every heap-to-trusted load should be treated as hostile input and subjected to strong validation or sanitization.

The second is to prevent repeated reads of untrusted data without explicit memory fencing or trusted copies. Where possible, heap fields should be fetched once into trusted memory before further use. When concurrency is possible, APIs should be designed to be idempotent or otherwise resistant to TOCTOU behavior.

The third is to enforce exhaustive handling of enums and variants that originate from untrusted data. The summary specifically recommends defensive programming with default cases for switch statements on attacker-controlled enum values.

The fourth is careful translation-table index validation. Attacker-supplied indices must be checked for bounds and legality before dereference.

The fifth concerns the build process. Because some bugs depend on code generation, the summary recommends hardening testing against codegen variation and ensuring that likely compiler and optimization combinations are covered.

The sixth is to integrate SFI-aware fuzzing into continuous integration, including tools such as SbxBrk or similar mechanisms for regression testing.

The summary also states that fault injection across SFI boundaries is broadly applicable and encourages extensions to mechanisms such as Firefox’s RLBox (Bars et al., 9 Sep 2025). This does not establish equivalence between systems, but it indicates that the testing principle is not unique to V8. A plausible implication is that SFI mechanisms should be evaluated not only by their abstract memory-partitioning design, but also by adversarial testing directed at the exact semantics of cross-domain data use.

Taken together, the paper presents the V8 heap sandbox as a substantial isolation mechanism whose effectiveness depends on a narrow but critical condition: trusted code must never mis-handle values imported from the sandboxed heap. The empirical result that 19 security bugs were found under a threat model with full sandbox-memory control underscores that, in this setting, the decisive security property is boundary correctness rather than mere memory separation (Bars et al., 9 Sep 2025).