I wrote a short blogpost on the quirks of grammar fuzzing (and, more generally, structure-aware fuzzing) and a simple trick I used to get more bugs out of it more quickly. https://projectzero.google/2026/03/mutational-grammar-fuzzing.html
Ivan Fratric
- 1,088 Followers
- 34 Following
- 40 Posts
Tech lead and security researcher at Google Project Zero. Views / opinions are my own.
Jann Hornfun fact: when you download a RAR file in Chrome on Linux with advanced protection enabled, Chrome will try to extract symlinks from the RAR file to the host filesystem with symlink() syscalls, which are blocked by seccomp so nothing bad actually happens
https://issues.chromium.org/issues/374351426
https://issues.chromium.org/issues/374351426
For the side channel crowd:
I wrote about how side channels in serialization can theoretically allow breaking ASLR - with a theoretical worst-case example of how a single round trip of deserializing attacker-controlled data, serializing the result again, and sending the re-serialized data to an attacker could leak an entire pointer:
"Pointer leaks through pointer-keyed data structures"
https://googleprojectzero.blogspot.com/2025/09/pointer-leaks-through-pointer-keyed.html
I found a Linux kernel security bug (in AF_UNIX) and decided to write a kernel exploit for it that can go straight from "attacker can run arbitrary native code in a seccomp-sandboxed Chrome renderer" to kernel compromise:
https://googleprojectzero.blogspot.com/2025/08/from-chrome-renderer-code-exec-to-kernel.html
This post includes fun things like:
- a nice semi-arbitrary read primitive combined with an annoying write primitive
- slowing down usercopy without FUSE or userfaultfd
CONFIG_RANDOMIZE_KSTACK_OFFSETas an exploitation aid- a rarely-used kernel feature that Chrome doesn't need but is reachable in the Chrome sandbox
sched_getcpu()usable inside Chrome renderers despitegetcpubeing blocked by seccomp (thanks to vDSO)
Natalie SilvanovichWhile most vendors ship timely patches for vulnerabilities reported by Project Zero, they don’t always reach users. Today, we’re announcing Reporting Transparency, a new policy to encourage downstream fixes
https://googleprojectzero.blogspot.com/2025/07/reporting-transparency.html
In my recent conference talks on browser security, I showed a calc-popping exploit demo that targets Firefox 135.0. For educational purposes, to try to demistify some of that calc popping magic, the demo code is now public https://project-zero.issues.chromium.org/issues/389079450#comment7
Last week, I gave a talk on web browser security research at a student-organized conference. I tried to make the talk reasonably beginner-friendly, so the slides (linked here) could hopefully be useful to someone as a learning resource. https://docs.google.com/presentation/d/1rEPiqV0KBHAI0lVym283OHzYRXNCCuGudmDby1Z1qyc/edit?usp=sharing
...and now the video of my talk "Finding and Exploiting 20-year-old bugs in Web Browsers" is live too https://www.youtube.com/watch?v=U1kc7fcF5Ao
OffensiveCon25 - Ivan Fratric - Finding and Exploiting 20-Year-Old Bugs in Web Browsers
The slides for my OffensiveCon talk "Finding and Exploiting 20-year-old bugs in Web Browsers" https://docs.google.com/presentation/d/1pAosPlKUw4uI5lfg7FVheTZAtI5mUy8iDeE4znprV34/edit?usp=sharing
dillonfrankeThrilled to announce my new Project Zero blog post is LIVE! 🎉 I detail my knowledge-driven fuzzing process to find sandbox escape vulnerabilities in CoreAudio on MacOS.
I'll talk about this and the exploitation process next week
@offensive_con
https://googleprojectzero.blogspot.com/2025/05/breaking-sound-barrier-part-i-fuzzing.html
