At the beginning of this year, 2026, I decided to dive into a topic I've wanted to explore for a few years now (ever since I started learning hacking). That topic is Browser Exploitation. I spent a few months trying to learn and find something valid. I kept hitting my head against the wall, but in the end, everything worked out and I found a bug!! :D
Hello world! I've been hacking for as long as I can remember (thanks to BoitaTech/Marcio Herobrine), and a topic that's always fascinated me but seemed really tough was Browser Exploitation. I think that spark started when my friend Luskabol first showed me a client-side bug from PaulosYibelo. That client-side bug was "DoubleClickjacking," a sophisticated popup attack, that to my young and unprepared mind, it was something easy to understand that I could exploit in bug bounties. But why am I telling you this? Just to give you some background on what made me love browsers and how they work so much (even though I'm no genius when it comes to browser or client-side exploitation).
In February 2026, I decided to go deep into trying to find a high-severity vulnerability in Chromium. Why? It’s something that would give me a huge sense of personal satisfaction (and it really did)! After spending a good chunk of time analyzing and evaluating how most vuln researchers were able to drop bugs in complex systems, I eventually came to understand some methodologies that, for the most part, consist of:
Variant Analysis: This method consists of looking at the past—looking at previous bugs and doing patch diffing, root cause analysis, and trying to find the same variant (breaking an invariant) that caused the vulnerability you’re analyzing. To do this, you need to understand some concepts of how software is maintained, but that’s a topic for another blog post. Just remember: every codebase has assumptions and rules that the developer never expected to be broken. (This is important.)
Deep diving into a subcomponent: Just like everything in life, we break big things down into small parts. Even your thoughts work like this—you abstract things but at the same time isolate parts of them to be able to think. The process of finding vulnerabilities is no different. And the most important step that yields the most results is this: deeply understanding a small section, a small part of something bigger (the software you’re analyzing).
Monitoring sudden changes and code additions or removals: This is one of the points I like most and that taught me the most, because being the first to analyze something usually makes it easier to find things, SINCE almost no one has meticulously looked over it yet. So, monitoring changes in the codebase can help find new flaws.
Besides all this, there are countless other ways I’ll mention later in the blog post (or in others), such as fuzzing, etc.
In the beginning (January, yeah, before I started going deep), I decided to look for logic bugs (mostly client-side bugs that affected browser policies) because of a friend and inspiration, Herrera. For those who don't know, Herrera is a guy who's really good at anything involving browsers (yeah, the guy is a beast at it). However, this sounds easy, but it's way, way (seriously way) harder than I expected, and since I wanted to find a bug with at least a HIGH severity, I decided to pivot and go back to some notes from last year (yeah, I had tried to find bugs a long time ago, but my limited intelligence at the time didn't allow it LOL). I found some ideas and notes, and remembered my frustrated attempts to find memory corruption bugs via fuzzing; I was pretty clueless back then, so all my attempts failed miserably. But that reignited a spark in me to try and find memory corruption bugs (after all, it's a lot of fun—a bug like this can be a piece of a chain that can be as powerful as a weapon). And this is where our blog post begins:
"Blink dev", the desk at the front of the classroom
Basically, blink-dev is a Google Group where CHROMIUM project developers and maintainers discuss new features and project updates; every new feature or major code change is announced there. And it's public (a gold mine for anyone who wants to spot something before everyone else). There, you can see features that are about to be released, in-experiment, etc. But how does this help find a flaw in Chromium? It helps A LOT, because it lets you win the race of who can look at it first. (After all, almost nobody checks this group with that intention).
I decided to look into this and it really helped me find the vulnerability I reported. And by the way, this is quite a tip, but moving on. While looking at the group, I stumbled upon something that was very likely to be extremely vulnerable titled "WebAudio: Configurable render quantum." Basically, this feature extends control over the size of the internal block used to process audio in WebAudio; previously, WebAudio processed the audio graph in fixed blocks of 128 frames, called render quantums. The explanation for adding this feature was the issue of latency—to optimize. A great motivation, but if done incorrectly, it can cause memory corruption bugs.
Finding the Vulnerability, but the easy way.
Nature operates in the shortest way possible.
I'm someone who's kind of lazy, but when I'm motivated, I'm extremely dedicated. However, that motivation doesn't last long, but during my motivation peaks, I found a good way to find flaws in WebAPIs without much effort, thanks to a Mozilla article: https://hacks.mozilla.org/2020/04/fuzzing-with-webidl/ (it's a bit old but still very much worth it). Basically, I decided to spend the remaining time of my motivation burst writing a super simple fuzzer that used the Web Audio WebIDL, permuting quantities to try to exceed limits and hit edge cases in this new API. (Of course, since Chromium pays for bugs in experimental features, I could use the experimental feature flag for the WebAudio render quantum). I coded something super simple that fuzzed several inputs using just an HTML page to try to cause anomalous behavior, similar to (though more rudimentary than) what was done in the article mentioned above.
With everything ready to go, all that's left is the crash detection tool. I didn't even have to build an ASAN version myself, as Google provides the latest ASAN release (here). This meant I could jump straight into fuzzing. And impressively, within a few minutes, the page had already crashed with an ASAN heap overflow result. :D
Finding the root cause, but the stupid way
While many would go after the source code and try to understand the root cause (I don't judge, I'd do the same if I had endless motivation), I decided to go the dumb but easier way. Which was simply to take the fuzzer output that caused the crash, isolate the attempts, and end up with just a minimal PoC. In the end, after this tedious but simple process, I was left with:
<!DOCTYPE html>
<script>
try {
const ctx = new AudioContext({
renderSizeHint: 57456,
latencyHint: 'playback'
});
const shaper = ctx.createWaveShaper();
shaper.connect(ctx.destination);
shaper.oversample = '4x';
} catch (e) {
console.error(e);
}
</script>
Pretty short, right? That was all I needed to trigger the memory corruption
Basically, it's a bug that happens because the WebAudio WebAPI started accepting renderSizeHint and configurable render quanta. However, internal paths like WaveShaper + oversampling + FFT still relied on size invariants that were only validated by DCHECK. Essentially, an HTML page could create an AudioContext/OfflineAudioContext with an unusual or extreme render size and then force the WaveShaper pipeline with oversampling to hit the FFT with an fft_size that falls outside the internal assumptions. The "why" is that the configurable render quantum feature expanded the range of sizes that WebAudio could process; previously, a lot of code could treat the audio block as something small/expected, but now the site could suggest a different size.
Conclusion
Now, to wrap things up, I'd like to finish with an exploit, but that's a job for a future blog post. So, I'll say "Bye!" for now, and I hope you learned something or that I helped you out with this post. I hope to write the weaponization part in the coming days (which unfortunately I did too late, long after the bug had already been paid out).
Appendix
Timeline:
2026-02-13: Reported the bug to Google.
2026-02-13: First Response from Google.
2026-02-13: Bug Triaged! (Lets goo)
2026-03-13: Bug Paid ($7K+)
2026-06-02: Disclosure (14w)