Chrome Exploit Mitigations

June 2nd, 2026 – Alisa Esage

Introduction

Earlier this year I invested several weeks full-time in zero day engineering for Google Chrome and validating my mental models of frontier browser defenses. I found and reported to Chromium VRP a number of security bugs across renderer, network service, and browser process. This article will focus on three modern Chrome-specific exploit mitigations that I had to confront while writing the exploits: MiraclePtr, v8 sandbox, and PartitionAlloc.

Before getting to those three, I met the old guard: ASLR, CFI, CORS and the sandbox security model itself. These are generally well understood and I will only briefly mention my experience with them here.

As my bugs spanned the full stack of Chrome technology – from a renderer RCE to network service partial-EoP and browser process EoP for sandbox escape, all memory corruption issues – I consider this subset of mitigations somewhat representative of the actual resistance surface that a modern Chrome attacker will face; and a priority for offensive R&D.

Some of my bugs bypassed the relevant Chrome mitigations, while others were blocked by them despite my best effort. I cover both types in this article, as much as the present stage of responsible disclosure permits. Full technical details of the exploits will be disclosed in due course.

For a compressed systematic exposure to prerequisite knowledge, I recommend my Browser Exploit Design course.

The Landscape

Chrome has many exploit mitigations that are doing more work than public knowledge suggests.

The tables below are actual as of current Stable (M148).

PartitionAlloc

V8 Sandbox

V8 (non-sandbox)

Process / Sandbox

IPC / Mojo

Control-Flow Integrity (native)

Compiler / OS Baseline

Web Platform

Spectre / Side-Channel

Not all the mitigations at once are at work against every Chrome exploit chain. An exploit would usually hit a small subset of mitigations, which depends on the bug class, operating system, hardware architecture, field trials configuration, user configuration, Chrome version, specific bug instance shape, and other factors.

That said, certain mitigations are more prohibitive while others are mostly obstacles in the exploit engineering process.

The Old Guard

Familiar exploit mitigations – such as ASLR and CFI – are still relevant and present a substantial obstacle to exploit engineering for modern Chrome.

Consider ASLR. The common bounce-off judgement from an "exploit expert": "Just find an infoleak bug to bypass it". Technically correct, but... In my experience, reality differs.

First, pure memory disclosure vulnerabilities in Chrome are rare. This is both statistical and structural. I looked at most Chrome security bugs of the past year, plus selectively picked prior samples. I didn't get an impression that a memory disclosure bug in Chrome is easy.

Furthermore, an infoleak bug must be located in the same process as the main bug to be chainable, which constrains the search space. Every process type in Chrome is a different world with its own anti-patterns, architectural models and implementation details. A problem like "I need to find an infoleak in renderer and another one in the browser process" isn't the same problem repeated twice, it's two different specialization projects.

Historically, ASLR in Chrome renderer was weakened by JavaScript engine type confusion vulnerabilities. A typical JSE bug is powerful enough that it can work twice: first to disclose memory and break ASLR, then to execute the code. [1] Enablement of v8 sandbox in M124 broke this convenience, and made ASLR hard again for the Chrome renderer.

In contrast, the broker process, GPU process and other high-privilege browser processes never had this kind of a luxury bug class to coast through ASLR, which is why the majority of wild 0-day chains for Chrome use either logic bugs for the sandbox escape part, or an OS kernel EoP (another restricted attack surface), or settle on a renderer-only payload, or attack a peculiar configuration – all compromises driven by the cost of an honest infoleak chain in the browser process.

Another assumed solution to bypass ASLR is to "make" an infoleak out of a compatible use-after-free bug. In fact, PartitionAlloc blocks many state manipulations on use-after-free bugs, while MiraclePtr shrinks the attack surface.

A similar situation with CFI/CFG (Control Flow Integrity). In Chrome, CFI is baked into every object vtable dispatch by the compiler, excluding a handful of code-annotated exceptions, which makes the coverage broad and solid. It means that any accidental vtable call on a use-after-free object will hit a hard crash, and if that happens early enough in the bug's state machine, it becomes unexploitable.

In general, most of the old-gen mitigations are not invariants, but rather cost-raisers. An encounter with them is often bypassable with the same bug and a bit of luck. Newer Chrome-specific mitigations tend to be more solid. If a bug is blocked by it, it's often game over – go find another one.

Further sections deal with the newer mitigations that I experienced.

MiraclePtr

MiraclePtr – also known as BackupRefPtr or BRP – is a fairly recent and ambitious addition to Chrome's list of exploit mitigations. It aims to make use-after-free bugs unexploitable without eliminating them, at the cost of manually wrapping each pointer in raw_ptr<T>, plus some runtime overhead. Design docs and developer's instructions are published [1 2 3], although it's best understood by reading the code, which is compact.

The security invariant offered by MiraclePtr: "as long as a dangling raw_ptr<T> exists, the slot is not reused". This is achieved by 1) counting pointer instances in a field under InSlotMetadata, and 2) quarantining the freed memory if InSlotMetadata counter isn't zero on free. Coverage is per-field and per-process, not whole-allocator.

