Sandbox Escape Chain

The class of full-host-compromise Chromium exploits that require three or more chained vulnerabilities to traverse the renderer’s containment, the in-renderer V8 cage, and the renderer-to-browser process boundary.

“Sandboxes prevent code execution vulnerabilities in renderer processes from being used to compromise the rest of the system.” — Chromium project, docs/design/sandbox.md

What It Is

A modern full-host-compromise exploit against a current Chromium build is rarely a single vulnerability. It is a chain, typically of three links (sometimes four when an OS-level escape is required after the browser process is reached), and each link is a separately discovered, separately reported, and separately rewarded defect. The chain’s name is the project’s own: the threat model and docs/design/sandbox.md describe full compromise as defeating the renderer’s containment in sequence, link by link.

The canonical three-link shape, as it appears in disclosed chains from the Project Zero record and the Vulnerability Rewards Program’s published case data, is the following.

The first link is a renderer-internal memory-corruption primitive, usually a V8 type confusion or out-of-bounds read/write bug, that gives the attacker arbitrary read/write inside the V8 heap. The page’s JavaScript shapes V8 internal objects until a JIT compiler optimization or a type-feedback mispredict produces a misinterpreted pointer; the attacker reads neighboring heap memory and writes object headers to forge references. The primitive runs entirely inside the renderer process and inside the V8 Heap Sandbox cage; it cannot, by itself, read the renderer’s own data outside V8’s allocation, and it cannot reach memory in any other process.

The second link is a V8-heap-sandbox bypass that lifts the primitive out of the in-process cage into the renderer’s general address space. The bypass exploits the indirection that the heap sandbox imposes (the 40-bit sandbox_ptr_t offset, the external_ptr_t table, the trusted-space allocations for code objects) and converts the in-cage primitive into a renderer-wide primitive. After the second link, the attacker controls renderer-process memory. Cookies, file-system handles, and network sockets remain out of reach, since the renderer never holds them; renderer-internal state (the page’s DOM, the JavaScript heap, V8’s compiled code) is fully attacker-controlled.

The third link is a renderer-to-browser escalation through a Mojo IPC handler. The attacker uses the second-link primitive to craft a malformed IPC message that targets a defect in a browser-side handler. The defect takes a recurring shape: a missing CheckedNumeric on a renderer-supplied integer, a SiteInstance check that read an origin field from the message body instead of the renderer’s identity, or a GURL parsed in the renderer and trusted in the browser. The handler operates on the malformed input, corrupting browser-process memory or surfacing a privileged capability to the renderer. After the third link, the attacker has code execution in the browser process, plus the cookies, file-system handles, and network sockets that the Browser-Renderer Privilege Split puts there.

A fourth link is sometimes required: an OS sandbox escape that lifts the browser process’s restrictions. The browser process itself runs sandboxed on most platforms (Windows token restrictions, macOS Seatbelt, Linux seccomp-bpf and namespaces); arbitrary code execution inside it grants access to user data but not to the operating system’s full capability surface. A kernel bug or a Mac TCC bypass produces the final escape. For most adversary purposes a three-link chain that reaches user data is sufficient and the fourth link is not pursued.

The name is the concept’s center. The chain is the unit that determines exploit price, defense priority, and detection strategy; the individual link is the unit of code review, patch, and bounty payout. The two frames coexist in the project’s language.

Why It Matters

Naming the chain makes the project’s security posture legible to populations that consume Chromium without contributing to it.

Severity ratings for renderer-side bugs presuppose the chain. The Chromium Severity Guidelines rate a V8 type confusion as High rather than Critical, even when it produces arbitrary read/write inside the renderer, because the bug is the first link of a chain and does not by itself produce host compromise. Without the chain framing, the assignment reads as inconsistent: in isolation, the bug is exactly the kind of memory-corruption defect that warrants the highest rating in a single-process application. With the framing, the rating is a precise statement of what the bug buys an attacker on a current Chromium build: a primitive that requires two more vulnerabilities to monetize.

