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-...

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!

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!

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!

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! :)

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)

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

Here's another V8 sandbox design document, this time discussing how sensitive ("trusted") V8-internal objects (such as BytecodeArrays) can be protected: docs.google.com/document/d/1... This should be one of the last pieces of infrastructure required for the sandbox.