AI Browser Vulnerability Research

Part 1
The Rise of AI-Driven Browser Vulnerability Research

August 13, 2026

Vulnerability research in JavaScript engines needs to keep evolving to remain effective in a context increasingly influenced by AI.

LLMs can work alongside the researcher when they are integrated into the research infrastructure itself. They can analyze the data generated during execution, detect patterns, observe the results, and provide information that helps the researcher decide what to test next.

Browser fuzzers need to evolve into infrastructures capable of reporting large amounts of data and allowing granular control over their execution. Both the researcher and the LLM must be able to observe execution state, mutations, and results, adjust sample generation and mutation plans, and produce new changes based on what has been learned. This process of observing the results, modifying the configuration, and running again creates an environment particularly well suited to integrating an LLM-based agent.

In this series of posts, we will show how to turn this approach into a real system. First, we will look at how AI has evolved within vulnerability research and what impact it is having. Then we will discuss V8 bytecode mismatches, inconsistencies between compilations that can lead to vulnerabilities, and the JavaScript engine internals needed to understand them. Finally, we will practically specialize an LLM in this class of vulnerabilities, integrate it as part of an agent, and connect it to our SeekZero infrastructure so that it can work alongside the researcher within the same campaign.

From Code Review to Research Agents

Traditionally, automated research divided the work between tools and researchers. Fuzzers generated and executed test cases, while researchers identified attack surfaces, analyzed previous vulnerabilities, formulated hypotheses, and determined whether a finding actually had security implications. AI is narrowing this separation, allowing models and humans to collaborate more closely within the same research process.

One of the most important changes was the integration of AI into the software development process. Google’s AutoCommenter demonstrated that an LLM-backed system could participate in large-scale industrial code reviews. Its goal was to verify programming best practices and accelerate software development.

Project Naptime, which would later be replaced by Big Sleep, focused specifically on vulnerability discovery. Earlier developments often treated the LLM as a simple function that went from source code to generating a response: here is a program, generate an input that causes a failure. In contrast, Naptime modeled the LLM as a researcher inside a testing environment with access to tools. It could explore the code, execute Python, interact with a debugger, generate test cases, and observe their behavior. This was an important change because the vulnerability discovery process normally consists of locating an area, generating tests for it (automation or code reading), and checking what happens.

Big Sleep demonstrated that this new approach could work in the real world, finding vulnerabilities in SQLite, which showed that a model connected to tools and guided by researchers could contribute something different from the fuzzing techniques used up to that point.

At the same time, models trained specifically for cybersecurity tasks began to appear. Sec-Gemini v1 focused its knowledge on defensive tasks such as threat analysis and assessing the impact of flaws.

Later, HonestCyberEval tested models such as GPT-4o, o1, Claude 3.7 Sonnet, and Gemini 1.5 Pro on a modified version of Nginx containing 14 manually introduced vulnerabilities. The test consisted only of detecting suspicious code and generating test cases capable of reaching the vulnerability. These models solved 13 of the 14 tests.

Anticipating a potential increase in vulnerability reports, Google DeepMind developed CodeMender, an AI agent capable of analyzing flaws, locating their root cause, proposing patches, and validating that those changes do not break existing functionality. To do this, it combines Gemini models with tools such as debuggers, static analysis, fuzzing, differential testing, and SMT solvers. Its goal is to integrate into the software development lifecycle and reduce the burden that vulnerability remediation places on developers.

In early 2026, published studies began to show models with much more advanced capabilities. Anthropic reported that Claude Opus 4.6 had found hundreds of previously unknown vulnerabilities across well-tested open-source software, including major projects such as Mozilla Firefox.

Mozilla stated that it had used Anthropic’s Mythos model to find and fix 271 vulnerabilities in a single browser release.

The next leap came with Claude Mythos Preview and Project Glasswing. These systems were capable of autonomously discovering vulnerabilities and developing complete exploits in projects such as operating systems, browsers, and even closed-source software.

In April 2026, Google updated its Chrome and Android VRP rules, arguing that AI and increased automation had made tasks such as explaining root causes, suggesting fixes, and discovering variants of known bugs easier. Google began placing greater value on external reports that were difficult to automate, such as high-impact vulnerabilities and memory protection bypasses.

One Year of Chrome Vulnerabilities: What the Data Reveals

We collected public information about CVEs and fixes in both Chrome and V8. Our goal is not to attribute these changes to a specific cause, but to examine whether relevant variations appear over the last year in the volume and distribution of public activity related to flaws.

We use two different types of data: CVEs reported in Google Chrome and commits that fix some type of flaw in V8.

For the CVE data, our script reads the posts from Chrome Stable Channel Update for Desktop and extracts the CVEs included in each release. We classify each CVE by the affected component indicated and group less common categories under `Others` to keep the graph readable.