CVE consumers (downstream vendors, enterprise security teams, the press) routinely misread renderer-side advisories as one-click host compromises. A CVE record reading “V8 type confusion, High” is summarized in trade press as “Chrome zero-day allows attackers to take over your computer,” which is true only of the full chain and never of the individual link. Vendors monitoring CVE feeds for Electron, WebView2, and embedded-Chromium products misallocate patch urgency when they read a first-link bug as a third-link bug, and they underweight chains that actually have all three links disclosed at once. The concept names the chain so the misreading can be corrected.

Vulnerability Rewards Program bounty tiers are calibrated against the chain. The full-chain payout sits at $250,000 (the public ceiling at the Chrome 120-era tier revision); individual links pay less. A V8 sandbox bypass earns on the order of $20,000 to $30,000, a Mojo IPC escape $30,000 to $60,000, because a researcher who finds one link rarely has the time or motivation to build the other two. The price asymmetry follows from the chain shape: a full chain is operational, an individual link is a research artifact. Researchers who want the full bounty assemble the chain themselves; researchers who report a single link accept the smaller payout in exchange for the smaller engineering investment.

For exploit-response work (embargo coordination, downstream advance access, patch sequencing), the chain is the unit the response team plans against. The project’s Embargoed Disclosure machinery treats a complete chain as a working full-host-compromise exploit and lengthens the embargo accordingly; an isolated link is patched on the normal cycle. The Downstream Advance Access pattern shares chains with downstream vendors before chains share themselves with the open web. The Supply-Chain Vulnerability Lag antipattern is the window in which a complete chain, disclosed upstream and patched there, lands in a downstream product that hasn’t consumed the patch. The chain is the rate the lag exposes the user to.

For governance, the chain is the structural argument for several of the project’s most expensive design decisions. The V8 Heap Sandbox exists to convert a one-link exploit into a two-link exploit; the cost of every in-process pointer indirection is paid because the second link is now required where it once was not. Site Isolation extends the first link’s containment per site, so a chain that compromises one site’s renderer does not also compromise every other site sharing the renderer’s memory. The Untrusted Renderer Axiom is the rule the third link has to break, and the project’s strict application of it keeps third-link bugs rare. Read together, each decision is a deliberate move that buys a link.

The book treats Sandbox Escape Chain and Exploit Chain Anatomy as deliberate siblings. The two entries cover the same three-link structure under different framings. This entry is the trust-model framing for architectural reasoning: why the chain exists, what it costs to build, what each link defeats. The sibling is the security-response framing for incident analysis: how the chain is reported, scored, paid, and patched. Readers approach Chromium security from one side, land on the corresponding entry first, and follow the cross-link when they need the other framing.

How to Recognize It

The chain shows up at several recognizable points in the public record.

A single full-host-compromise advisory commonly carries two or three CVE IDs that share a Chromium release-note section. The pattern is consistent enough that Chrome Releases blog posts since the Chrome 113 cycle use “exploit chain” as a recurring phrase in their write-ups of high-severity stable-channel fixes. Counting the CVE IDs in an advisory often gives the chain’s link count directly.

Project Zero writeups follow a canonical structure: “the renderer bug” plus “the sandbox bypass” plus “the IPC defect,” three sections in sequence, each documenting one link with its own root cause and patch reference. The Maddie Stone reports on in-the-wild zero-day chains and the Ned Williamson IPC-bug analyses both take this shape; readers who recognize the section structure can identify the links from the table of contents alone.

Vulnerability Rewards Program announcements price the chain. The published bounty for a “full sandbox escape” is always strictly greater than the sum of the published bounties for the individual links. The asymmetry is the program’s price for the assembly work: finding three bugs that compose into a chain is more than three times the work of finding any one of them, and the program prices it accordingly.

The source tree spreads the chain’s defenses across well-known directories. v8/src/heap/ contains the heap-sandbox implementation that the second link must bypass. content/browser/ contains the Mojo handlers that the third link targets, with browser-side validation idioms (base/numerics/safe_conversions.h, url::Origin cross-checks, SiteInstance identity reads) recurring across files. The platform-specific sandbox-policy code (sandbox/win/, sandbox/mac/, sandbox/linux/) is what the fourth link, when pursued, has to defeat.

