The fuzzer that found project-zero.issues.chromium.org/issues?q=com... (and a number of issues prior to that as well) is now open-source: crrev.com/c/7580844
It uses pkeys, trap-handling and single-stepping to intercept and mutate in-sandbox reads (see trap-fuzzer.h). Definitely had fun writing it!
Today, Project Zero released a 0-click exploit chain for the Pixel 9. While it targets the Pixel, the 0-click bug and exploit techniques we used apply to most other Android devices.
projectzero.google/2026/01/pixe...
V8 now has a JS bytecode verifier!
IMO a good example for the benefits of the V8 Sandbox architecture:
- Hard: verify that bytecode is correct (no memory corruption)
- Easier: verify that it is secure (no out-of-sandbox memory corruption)
The sandbox basically separates correctness from security.
We derestricted a number of vulnerabilities found by Big Sleep in JavaScriptCore today: issuetracker.google.com/issues?q=com...
All of them were fixed in the iOS 26.1 (and equivalent) update last month. Definitely some cool bugs in there!
I've uploaded the slides of my recent talk "JS Engine Security in 2025": saelo.github.io/presentation.... I think there'll also be a recording available at some point (otherwise I can make one as not everything's in the slides).
Fantastic conference as usual, big thanks to the PoC Crew!
Some more cool JS Engine bugs found by Big Sleep were fixed in yesterday's Apple security updates: support.apple.com/en-us/125632
Technical details will be available soon at issuetracker.google.com/issues?q=com...
We derestricted crbug.com/382005099 today which might just be my favorite bug of the last few years: bad interaction between WebAudio changing the CPU's handling of floats and V8 not expecting that. See crbug.com/382005099#co... for a PoC exploit. Also affected other browsers
I have often stated that well-implemented memory tagging will be a game changer for memory corruptions. And it seems that with the next iPhone it's finally here: security.apple.com/blog/memory-...
It's been a great pleasure being part of the core V8 team and I'll still be active in the V8 Security space in a (mostly) consulting role to help ensure the V8 Sandbox keeps progressing and becomes a strong security boundary! :)
Some personal news: I'm thrilled to be moving back to Project Zero! Specifically I'll be joining the Big Sleep project to find vulnerabilities in JavaScript engines. We've already found and reported our first vulnerability in V8 last week: issuetracker.google.com/issues/43621...
We released our Fuzzilli-based V8 Sandbox fuzzer: github.com/googleprojec...
It explores the heap to find interesting objects and corrupts them in a deterministic way using V8's memory corruption API. Happy fuzzing!
It's not (yet) meant for production use, but should offer a preliminary look at where things might be heading. See crbug.com/350324877 for more details.
Feedback welcome! :)
If you have a machine with PKEY support and somewhat recent Linux kernel you can now play around with hardware support for the V8 sandbox. When active, JS + Wasm code has no write permissions outside the sandbox address space. To enable, simply set `v8_enable_sandbox_hardware_support = true`.
V8 Security is hiring in Munich, Germany: www.google.com/about/career...
Great opportunity to work on some really hard and interesting problems in the security space!
And I've also updated our V8 Exploit Tracker sheet now: docs.google.com/document/d/1... (see the 2025 tab) :)
chromereleases.googleblog.com/2025/06/stable-channel-update-for-desktop.html
Some cool things to note though:
- the bug was mitigated via finch kill switch a day after the report from TAG
- we also fixed the V8 Sandbox bypass within 7 days even though it's not yet considered a security boundary
I’m very excited to announce that we at V8 Security have finally published our first version of Fuzzilli that understands Wasm!
Go check it out at https://github.com/googleprojectzero/fuzzilli
While we still have a way to go in improving it, we think it shows a promising approach!
Another big step towards becoming a security boundary: today we’re expanding the VRP for the V8 Sandbox
* No longer limited to d8
* Rewards for controlled writes increased to $20k
* Any memory corruption outside the sandbox is now in scope
bughunters.google.com/about/rules/...
Happy hacking!
This for example shows that the V8 Sandbox is pretty promising in terms of "bug coverage". Of course that also assumes that it'll become a strong security boundary (it's still pretty soft at the moment), see bsky.app/profile/sael...
Thanks to events like Pwn2Own or our V8CTF (~= exploit bounty program), we now have more data about the types of bugs exploited in V8. Based on that, we've gathered some basic statistics: docs.google.com/document/d/1...
And the recording is now also public: youtu.be/5otAw81AHQ0?... thanks @offensivecon.bsky.social!
Finally got around to publishing the slides of my talk @offensivecon.bsky.social from ~two weeks ago. Sorry for the delay!
The V8 Heap Sandbox: saelo.github.io/presentation...
Fantastic conference, as usual! :)
Thanks Justin!
Big day for the V8 Sandbox:
* Now included in the Chrome VRP: g.co/chrome/vrp/#...
* Motivation & goals discussed in a new technical blog post: v8.dev/blog/sandbox
If there is ever a Sandbox "beta" release, this is it!
New V8 Sandbox design document is out: docs.google.com/document/d/1...
This discusses how a hardware-based sandbox instead of the currently purely software-based one might look like in a somewhat distant future (if at all)
Benchmark results on Speedometer2 showing that the overall performance impact of the V8 sandbox is only around 1% total
Some early performance numbers for the V8 Sandbox: looks like with most of the performance critical parts in place now, the overall performance cost of this future security boundary is only around 1% on popular benchmarks \o/
More results linked from chromium-review.googlesource.com/c/v8/v8/+/52...
I've been meaning to write this for some time now and finally got around to it: a "V8 Sandbox Glossary" document that briefly explains the most important terms/concepts used for the sandbox and links to the respective design documents: docs.google.com/document/d/1...
Another exciting step for the V8 sandbox: with crrev.com/c/5007733 BytecodeArrays are now the first objects to move into the new trusted heap space! Still a number of remaining issues around bytecode execution, but this fixes the long-standing issue that an attacker could directly corrupt bytecode