For V8, we generate the data from diffs. Between each pair of consecutive stable revisions, we perform a diff and select the commits that appear to be related to bug fixes, regressions, or security issues.

The selection is heuristic and uses classifications such as “Bug”, “Fixed”, or “Fixes”, Chromium or V8 issue identifiers, regression files, and other keywords such as “crash”, “regression”, “fuzz”, “out-of-bounds”, and “use-after-free”.

The selected commits are not treated as confirmed vulnerabilities. What we are looking for is significant changes in the number of fixes over time that may reflect variations in V8’s development flow.

In the graphs, we can observe visible changes starting in March 2026. In the Chrome reports, there are releases with a number of CVEs higher than what was observed during several of the previous months. In parallel, the classification of V8 diffs records 465 candidate commits in March, 562 in April, and 488 in May.

Both datasets show an increase in activity during a similar period, although they measure different things. The Chrome data shows the CVEs published in each release, while the V8 data shows an estimate of the commits related to fixes between stable revisions.

This period coincides with the changes introduced in Chrome VRP and with Google’s statements about increased internal use of AI and automation. The public data does not allow us to claim that there is a direct relationship, but the increase in activity appears during the same period in which Google describes these changes to its internal processes.

The Limits of Traditional Browser Fuzzing

We consider fuzzing to remain one of the most effective vulnerability discovery techniques. Fuzzers are still indispensable because they perform testing at runtime, which is particularly relevant because a JavaScript engine consists of multiple interconnected components such as bytecode generation, code optimization, deoptimization, garbage collection, and many other components.

Each subsystem in a browser has its own internal state and assumptions, but none of them operates in isolation. In addition, the JavaScript engine is part of a much larger browser: it is connected to the DOM, Web APIs, the rendering process, sandboxing mechanisms, and other security layers.

Traditionally, code coverage-guided fuzzing prioritizes test cases that execute new paths inside the JavaScript engine and reuses them as part of the corpus. However, many bugs in JavaScript engines do not appear simply by reaching new code, but by reaching a part of the code under a very specific condition and sequence, such as calling the garbage collector after the deoptimization of a function that is then optimized again.

In the era of LLMs, fuzzers need to evolve into interactive frameworks where researchers and models can work together continuously. We want to direct fuzzing toward precise targets selected by the researcher, refined with the help of the LLM, and executed within an infrastructure that allows continuous monitoring and adaptation.

The goal is to turn fuzzing into a directed process, where each iteration brings the campaign closer to the hypothesis being tested. This allows the fuzzer to concentrate its effort on a specific area of the engine instead of dedicating resources to generic mutations or tasks with a low probability of providing value.

Why LLMs Change the Equation

LLMs introduce an improvement in vulnerability research because they allow part of the researcher’s reasoning to be applied to a much larger amount of information.

A researcher can analyze code, remember patterns from previous bugs, and formulate hypotheses, but is limited by time and by the amount of information that can be processed. An LLM can work simultaneously with previous vulnerabilities, their patches, JavaScript samples, and the results of a campaign, relating that information to suggest new lines of research continuously over time.

This fits well with the typical process a researcher follows: gather information, formulate a hypothesis, test it, and adjust the direction based on the results.

To take advantage of this, the model must be integrated directly into the research infrastructure and have access to the running campaign: corpus, configurations, and monitoring. The researcher maintains the objective and direction, while the model analyzes the information and proposes or performs new tests.

Our Goal: A Specialized LLM Agent for V8 Bytecode Mismatch Research

The practical case for this series will be the research of V8 Bytecode Mismatches. Our goal is to build a specialized model capable of joining a real campaign, observing its evolution, analyzing large volumes of information, and proposing hypotheses or experiments related to this class of vulnerabilities.

The model will work directly inside SeekZero. It will have access to the corpus, configurations, Timelines, Playground, Mutation Plans, Code Targeting, and campaign results, using that information to look for relationships that are difficult to detect manually.

The researcher, meanwhile, will maintain the direction, validate the conclusions, and decide which lines of research should be pursued.

Throughout the next posts, we will build each of these components. We will start with the base model and the information it needs about V8 and Bytecode Mismatches. Then we will build the agent, give it access to tools and persistent context, and finally incorporate it into a campaign shared with a researcher.

The next step will be to design the brain of the system. We will analyze what the LLM needs to know, what capabilities it should have, and how to connect it to the infrastructure for the first time.

References

Keep reading

More in this series

AI Browser Vulnerability Research, Part 2: teaching an LLM to find browser bugs with SeekZero.

Related research

V8 Bugs in the Agentic Era: what V8 CVEs from 2009 to 2026 show.
How ASTs Change the Way You Think About JavaScript: ASTs for vulnerability research and programmable fuzzing.

Learn more about SeekZero, our browser vulnerability research framework, or browse all posts on the Tashita research blog.

Research