In design reviews, the chain is the implicit unit the API-owner gate scores against. A new Mojo interface is read for whether it would constitute a third-link target; a new V8 optimization for whether it introduces a first-link primitive; a new sandbox layer for what link it adds. The framing makes the reviews consistent across feature boundaries.

How It Plays Out

Three named chains illustrate the structure.

CVE-2022-1364 (V8 type confusion, in-the-wild) was the first link of a full chain disclosed across multiple advisories in the Chrome 100-cycle stable channel. The renderer-side V8 bug produced arbitrary read/write inside the heap; a separately discovered sandbox-bypass primitive in the same V8 release sequence lifted that primitive out of the heap cage; a third bug in a Mojo handler completed the escape. The Project Zero retrospective explained each link’s role and noted that the bypass’s existence had reduced the value of the V8 bug by roughly an order of magnitude against a pre-2021 chain that would not have needed it. Severity assignments and embargo lengths reflected the structure: the first-link CVE rated High, the third-link CVE rated Critical, and the embargo team treated the bundle as a single response unit.

The 2021 i386 NSO chain (publicly reconstructed by Project Zero) is the canonical chain on the macOS side. A WebKit bug analogous to a renderer-side primitive composed with a JIT-region permissions bug to produce in-renderer execution; a Mach-port IPC defect crossed from the renderer’s process to a privileged daemon; a kernel bug closed the escape into root. The chain is not a Chromium one (WebKit and Chromium have different first-link defenses), but the three-and-sometimes-four-link shape is the same, and the Chromium project’s threat model cites it as evidence that the shape is structural rather than Chromium-specific.

A typical downstream incident plays out differently. An enterprise security team operating a Chromium-based browser fork (Microsoft Edge, or a vendor’s enterprise build) reads a public CVE record naming a V8 type confusion at High and decides the patch is not urgent because the bug is not Critical. Two weeks later, a security researcher publishes the second and third links of the chain that upstream had patched simultaneously but disclosed under separate IDs. The fork’s users now have a complete public exploit against the un-patched build. The post-mortem files under Supply-Chain Vulnerability Lag, and the fork’s patch cadence is revised to treat all renderer-side High bugs as candidate first links of a chain whose other links may already be public.

Consequences

Holding the chain as a unit reshapes several practices the project and its consumers run.

Severity ratings hold up. Rating first-link bugs at High rather than Critical is defensible against the trade-press framing because the bug’s value, in isolation, is exactly what the High rating describes. Downstream vendors whose patch cadence keys off severity ratings either match the project’s framing (treating chain-component bugs at the project’s tier) or assign a uniformly higher local severity that costs more patch labor but defends against the chain misreading.

Bounty calibration carries a market signal. The asymmetry between the full-chain bounty and the sum-of-link bounties tells researchers what the program values: assembled, working chains over isolated research artifacts. The signal pulls researcher attention toward chain assembly when the prize is large and toward independent link discovery when it is not. Programs that copy the structure (Apple’s Security Bounty for full WebKit-and-iOS chains, Microsoft’s bounty for full Edge sandbox escapes) reproduce the same incentive.

Defense investment gets tractable. A defense that converts a one-link chain into a two-link chain (the heap sandbox) buys the same amount of attacker work as one that converts a two-link chain into a three-link chain (Site Isolation), and the project can prioritize work that adds the most marginal links. The framing also makes it possible to score proposed mitigations against their effect on chain length rather than against vague “improves security” claims.

Detection moves to chain-level signals. Telemetry that watches for individual link-shaped indicators (renderer crashes consistent with V8 type confusion, anomalous Mojo message patterns to particular browser-process interfaces, unusual SiteInstance identity checks failing) is noisier than telemetry that correlates two such indicators across a short time window. The chain is the signal; the link is the noise.