I first encountered MiraclePtr at the stage of vulnerability discovery. I found a bug by static analysis; it looked good until I tested it with Address Sanitizer...

That was surprising: I knew about raw_ptr<T> and didn't see it in the code? Turns out that MiraclePtr was recently (and quietly) rolled into some popular chromium idioms, so it's invisible in the code unless you look deep into familiar system internals. Sneaky!

I spent some time looking at the MiraclePtr implementation, and couldn't find a bypass in the given time. It's quite obvious that the code was heavily scrutinized and hedged against anything that could go wrong. I didn't bother reporting the bug – Google officially considers MiraclePtr-PROTECTED bugs strongly mitigated. On those Chromium builds that don't enable MiraclePtr mitigation, it's still an exploitable 0-day.

Meanwhile, my other bugs escaped MiraclePtr – they are UNPROTECTED and exploitable in release Chrome before the patch.

PartitionAlloc

PartitionAlloc manages all the memory in official Chrome, including C++ new operator, and excluding v8 (which uses Oilpan). PartitionAlloc has been ramping exploit mitigations for years, and by now is a bit of a beast. MiraclePtr implementation is based on PartitionAlloc infrastructure, too. Official documentation is in the chromium docs [4].

Out of many mitigations in PartitionAlloc, Thread Cache itself – as in, separate freelists per thread – doesn't have a reputation as an exploit blocker. Indeed, it was built as a performance optimization and never offered any strong security invariants. In reality, it quietly mitigates many bug shapes in the browser process.

I have dealt with Thread Cache directly and passed by encoded freelist pointers, cacheline poisoning (0xbadbad00), and scheduler loop quarantine (0xcdcdcdcd) when working on the exploit for a double-free issue in the browser process. The latter was surprising, since Scheduler Loop Quarantine isn't supposed to be enabled yet – it's actually enabled in Dev channel via field trials configuration.

Consider the following scenario: a use-after-free bug in the browser process. As of current Chromium, the majority of objects in the browser process live in the same PA root partition, so reclaiming the freed object doesn't look hard in code. The problem is the multi-threading architecture of the browser process combined with the per-thread cache. This combination constrains object reclamation paths to those used in the vulnerable thread, which substantially shrinks the opportunity space to even begin to control the state machine from the bug. The following diagram illustrates the problem.

In this scenario, a bypass of Thread Cache depends on the bug's control flow graph escaping between free and re-use of the vulnerable object to allocate memory elsewhere to force a purge to the shared bucket. If the bug's code site is tight between free and re-use, it becomes unexploitable and heap grooming via another thread doesn't help. The same bug without Thread Cache would be exploitable. The specific bug that I worked with was of the former type and was effectively blocked by the mitigation in official Chrome.

v8 sandbox

v8 sandbox works by breaking common JavaScript Engine exploit idioms at a deep level of abstraction, which makes it efficient. Consider in-object pointer indirection, one of the key features of v8 sandbox. In a JavaScript engine, many object types have a pointer in them, which points to additional data (such as array contents in an ArrayBuffer). A typical JavaScript bug allows to craft a fake JavaScript object, which the unsuspecting engine then uses – dereferencing the fake inner pointer and thereby reading/writing to arbitrary memory whatever the JavaScript code requires. This allows to build an arbitrary RW primitive through the bug, a canonical JavaScript engine exploitation technique. The v8 sandbox replaces in-object pointers with indexes in out-of-sandbox tables, which breaks the exploit primitive universally. This feature alone isn't sufficient to break every exploit, and v8 sandbox doesn't end on it. Many official design docs are available [5 6].

All known public bypasses of the v8 sandbox, including 0-days, are bugs in the sandbox code. I looked at most of v8 sandbox bypasses (more than 80 issues in 2025), the bug patterns were eliminated systematically, and the implementation is substantially hardened now.

My renderer exploit bypasses the v8 sandbox by using a special kind of v8 bug that isn't fully covered by the sandbox. The exploit achieves arbitrary address read and write. This is an interesting attack surface for lateral thinking about attacking v8 in post-v8 sandbox era.

Conclusions

Chrome exploit mitigations continue to harden while being asymmetrically concentrated in the browser process and high-privilege processes, with the renderer and v8 now catching up.

Bypassing Chrome-specific mitigations head-on becomes nearly impossible; the open path lies through blind spots in coverage, platform-specific weaknesses, and bugs in mitigation code.

All current mitigations have limits, some of them structural (e.g., optimization). Those limits mark the edge of the practical attack surface.

Logic issues such as UXSS gain importance, as they are the least covered by current exploit mitigations.

Relevant Products

Browser Exploit Design — hands-on self-paced training in modern browser exploitation. Focus on class-wide models, canonical bug classes and exploit techniques, and full-chain perspective.

Pi — Pattern Insight — subscription intelligence service with in-depth research and analysis.

References

1. MiraclePtr One Pager
2. BackupRefPtr design document
3. Developer docs — raw_ptr.md (source.chromium.org)
4. PartitionAlloc docs (source.chromium.org)
5. V8 Sandbox design document
6. V8 sandbox README (source.chromium.org)
7. Chrome Security Architecture diagram