0-Days in 72 Hours: How Octane Found Vulnerabilities in the Code Behind 99.7% of Browser Traffic

Just three browser engines power nearly the entirety of the consumer internet. Blink (Chromium), WebKit (Safari), and Gecko (Firefox) together account for 99.7% of all browser traffic.

Browser engines are the core software responsible for interpreting and rendering web content. A meaningful vulnerability in any of this code means an exploitable bug in critical infrastructure for the modern internet.

For the in-house security researcher – let’s call him Stig, whom we let loose with Octane – that prospect is exactly what made this project worth doing.

Smart contracts were the first proving ground for our thesis that AI-native security analysis can outperform legacy workflows on high-stakes code. Crypto is an ideal venue for testing out new theses in a highly adversarial industry. But the broader claim was always bigger than that. If the underlying approach had real merit, it should generalize to other environments, other languages, and other classes of vulnerability.

For Stig, browser engines felt like an obvious place to test that theory.

They are large (the Chromium codebase alone weighs in at over 28GB), security-critical, and constantly exposed to untrusted inputs. They’re the only thing between a malicious website and the user’s machine. The size of these codebases also means manual coverage is essentially impossible.

Google and Apple have some of the deepest pools of software engineer talent to draw on of any organization in the world. And it still wasn’t enough.

This is the story of how the same AI-native security analysis process we use in our Adversarial Research Engagements helped uncover vulnerabilities across the browser engines behind 99.7% of browser traffic, and what that means for application security going forward.

72 Hours from Ideation to 0-Day

Stig focused on the parts of the Chromium source code responsible for handling media, JavaScript, HTML, and CSS. If the goal is to find bugs exploitable from a user-visits-a-malicious-website scenario, those are the surfaces that matter most. From there, Stig guided the analysis toward issue classes with the highest payoff, especially memory corruption and memory disclosure.

Stig chose the target surfaces, defined the vulnerability classes worth pursuing, tightened scope assumptions as noisy results came back, and used Octane as an instrument under expert direction rather than a black-box report generator. This researcher-in-the-loop model is the same structure we use in AREs: directed analysis, context definition, iterative refinement, then exploitation and validation.

One candidate finding stood out as a likely memory disclosure bug. After Stig wrote a proof of concept and ran it locally, it began returning random bytes. Re-running it returned different bytes, which was already a strong sign. Under debugger inspection, those leaked values turned out to include heap pointers. Once Stig extended the PoC to parse them reliably, he had a working exploit path.

This project had gone from a theory to a working 0-day in under 72 hours.

The New Division of Labor

In Book 1, Chapter 1 of The Wealth of Nations, Adam Smith identified "the invention of a great number of machines which facilitate and abridge labour, and enable one man to do the work of many" as being one of the major drivers of productivity increases.

250 years later, the default manual path in cybersecurity research still usually involves fuzzing, which requires digging deeply enough into each component to build harnesses, tuning those harnesses, and then waiting for crashes or other useful signals. That process is much better at surfacing clearly crashy memory corruption issues than more subtle memory disclosure. If a bug leaks sensitive bytes without obviously blowing up the process, fuzzing alone is a blunter instrument when trying to find it.

But with Octane, instead of spending the first phase building harnesses for each component, Stig could start from a list of candidate findings with reasoning already attached. Octane narrowed down the search to the files and paths that were most likely to matter, then surfaced potential vulnerabilities in natural language with enough context to make triage effective and efficient. That does not eliminate human work, but it does dramatically change what the human researcher spends their time on – “enabl[ing] one man to do the work of many.”

Researchers stop burning energy on figuring out where to look and start spending it on the higher-value parts of the job: validating exploitability, refining assumptions, and writing proofs of concept.

This new division of labor is the core thing AppSec teams should pay attention to. The strategic win is not that “AI replaces researchers.” It is that AI collapses the discovery phase, which lets human expertise concentrate on confirmation and remediation – ensuring the findings replicate in the real world, and then fixing them.

CVE-2026-5888

This work earned us CVE-2026-5888.

The National Vulnerability Database defines CVE-2026-5888 as an uninitialized use in WebCodecs VideoFrame.copyTo(codedRect) in Google Chrome that allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page.

This was a heap disclosure that could leak sensitive renderer memory and heap pointers to JavaScript that should never be exposed. While on its own it’s not a critical vulnerability that allows remote execution or other catastrophic access, this kind of finding enables more complex exploit chains to build on top of it for a more serious end result. Such exploits are often carefully assembled from smaller pieces: an information leak here and some memory corruption there can combine for far more serious results.

Gecko and WebKit

Blink/Chromium was the anchor finding, but by using a similar strategy against Gecko, and incrementally feeding root causes for noisy results back into the scope assumptions, Stig found three memory disclosure vulnerabilities in the browser engine under the hood of Firefox. All three were proven with PoC scripts and reported to Mozilla. As Stig kept adding sharper context about what the code was really doing and where earlier assumptions were wrong, Octane’s output quality improved. That is exactly the same dynamic our customers see when they feed more project-specific context into Octane over time.

WebKit yielded similar issue classes, but because remediation is still ongoing we’re deliberately withholding specifics.

What This Proves

The first takeaway is product-related: Octane generalizes far beyond blockchain.

Many teams still mentally bucket security tools into discrete categories: smart contract analysis, static analysis, web app scanning, manual review, browser research, etc. But the reality is much more fluid (and interesting). Once you have a system that can reason over large codebases, interpret context intelligently, and iterate with a human researcher on the right assumptions, the same core workflow can extend into general application security and low-level memory vulnerabilities in mission-critical software – and then beyond that too.

The second is a broader takeaway for the entire industry: AI is no longer optional in serious security research.

As AI massively compresses the discovery phase, human judgment becomes more important, not less. The heavy lifting moves from finding to validating, and the nature of human security research work changes. The researcher who can direct AI-native discovery, distinguish an LLM’s signal from its noise, validate exploitability, and refine the search will simply cover more ground than both the researcher who insists on doing everything the old and slow way, and the one who leaves all the work to AI.

And as AI is increasingly used to attack platforms and protocols, an old and slow approach to security just doesn’t cut it anymore.

Secure Your Entire Stack with Octane

If Octane can earn novel CVEs in browser engines, it can help secure the rest of your stack too.

High-stakes software now demands AI-scale discovery plus human validation, and that’s the exact model we built Octane around from day one.

Onboard your codebase today.