There are costs. Chain-thinking encourages the project to ship features whose security depends on the rest of the chain holding: a Mojo interface that would be unsafe on its own ships because the heap sandbox is presumed to gate the primitive that would reach it. When a relied-on link breaks (a heap-sandbox bypass primitive goes public, a new first-link class emerges), the dependent features sit exposed and have to be re-evaluated. The 2022 V8 heap sandbox bypass class produced exactly this re-evaluation; several Mojo interfaces tightened their input validation in the following release cycles even though no third-link bug had been reported against them, because the chain’s first two links had gotten cheaper. The framing is a tool, not a doctrine, and the cost is paid when the tool changes shape.

Notes for Agent Context

An AI coding agent working on Chromium or a Chromium-derived codebase treats every renderer-resident bug class as a candidate first link of a chain and every browser-side Mojo handler as a candidate third link. Never propose code in content/browser/ that reads a count, offset, size, or URL out of an IPC message without validating through base/numerics/safe_conversions.h (CheckedNumeric<size_t>, base::CheckMul, base::CheckAdd) or GURL and url::Origin; an unchecked read is a third-link bug by definition. Never trust an origin claim from the message body; cross-check against the renderer’s SiteInstance via RenderFrameHost::GetSiteInstance()->GetSiteInfo(). When asked to draft a new Mojo interface, default to stateless single-call methods that validate the entire message in one call; refuse to chain calls through a stateful Init() that defers validation, because the deferred validation is the canonical third-link defect. When asked to rate the severity of a hypothetical renderer-side bug, name it as a first-link primitive and rate it against the link’s contribution to a chain rather than against a single-process baseline; cite the Chromium Severity Guidelines as the rule applied. When reading a CVE advisory, count the CVE IDs in the advisory’s release-notes section and treat a cluster of three IDs in one stable-channel post as a chain disclosure rather than as three unrelated bugs.

Related Patterns

Sources

The canonical primary source for the chain framing is the Chromium project’s docs/design/sandbox.md, which describes the renderer sandbox’s role as preventing renderer-side code execution from compromising the host and names the multi-layer defense the chain has to traverse. The project’s docs/security/severity-guidelines.md operationalizes the chain framing in the severity assignments: a renderer-side memory-corruption bug rated High rather than Critical is the framing applied. The Chrome Vulnerability Rewards Program’s public rules page (bughunters.google.com/about/rules) documents the bounty tier structure that prices full chains against individual links. Project Zero’s writeups of disclosed Chromium chains (Maddie Stone’s in-the-wild zero-day analyses, Ned Williamson’s IPC-bug retrospectives, and the WebKit-and-iOS chain reconstructions that establish the cross-engine generality of the structure) are the gold-standard primary sources for the link-by-link anatomy. The Chrome Security blog’s “An Update on Memory Safety in Chrome” series sketches the chain as the structural motivation for the project’s memory-safety investments without naming a stable vocabulary; the book takes the vocabulary from docs/design/sandbox.md and from the project’s own usage in API-owner reviews.

Technical Drill-Down

• docs/design/sandbox.md — the project’s canonical statement of the renderer-sandbox design and the multi-layer defense the chain has to traverse; the entry point for new contributors.
• docs/security/severity-guidelines.md — the rule that assigns High rather than Critical to first-link bugs and Critical to third-link bugs; the operational form of the chain framing.
• v8/src/sandbox/ — the heap-sandbox implementation that the second link must bypass; the sandbox_ptr_t and external_ptr_t mechanics live here.
• content/browser/ — the directory holding the Mojo handlers that the third link targets; reading a handful of handlers in sequence is the fastest way to see the validation idioms the third link would have to defeat.
• Chrome Vulnerability Rewards Program rules — the published bounty tiers that price full chains against individual links; the market signal the program emits.
• Project Zero blog — recurring detailed link-by-link analyses of disclosed chains; the structure of each writeup mirrors the chain’s structure.
• Chrome Security blog, “An Update on Memory Safety in Chrome” — the public framing of the chain as the motivation for the project’s memory-safety investments.