Agentic Fuzzing: Opportunities and Challenges Junyoung Park
Insu Yun
[email protected] KAIST Daejeon, Republic of Korea
[email protected] KAIST Daejeon, Republic of Korea
arXiv:2605.10074v1 [cs.CR] 11 May 2026
Abstract Fuzzers and static analyzers find many bugs but struggle with logic bugs in mature codebases. Triggering such a bug often requires multi-step reasoning that produces no distinctive execution feedback, and variants can appear across implementations too different for a single pattern to match. Recent LLM-assisted approaches help, but they use LLMs as auxiliaries rather than as the reasoning engine. We propose agentic fuzzing, a bug-finding approach seeded by historical bugs in which deep agents perform the reasoning directly. Given a reference bug, the agent analyzes its root cause, hypothesizes new scenarios elsewhere in the codebase that may share that cause, and verifies each hypothesis by generating and running proof-of-concept code. This lets the agent find variants that differ completely in trigger path or code structure from the reference. We identify three practical challenges in implementing agentic fuzzing: harness engineering, redundant investigations across seeds with similar root causes, and scheduling seeds in a large corpus. We address these in AFuzz through a four-stage agent pipeline, scenario coverage that deduplicates previously explored scenarios, and a DPP-MAP scheduler that orders seeds by diversity. We ran AFuzz on the V8 JavaScript engine for about one month, finding 40 bugs (including three duplicates), receiving a total $35,000 bounty, and being assigned two CVEs. AFuzz also found 19 bugs (including one duplicate) in SpiderMonkey and JavaScriptCore using the seeds from V8. However, agentic fuzzing is in its early stages with several remaining open problems we discuss in the paper. Still, we think it points to a promising direction for finding logic bugs.
1
Introduction
As software systems grow in size and complexity, automated bug detection techniques are commonly used to maintain software quality and security. Among them, fuzzing [42, 45, 65, 80] and static analysis [37, 39, 55–57, 88, 90, 92] have been widely adopted for their ability to discover bugs at scale. Fuzzers discover bugs by generating a large number of diverse inputs and observing execution feedback such as code coverage or crashes. Static analysis matches predefined patterns or traces data flows across the program without executing it. These techniques have discovered tens of thousands of bugs in projects like Chromium [42] and are widely deployed across open-source projects [39]. However, these techniques struggle to find logic bugs in mature codebases. A blog post by the V8 team [46] revealed that V8 JavaScript engine vulnerabilities are rarely memory corruption bugs, but instead logic bugs that have the potential to turn into ones when exploited. Because logic bugs do not necessarily exhibit observable signals such as crashes, fuzzers are likely to miss them since they rely on such signals to guide their search. Static analyzers also cannot reliably find them because finding such bugs usually requires reasoning about complex conditions that may not be easily
captured by general patterns. For example, detecting an integer overflow bug may require static analyzers to understand how to achieve sufficiently large integer values through multiple stages of execution, which is difficult to express as a simple general pattern. Historical bugs can provide useful guidance for finding logic bugs, as they demonstrate root causes and trigger conditions that can be used to hypothesize new vulnerability scenarios. However, existing tools lack the reasoning capability to use this guidance effectively. Fuzzers can use Proof-of-Concept (PoC) code as a seed to generate or mutate inputs, exploring around the original trigger path. However, because they do not understand the meaning of the seed, they can only explore around the original trigger path, missing similar bugs with different trigger paths (e.g., JavaScript vs. WebAssembly). Static analyzers can match bug patterns derived from historical bugs. However, a pattern broad enough to cover different code structures (e.g., different components) loses the precision needed to avoid false positives, while a more precise one does not carry over to another implementation of the same logical flaw. Recent works use LLMs to assist fuzzing [28, 33, 34, 36, 66, 68, 89, 94, 95, 99] and static analysis [62, 63]. They use LLMs to generate test inputs, infer protocol grammars, or label code property graph nodes. However, in each case, LLMs are used as auxiliaries, while coverage feedback or pattern matching still steers the search. Because the deep reasoning LLMs are capable of is mostly not used to drive the search, the fundamental limitations of existing approaches persist. Logic bugs that require reasoning about complex conditions across multiple stages of execution can avoid detection, and similar bugs that differ in trigger paths or code structures are unmatched. We propose agentic fuzzing, a new approach that uses deep agents instead as the primary reasoning engine for finding bugs, seeded by historical bugs. Recent deep agents [17, 40, 59, 69] are capable of complex, multi-step reasoning and code manipulation, matching what a human auditor is capable of. Therefore, an agentic fuzzer mimics how a human auditor finds bugs: it takes a reference bug as a seed, analyzes its root cause, hypothesizes new vulnerability scenarios that share the same root cause, and verifies each hypothesis through code reasoning and PoC generation. This lets agentic fuzzers find similar bugs even when they completely differ in trigger paths and code structures, because the agent can understand the root cause at a high level and then reason about how it may occur across the codebase. In practice, implementing an agentic fuzzer raises three problems. First, there is no obvious way to define the agent’s tasks—a problem known as harness engineering [77]. It requires domain expertise and iterative experimentation to find the right design. Second, when an agentic fuzzer processes multiple seeds, it often performs redundant investigations because each seed is analyzed independently and semantically similar seeds lead to overlapping hypotheses. Third, given a large seed corpus, an agentic fuzzer needs to decide which
Junyoung Park and Insu Yun
seeds to process and in what order to maximize bug discovery. Ideally, an agentic fuzzer would prioritize the most promising seeds, but estimating each seed’s potential is difficult. We implemented a prototype AFuzz, which addresses each of these problems as follows. First, AFuzz decomposes the task into a four-stage pipeline of specialized agents (Analyzer, Investigator, Scenario Analyzer, and Validator), each focused on a single objective. This pipeline enables deep analysis of each seed and yields the highest per-seed bug discovery rate in our evaluation. Second, AFuzz tracks scenario coverage, a record of all previously explored location-hypothesis pairs, to skip redundant investigations. Third, AFuzz uses a strategy to disperse seed selection across diverse root causes, using a DPP-MAP [29, 49, 67] algorithm. This strategy allows AFuzz to cover a broad range of root causes early on. We evaluated AFuzz on the V8 JavaScript engine [78] for about one month, processing about 750 of the 3,146 seeds collected from the Chromium issue tracker [41]. As a result, AFuzz discovered 40 bugs (including three duplicates), of which four vulnerabilities received a total bounty of $35,000 and were assigned two CVEs (CVE-2026-2649 and CVE-2026-7902). The bugs are not limited to a specific component but span the parser, interpreter, and multiple compilers. As we detail in §5.3, several of these bugs are complex logic bugs that are hard to find with conventional fuzzing or static analysis. Agentic fuzzing is still in its early stages, with several open problems. These include the high operational cost (we evaluated only about 23.8% of our seed corpus within our budget), the assumption that reference bugs are available (which does not hold for closedsource software), and the fragility of design choices across model generations. We discuss these in §6. Our contributions are as follows. • We propose agentic fuzzing, a new bug-finding approach that uses deep agents as the primary reasoning engine and takes reference bugs as seeds. • We identify three practical challenges in agentic fuzzing: harness engineering, redundant investigations across seeds, and seed scheduling over a large seed corpus. • We design and implement a prototype AFuzz with a four-stage agent pipeline, scenario coverage, and DPP-MAP seed scheduling. • We evaluated AFuzz primarily on V8, discovering 40 bugs (including three duplicates), receiving a $35,000 bounty and two CVEs. Our case studies show that AFuzz can find bugs that conventional fuzzing and static analysis tools rarely find. • We discuss open problems for agentic fuzzing, including cost effectiveness, the need for reference bugs, and design uncertainty.
2
1 2
// src/compiler/turboshaft/operations.h const uint16_t input_count; // input_count is defined as uint16_t
3 4 5 6 7 8
truncated
explicit Operation(Opcode opcode, size_t input_count) : opcode(opcode), input_count(input_count) { // accepts as size_t DCHECK_LE(input_count, // DCHECK only fires in debug builds std::numeric_limits<decltype(this->input_count)>::max()); }
(a) Vulnerable code in V8’s Turboshaft IR. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
(block $outer (result i32) (local.get $cond) (if (then (i32.const 1) (local.get $idx) ;; 33,000 targets, all branch to outer (br_table $outer $outer $outer $outer ... (33,000x))) (else (i32.const 2) (local.get $idx) ;; 33,000 targets, all branch to outer (br_table $outer $outer $outer $outer ... (33,000x))) ) (i32.const 0) ;; fallthrough )
(b) Simplified WebAssembly structure that triggers the vulnerability.
Figure 1: Motivating example: an integer truncation vulnerability (CVE-2026-2649) in V8’s Turboshaft compiler discovered by AFuzz. The red arrow in (a) shows size_t→uint16_t truncation.
2.1
Motivating Example
Figure 1a shows a code snippet of an integer truncation vulnerability in V8’s Turboshaft compiler that AFuzz discovered during evaluation. The Operation base class stores the operand count of each IR node in a uint16_t field input_count (line 2). However, the constructor accepts input_count as a size_t (line 5), implicitly truncating it to 16 bits during initialization. A DCHECK assertion guards this truncation (line 6), but it is stripped in release builds, leaving the truncation unchecked. An attacker can exploit this truncation to cause out-of-bounds access when subsequent compiler phases use the truncated input_count. This leads to memory corruption and potential arbitrary code execution. To trigger the vulnerability, we use WebAssembly’s br_table instruction (i.e., switch-case), which can carry up to 65,520 entries (kV8MaxWasmFunctionBrTableSize). When Turboshaft compiles a br_table, each entry adds one predecessor to the destination block. When multiple branches merge, Turboshaft creates a PhiOp whose operand count equals the total number of predecessors. We place two br_table instructions in opposite arms of an if-else structure as shown in Figure 1b, each with 33,000 entries targeting the same merge point. This creates a PhiOp with 66,000 predecessors, exceeding the uint16_t limit and triggering the truncation.
Motivation 2.2
Using a motivating example, we demonstrate the challenges of finding logic bugs and how existing automated approaches struggle to find them. Then, we show how agentic fuzzing addresses these challenges using deep LLM agents and reference bugs. Finally, we discuss the challenges in scaling this approach to large codebases with many reference bugs, which motivates our design of AFuzz.
Limitations & Key Insights
In this section, we discuss the problem of finding logic bugs and the insights that motivate our design of AFuzz. 2.2.1 Large and complex codebases. It is challenging to identify logic bugs in large and complex codebases. For example, V8 [78], the JavaScript engine used in Google Chrome, adopts a multi-phase
Agentic Fuzzing: Opportunities and Challenges 1 2 3 4
// src/maglev/maglev-ir.h // Bitfield: [opcode:16][input_count:16][properties:16][extras:16] using OpcodeField = base::BitField64<Opcode, 0, 16>; using InputCountField = OpcodeField::Next<size_t, 16>; // 16-bit
5 6 7 8 9 10 11 12 13 14 15
// src/maglev/maglev-ir.h (NodeBase::Allocate) uint64_t bitfield = OpcodeField::encode(opcode_of<Derived>) | OpPropertiesField::encode(Derived::kProperties) | InputCountField::encode(input_count); // encodes to bitfield truncated
// src/base/bit-field.h static constexpr U encode(T value) { DCHECK(is_valid(value)); // only in debug builds return static_cast<U>(value) << kShift; // truncates to 16-bit } data flow
16 17 18 19 20 21
// src/maglev/maglev-graph-builder.cc int input_count = parameter_count_without_receiver() + args.register_count() + GeneratorStore::kFixedInputCount; // input count calculation AddNewNode<GeneratorStore>(input_count, ...); // passed as int
(a) Vulnerable code in V8’s Maglev compiler. 1 2 3 4 5 6
const kNumRegs = 65534; let body = []; for (let i = 0; i < kNumRegs; ++i) { body.push(` let r${i} = ${i};`); } let f = eval(`(function*() {\n${body.join(’\n’)}})`);
7 8 9 10 11
%PrepareFunctionForOptimization(f); f(); %OptimizeMaglevOnNextCall(f); f();
(b) JavaScript code that triggers the vulnerability [43].
Figure 2: Reference vulnerability (CVE-2025-10892) in V8’s Maglev compiler [43]. Blue dashed arrows and the red arrow in (a) show the data flow and integer truncation, respectively.
execution pipeline consisting of parsing, an interpreter (Ignition), a baseline compiler (Sparkplug), and an optimizing compiler (TurboFan). V8 later added a mid-tier compiler, Maglev, in 2023 [79], further increasing its complexity. Each component is designed with distinct performance goals, making JavaScript code transition dynamically across multiple execution tiers at runtime. This complexity makes it difficult to reason about program behavior and detect subtle logic bugs such as the one in our motivating example. Insight 1: Historical bugs as hints. Although it is difficult to discover the motivating example from scratch, historical bugs in V8 can provide useful guidance. Figure 2a shows CVE-2025-10892 in V8’s Maglev compiler [43]. Notably, this bug shares a common pattern with the motivating example: a 16-bit representation of input counts, truncation from wider integer types, and language features that push the count beyond its limit, despite differences in backend and input path. We now describe this bug in detail. In Maglev, the NodeBase base class packs each IR node’s metadata into a 64-bit bitfield, storing the input count in a 16-bit field InputCountField (line 4). When the Allocate function creates a node, it encodes the input count into this bitfield (line 9). However, BitField::encode accepts the input count as a size_t and silently truncates it to 16 bits (line 14). This vulnerability is triggered through the GeneratorStore operation, which saves all local variables when suspending a generator function. The IR graph builder computes the input count by adding the
parameter count, the bytecode register count, and a fixed number of kFixedInputCount=2 (line 20). Then, the IR graph builder passes the input count to node creation as an int (line 21). When we create a generator with a sufficiently large number of local variables (e.g., 65,534), the local variables become bytecode registers, and the input count exceeds the 16-bit limit. 2.2.2 Lack of reasoning. Existing approaches struggle to find bugs even with the help of historical bugs. There are two main approaches that use historical bugs: coverage-guided fuzzing and variant analysis. First, coverage-guided fuzzing uses the Proof-ofConcept (PoC) code as a seed and mutates it to find variants without understanding its meaning. Unfortunately, while the reference bug and the motivating example share a similar root cause (i.e., integer truncation in compiler IR), their PoC codes are completely different. In particular, the former uses JavaScript for creating a generator with a large number of local variables (Figure 2b), while the latter uses WebAssembly to do so (Figure 1b). Therefore, coverage-guided fuzzers are unable to find such variants. Second, variant analysis tools, such as CodeQL [39] or Joern [93], use static analysis to find variants. These tools detect variants by matching predefined code patterns or signatures [39, 57, 88, 93], measuring syntactic or structural similarity [55, 92], or analyzing program slices or traces [37, 56, 90]. However, the reference bug and the motivating example occur in completely different implementations: one uses Maglev and the other uses Turboshaft. As a result, existing variant analysis tools also fail to find such variants. Insight 2: LLM for reasoning. To address these challenges, we use LLMs to reason about the code. LLMs can understand code semantics and perform complex reasoning that is challenging for existing tools. In the motivating example, LLMs can abstract away low-level implementation details such as Maglev’s bitfield encoding and Turboshaft’s constructor, and focus on high-level semantics: they both store wide input counts in a 16-bit field. Then, LLMs can reason about how to make the input count exceed the 16-bit limit, for example by using large br_table instructions to create a PhiOp with too many predecessors. As a result, LLMs can match the vulnerability pattern across Maglev and Turboshaft and figure out how to trigger the vulnerability, discovering the motivating example from the reference bug. 2.2.3 Limited LLM integration. Instead of using LLMs as the primary reasoning engine, existing LLM-based approaches use LLMs as auxiliaries to assist fuzzing or static analysis. This limited integration prevents them from fully leveraging LLMs’ reasoning capabilities to find logic bugs like our motivating example. For example, LLM-assisted fuzzers [89, 99] use LLMs to generate inputs that can maximize code coverage, rather than to reason about why and how a bug occurs and how to find new bugs based on that understanding. Similarly, LLM-assisted static analysis tools [62, 63] use LLMs to label source and sink nodes in taint analysis, generate code queries, or triage false positives. While this reduces human effort, LLMs still serve as auxiliaries rather than to reason about why and where a bug might occur. Insight 3: Deep agents. Instead of limiting LLMs to assisting existing fuzzing, we use deep agents [17, 40, 59, 69] as the primary reasoning engine. Deep agent is an LLM agent paradigm that combines planning, sub-agents, filesystem access, and shell integration
Junyoung Park and Insu Yun
to execute complex tasks over a long horizon. These capabilities are essential for finding bugs like our motivating example. Notably, such a bug cannot be discovered in a single step: the agent must analyze, hypothesize, and verify.
2.3
Technical Challenges
We combine these three insights into agentic fuzzing, a new approach that uses deep agents to detect logic bugs through code reasoning, and implement it in AFuzz. Instead of receiving a test input as a seed, AFuzz takes a reference bug as a seed. Given a seed, AFuzz analyzes its root cause, searches the codebase for other locations where the same root cause could produce a bug, and investigates each candidate to determine whether it contains a new vulnerability. Unlike traditional fuzzing, which generates or mutates inputs, and observes execution signals (e.g., crashes), AFuzz hypothesizes vulnerabilities from reference bugs and verifies them through code reasoning and PoC generation. It mimics how human auditors find bugs by analyzing, hypothesizing, and verifying. However, implementing this approach is more challenging than it may seem, as it introduces the following challenges: Challenge 1: Harnessing. The first challenge is how to define tasks for AFuzz to perform. This is known as harness engineering [77]: defining the interface and behavior of an agent to perform a task. There is no algorithmic solution to this; it requires domain expertise and iterative experimentation. We decomposed the task into a four-stage pipeline: Analyzer, Investigator, Scenario Analyzer, and Validator (§3.2), so that each agent can focus on a single objective. As a result, our pipeline achieved the highest per-seed bug discovery (9 bugs from 100 seeds) in our evaluation (§5.4). However, the optimal harness design for agentic fuzzing remains an open problem: a single-agent baseline that self-decomposes using subagents performed comparably to our pipeline, suggesting that there may be other effective ways to structure the agents and their interactions. Challenge 2: Repeated scenarios. When AFuzz processes multiple seeds, it often produces repeated scenarios. This happens because AFuzz analyzes each seed independently, leading to overlapping hypotheses if the seeds are semantically similar. This is especially common when multiple seeds report different symptoms of the same root cause (e.g., fuzzer crashes that hit the same code path) or are variants of each other. One naïve way to resolve this is to append previous hypotheses to the prompt, but this increases the cost of analysis and fills the context window. To mitigate this, AFuzz tracks scenario coverage, a record of all previously explored location-hypothesis pairs. In detail, before exploring a new hypothesis, AFuzz checks whether a similar hypothesis has already been investigated at that location. If so, AFuzz skips the redundant investigation and instead uses a summary of prior findings to refine or devise new hypotheses. By doing so, AFuzz can avoid redundant investigations and save LLM budget. Challenge 3: Seed scheduling. Given a large corpus of reference bugs, AFuzz must decide which seeds to process and in what order to maximize bug discovery within a limited budget. Naïve strategies, such as processing seeds chronologically or randomly, risk concentrating effort on similar seeds, limiting the diversity of discovered bugs. Notably, many bugs with similar root causes are clustered
together in time [11–15], as they often originate from the same fuzzing campaign or code audit. Ideally, we would prioritize seeds that are most likely to lead to new discoveries, but it is difficult to estimate this a priori. Instead, we use a strategy of dispersing seed selection across different root causes to maximize diversity (§3.3.2). Specifically, we use the DPP-MAP [29, 49, 67] algorithm, which has been used in recommendation systems [29] and machine learning [49] for selecting diverse subsets of items. This approach allows AFuzz to cover a broad range of root causes early on, rather than spending budget on clusters of similar seeds. However, optimal seed scheduling for agentic fuzzing remains an open problem: more sophisticated strategies that estimate the potential of each seed to lead to new discoveries could further improve efficiency.
2.4
Comparison to Google Big Sleep
Recently, many works have applied LLM agents to vulnerability discovery [25, 31, 32, 62, 63]. Among them, Google Big Sleep [25] is the closest work to ours, as it uses LLM agents for discovering bugs from reference bugs. Google Big Sleep demonstrates its effectiveness by discovering vulnerabilities in multiple open-source projects, including SQLite [52] and Chromium [75]. Despite these similarities, we still believe our work remains novel for the following reasons. First, Google Big Sleep does not disclose its architecture or details. In contrast, we disclose AFuzz’s architecture and details and leverage commercial LLMs, making it more accessible to the community. Second, Google Big Sleep already performed vulnerability discovery on the V8 engine as shown in its issue tracker [24]. In particular, the reference bug in our motivating example (CVE-2025-10892, Figure 2a) was itself discovered by Big Sleep [24], indicating that Big Sleep has investigated this family of bugs in Maglev. However, the Turboshaft variant (Figure 1a), which shares the same root-cause pattern but arises in a different compiler backend, remained undiscovered until AFuzz found it. Third, AFuzz assumes a general user setting and introduces several optimizations. Model providers (e.g., Google) face fewer constraints on token usage. In contrast, general users must manage costs, making AFuzz’s approach more meaningful for them.
2.5
Target Selection
We target the V8 JavaScript engine, a widely used open-source project with a well-maintained issue tracker [41]. As discussed above, V8’s multi-tier execution pipeline creates cross-component complexity where logic bugs can hide in interactions between very different implementations. V8 is also one of the most heavily fuzzed codebases in the world: Google’s ClusterFuzz [42] infrastructure continuously fuzzes it, and the V8 team integrates and maintains both conventional (e.g., libFuzzer [65]) and state-of-the-art fuzzers (e.g., Fuzzilli [45] and DUMPLING [80]). Any bug that survives this process is one that conventional fuzzing alone rarely finds. To confirm this, we ran Fuzzilli [45] for 72 hours and it found no bugs while achieving 17.85% code coverage. This makes V8 a good target for showing the effectiveness of agentic fuzzing in finding logic bugs that are missed by conventional fuzzing. Although we use V8 as our primary target, AFuzz can generalize to other targets as we show in other JavaScript engines (§5.7) and applications (§5.8).
Agentic Fuzzing: Opportunities and Challenges
Seed Corpus Bug #1 Integer Truncation in Maglev ... Bug #2 Type Confusion in Turboshaft ...
Scenario Coverage
Seed Scheduler Pre Analysis
Select Next Seed
Seed analysis before embedding
Diversity-driven DPP-MAP
Location
ast.cc: 889
Embedding
Confirmed
Hypothesis
operations.h: 16-bit trunc 1026 in ...
... Bug #N Sandbox Escape: WebAssembly ...
Vulnerability Reports
Seed Queue
Duplicate
Element type transition ...
Out of Scope False Positive
Coverage Agent
Map seed to embedding space
Checks Duplicate Location & Hypothesis
Rejected
LLM Agent Pipeline 1
2
3
Analyzer
Investigator
Root Cause Extraction of Seeds
Investigate & Hypothesize Scenarios
Coverage Check
4
Scenario Analyzer
Validator
Verify Scenarios / Generate PoC Code
Validate Results & Write Report
Figure 3: Overview of AFuzz, an Agentic Fuzzer
3 Design 3.1 Overview Figure 3 shows the overall architecture of AFuzz. AFuzz consists of three main components: 1 the seed scheduler, 2 the LLM agent pipeline, and 3 the scenario coverage tracker. Given a corpus of reference bugs as seeds, AFuzz works as follows. Initially, the seed scheduler (§3.3) schedules the seeds by iteratively selecting a seed that maximizes the diversity of explored bugs. Each seed is then processed by the four-stage LLM agent pipeline (§3.2), which searches for vulnerabilities in the target codebase that share similar root causes with the reference bug. Throughout this process, the scenario coverage tracker records which (location, hypothesis) pairs have been explored, allowing the pipeline to skip redundant investigations across different seeds.
3.2
LLM Agent Pipeline
The LLM agent pipeline consists of four specialized agents that execute sequentially: 1 Analyzer, 2 Investigator, 3 Scenario Analyzer, and 4 Validator. Each agent feeds its results to the next stage, progressively deepening the investigation from understanding the reference bug to validating new vulnerabilities. The agents operate on the target codebase, reading source files, hypothesizing scenarios, and executing test code to validate those scenarios. We describe each stage in detail below. We also explain an example of how the pipeline discovers a bug in Appendix C. Stage 1: Analyzer. Analyzer takes a reference bug as input and produces a comprehensive analysis report. Given a reference bug as an issue tracker URL or a commit hash, Analyzer fetches related artifacts such as the bug report, patches, code reviews, and PoC code. Then, it examines the relevant source code in the target codebase to understand the vulnerability. As a result, Analyzer produces a report containing comprehensive information about
the bug, including the root cause, bug mechanism, impact, fix description, affected files and functions, vulnerable code snippets, and patch code. One notable output is the bug mechanism, which describes the step-by-step process of how the vulnerability works. This mechanism guides the agents in later stages to search for similar instances of the bug. Stage 2: Investigator. Investigator takes the analysis report from Analyzer and searches the target codebase for locations where the same or similar assumption violations might exist. Guided by the bug mechanism, Investigator reads source files, traces code paths, and identifies locations that share the same underlying pattern as the reference bug. Specifically, it looks for direct pattern matches, subclasses or implementations of the same vulnerable interfaces, related subsystems with similar logic, and cross-component interaction boundaries. When Investigator finds a suspicious location, it formulates a vulnerability hypothesis describing the broken assumption or missing validation and submits it as a scenario for the next stage. Each scenario includes the affected source locations, a potential trigger path from JavaScript to the vulnerable code, and advisory notes that help Scenario Analyzer navigate defensive checks or target specific optimization states. Investigator does not stop at the first scenario; it keeps exploring the codebase for multiple independent scenarios before completing its investigation. Stage 3: Scenario Analyzer. Scenario Analyzer receives a scenario from Investigator and verifies whether the hypothesis in the scenario is valid by producing a Proof-of-Concept (PoC) that demonstrates the vulnerability. It first reads the scenario’s code locations in the target codebase, traces the execution path from JavaScript to the suspected vulnerable code, and determines what conditions are needed to reach it. Using the examined trigger path and advisory notes from Investigator as a starting point, Scenario Analyzer writes an initial batch of test code. It then executes the test code on the target engine, checking if the execution produces observable evidence of a vulnerability such as crashes, debug assertion failures,
Junyoung Park and Insu Yun
Scenario
Scenario Coverage
Title Turbolev exception handler Phi uint16_t overflow Location turbolev-graph-builder.cc:876, operations.h:1021, ... Hypothesis When Turbolev converts a Maglev exception handler block ... Turboshaft Operation class stores input_count as ... Potential Trigger ...
Location
Hypothesis
operations.h: 1021
Turboshaft Operation base class stores input_count as ...
turboshaft-graphinterface.cc:6508
Turboshaft Operation base class stores input_count as ...
...
...
Advice Function needs many throwing bytecodes ...
Does not overlap Stage 1. Spatial Overlap Checks Duplicate Locations Same file, ±20 lines
Stage 2. Hypothesis Overlap Overlaps
Check Duplicate Hypotheses
Coverage Agent operations.h:1021 overlaps
Checks Duplicate Location & Hypothesis
Accept Send to Scenario Analyzer Save to Scenario Coverage Does not overlap Overlaps
Require: Seed corpus C, embedding model 𝜙 // Pre-analysis 1: for each seed 𝑠 ∈ C do 2: 𝑡𝑠 ← PreAnalyze(𝑠) ⊲ Pre-analyze seed (Analyzer) 3: v𝑠 ← 𝜙 (𝑡𝑠 )/∥𝜙 (𝑡𝑠 )∥ ⊲ Normalized embedding // Iterative scheduling 4: P ← ∅ ⊲ Already-processed seeds 5: while C \ P ≠ ∅ do 6: 𝑠 ∗ ← FastGreedyDPP({v𝑠 }𝑠 ∈ C\P , {v𝑠 }𝑠 ∈ P ) ⊲ [29] 7: Dispatch 𝑠 ∗ to the agent pipeline 8: P ← P ∪ {𝑠 ∗ }
Reject Return Tool Output with Overlapping Hypotheses
REDUNDANT: Both hypotheses identify the same buggy code: the uint16_t input_count field ...
Figure 4: Scenario coverage to avoid redundant investigations. The example scenario (§2.1) follows the blue arrow (Stage 1 → Stage 2 → Reject), rejected due to spatial and hypothesis overlap with a previously investigated scenario.
or unexpected values that violate the JavaScript specification. If the initial attempt does not produce observable evidence, Scenario Analyzer iteratively refines its approach—trying different JavaScript constructs, optimization states (interpreted, baseline-compiled, or optimized code), object shapes, and edge cases. Finally, Scenario Analyzer examines the execution results and reports either success, with the final PoC code and execution results, or failure, with a description of the approaches tried and why they did not work. Scenarios with a successful PoC are forwarded to Validator for final verification. Stage 4: Validator. Validator independently verifies each scenario and produces a vulnerability report for confirmed vulnerabilities. For each scenario with a successful PoC, Validator reexecutes the PoC, checks the validity of the evidence, and determines whether to accept or reject the scenario. It also checks whether the evidence conforms to the threat model (see §4). For example, it warns if the execution of the PoC uses any securitydisabling flags (e.g., –no-wasm-bounds-checks) or debug-only native functions (e.g., %AbortJS). For confirmed vulnerabilities, Validator produces a vulnerability report containing summary, technical details, trigger conditions, reproduction steps with outputs from both release and debug builds, and a suggested patch. Humans can then independently validate the report and decide whether it is worth reporting to the vendor.
3.3
Algorithm 1 Seed scheduling via Fast Greedy DPP-MAP [29].
Exploration Strategy
As discussed in Challenges 2 and 3 of §2.3, scaling agentic fuzzing to a large number of seeds (i.e., reference bugs) raises two challenges: avoiding investigation of redundant scenarios and scheduling seeds. We describe our approaches to each below. 3.3.1 Scenario coverage. Scenario coverage tracks all previously explored scenarios (i.e., location-hypothesis pairs) across the entire fuzzing campaign, preventing redundant investigations across
different seeds. Figure 4 depicts how it works. Each time Investigator submits a new scenario, the coverage tracker checks whether a similar scenario has already been explored at overlapping code locations before dispatching it to Scenario Analyzer. The check proceeds in two stages. First, it queries the coverage database for existing entries matching the source file locations of the scenario. Agents often investigate the same code region with slightly different line numbers, especially when a statement spans multiple lines. To account for this, the check considers two scenarios to be spatially overlapping if they target the same source file and their line numbers fall within a tolerance window (±20 lines). If no overlapping entry exists, the scenario is approved immediately. If overlapping entries are found, an LLM agent using a lightweight model (e.g., Haiku) compares the proposed hypothesis against existing hypotheses to determine whether they overlap semantically. Redundant scenarios are rejected; distinct ones are approved. Approved scenarios are recorded in the coverage database so that future submissions can be checked against them. Example. In the example of Figure 4, the proposed scenario tries to achieve integer truncation using the exception handler of a different compiler component, Turbolev. It flows through Stage 1 → Stage 2 → Reject (the blue arrow in the figure), and is rejected as redundant with the existing scenario of our motivating example (§2.1). At Stage 1, the two scenarios are considered spatially overlapping because they both target operations.h 1021. At Stage 2, the proposed scenario is considered semantically redundant with the existing scenario. Although they use different attack vectors, they share the same root cause: both hypothesize that the Turboshaft Operation class stores input_count as uint16_t, which can lead to an integer truncation vulnerability. Since any scenario that exploits this root cause would yield the same bug regardless of the attack vector, the proposed scenario is rejected and discarded. 3.3.2 Seed scheduling. To schedule seeds from a large corpus of reference bugs, AFuzz prioritizes diversity by selecting seeds that cover distinct root causes and bug mechanisms before similar ones. To achieve this, AFuzz uses Determinantal Point Process Maximum a Posteriori inference (DPP-MAP) [29, 49, 67], which was previously applied in recommendation systems [29] and machine learning [49] for selecting diverse subsets of items. The scheduling works in three steps as shown in Algorithm 1. First, Analyzer pre-analyzes all seeds in the corpus to extract their root causes and bug mechanisms. Although pre-analyzing
Agentic Fuzzing: Opportunities and Challenges
all seeds in advance is costly, this is a one-time cost that can be amortized across multiple runs, and the results can be directly reused as Analyzer results during actual runs. Second, the preanalysis results are mapped to normalized vector embeddings using a text embedding model (e.g., OpenAI’s text-embedding-3-large), so that seeds with similar root causes and mechanisms can be mapped close together in the embedding space. Finally, AFuzz uses the Fast Greedy DPP-MAP algorithm of Chen et al. [29] to greedily select the seed most distinct from those already processed in the embedding space. This algorithm selects the next item that maximizes the diversity of the selected subset at each step, measured by the determinant of the kernel matrix of the selected items.
4
Implementation
We implemented AFuzz as a web application with a total of 28.0k lines of code, including 13.0k lines of Python for the backend, 3.4k lines of Python and 720 lines of prompt templates for the agent service, and 10.9k lines of TypeScript for the frontend. The agents are built on the Claude Agent SDK [16], which provides an interface to Claude Code [17]. The backend is responsible for agent task orchestration, database management, and API handling while the frontend provides a user interface for monitoring and interacting with running agents. We designed the backend to spawn agents as individual Docker containers, allowing for scalable and isolated execution. Each agent container has access to its own target source code and prebuilt binaries, enabling it to perform dynamic analysis and PoC execution as needed. Time budget and soft timeout. To prevent agents from running too long and exhausting resources, we implemented a soft timeout mechanism. Specifically, we observed that agents occasionally fall into a compaction death spiral [26, 74]. In this state, agents loop over the same tasks without progress as long conversations lose context during compaction. To mitigate this, AFuzz injects a warning into the agent’s conversation at 50%, 80%, and 90% of its soft time budget, telling the agent how much time remains and prompting it to wrap up. After the soft timeout, additional warnings fire every 5 minutes until the hard timeout kills the process. AFuzz currently sets the soft timeout to 6 hours and the hard timeout to 12 hours, but these values can be adjusted when needed. PoC execution and threat model warning. AFuzz targets bugs reachable by untrusted JavaScript, so all PoC code must trigger the vulnerability without security-disabling flags or debug-only native functions. Agents execute PoC code through a dedicated tool that runs it against prebuilt d8 binaries (the V8 developer shell). We precompiled both release and debug builds for nine architectures: x64, arm64, ia32, arm, loong64, mips64el, ppc64, s390x, and riscv64. The flags –allow-natives-syntax and –expose-gc are always included so that agents can use optimization-triggering natives and explicit garbage collection. We also apply a 300-second timeout to each execution to prevent hanging. While we instruct agents to use PoC code that works without security-disabling flags or debug-only natives, our execution tool also warns about violations programmatically. Our execution tool implements this using a blocklist of flags and an allowlist of native functions. If a violation is found, the tool appends a warning to
the execution result so the agent can self-correct. The flag blocklist includes –expose-memory-corruption-api, –no-sandbox, and any flag whose name contains “experimental,” since experimental features are not shipped in production. The native allowlist conservatively permits only 15 optimization-related functions (e.g., %OptimizeFunctionOnNextCall); all others are rejected. Beyond these validations, the tool inspects execution results for common false positives. A CHECK failure (release-build assertion) means V8 intentionally detected the issue and terminated, which is usually not a bug; the tool warns the agent to look for a DCHECK failure (debugonly, compiled out in release) or a crash instead. For sandbox bugs, the tool checks if the output contains “V8 sandbox violation detected”; we ignore other sandbox-related messages and warn the agent that they indicate the sandbox is working correctly rather than being bypassed (e.g., “Safely terminating process”). Mitigating commit history bias. We observed that agents tend to pipe git log through head to keep context short, which means they only see the most recent commits and miss older ones that may be relevant. To mitigate this, we wrapped git log with a script that randomly shuffles the output entries before returning them. To notify agents of this behavior, the wrapper prepends a note to the output indicating that the commit history is not in chronological order. If agents need to see the commit history in its original order, they can pass a flag (i.e., –no-shuffle). Collecting and processing seeds. We implemented a seed collector that fetches V8 security bugs from the Chromium issue tracker [41]. We collected 3,146 seeds by filtering for vulnerabilities in V8 while excluding duplicate, intended-behavior, infeasible, obsolete, and non-reproducible reports. Each seed is represented by its issue URL, which Analyzer fetches at runtime to retrieve its contents. To aid Analyzer, we also implemented a tool that extracts the contents of a bug report from its URL, including the discussion, patches, and PoC code if available. We needed the tool because the issue tracker dynamically loads its contents, which the built-in WebFetch tool of the Claude Agent SDK [16] cannot fully retrieve. For seed scheduling, we embedded the pre-analysis text of each seed using OpenAI’s text-embedding-3-large model and ran DPP-MAP over these embeddings as described in §3.3.
5
Evaluation
Research questions. In this section, we answer the research questions below. • RQ1: Can AFuzz find new bugs in V8? (§5.3) • RQ2: How do pipeline design choices affect bug-finding effectiveness? (§5.4) • RQ3: Does DPP-MAP seed scheduling improve exploration diversity over simpler strategies? (§5.5) • RQ4: How much do Analyzer stage and the reference bugs contribute to bug discovery? (§5.6) • RQ5: Can seeds from one engine be used to find bugs in other JavaScript engines? (§5.7) We also include our mini-experiment results with open-source models and other software targets in §5.8.
Junyoung Park and Insu Yun
Table 1: New bugs discovered by AFuzz. Ref. ID refers to the seed that led to the discovery of the bug. #
ID
Detail
Ref. ID
Status
1 480788626 Type Confusion in MegaDOM IC 450328966 Fixed 2†∗ 481074858 Integer Truncation in Turboshaft PhiOp input_count via WASM br_table 444048019 Fixed 3 484300742 TOCTOU Race During [REDACTED] 427600180 Duplicate 4† 484789568 Missing Guard in [REDACTED] 458090625 Fixed 5 485281841 Sandbox Escape via [REDACTED] 458679941 Duplicate 6⋄ 496807872 Signed Integer Overflow in [REDACTED] 444048019 Fixed 7 499659070 JIT Miscompilation via [REDACTED] 40088942 Fixed 8‡ 502030575 Incorrect [REDACTED] 40055069 Fixed 9 482083327 Signed Integer Overflow in parseInt via InternalStringToIntDouble 420697404 Reported 10 482199449 DCHECK Failure in Scope::ForceDynamicLookup via PreParser info_id_ Reset in REPL Mode 418478214 Fixed 11 489494031 Use Count Corruption in Maglev Phi Representation Selector via HoleyFloat64 ToBoolean Path 428226995 Duplicate 12 491881374 JIT Miscompilation in Turboshaft Loop Unrolling via Non-Commutative Sub 436305802 Fixed 13 498010834 Incomplete Constant Pool State Cleanup in ARM Assembler via Maglev Codegen Abort 40057489 Fixed 14 498904291 DCHECK Mismatch in DependOnContextCell via Function Context Cells 412756062 Fixed 15 498904295 DCHECK Failure in Label Destructor via Regexp Compilation Error Propagation 452681948 Fixed 16 498904299 Miscompilation in Turboshaft via Div-to-Mul with Denormal Reciprocal 429761781 Fixed 17 499018901 Missing [REDACTED] During Deopt. 424627229 Fixed 18 499150024 OOB Vector Access in DataDrop During Streaming WASM Compilation 40094133 Fixed 19 499155349 Integer Overflow in [REDACTED] 369685641 Fixed 20 499188872 Missing Prototype Chain Dependency for Module Exports via PropertyAccessInfo::ModuleExport 40057622 Fixed 21 499206651 Spec Violation in Parser via Missing Escape Check for ’using’ Contextual Keyword 40091892 Reported 22 499254994 Multiple Disposal of Resources in C-style For Loops with using Declarations 385170388 Fixed 23 499254996 Missing Immutability Check for Exported using/await using Module Variables 385170388 Fixed 24 499323105 Spec Violation in Parser via Missing PrecededBy Member Checks 40092882 Fixed 25 499520013 Missing StackOverflowCheck in JSBuiltinsConstructStubHelper on RISCV/LOONG64/MIPS64 40094550 Fixed 26 499659062 Signed/Unsigned Confusion in Fast API kUint64 Argument Lowering via CheckedSigned64AsWord64 40064983 Fixed 27 499672315 Incorrect Private Name Resolution in Heritage Expression via Skip Bit Loss in FinalizeBlockScope 40093214 Fixed 28 499834467 Incorrect Deoptimization of undefined to NaN via Missing Check in Constant Encoding 394120836 Reported 29 500224598 Incorrect Math.round in Maglev on RISCV64/LOONG64 via Flawed "add 0.5 then floor" Algorithm 40063144 Fixed 30 500507435 Incorrect ToUint8Clamped Codegen in RISCV64 Maglev Backend 380604249 Fixed 31 500507436 Incorrect Codegen in RISCV64 Maglev CompareIntPtrAndBranch Uses Uninitialized Scratch Register 380604249 Reported 32 500536164 Spec Violation in IterableForEach — Missing Prototype Check Bypasses Iterator Protocol 385386138 Fixed 33 502035871 Register Clobber in RISCV UnalignedStoreHelper via Hardcoded t4 Scratch Register 380604249 Reported 34 502083475 Spec Violation in Float16Array Search Methods via Incorrect Range Check 394120836 Fixed 35§ 482083331 Race Condition in WASM Stack Switching via Profiler Signal Handler 424905890 Confirmed 36§ 482088900 Type Confusion in [REDACTED] 420464880 Confirmed 37§ 499027764 Incorrect F16x8 Comparison in TurboFan/Liftoff via Incorrect vpackssdw Usage 369685641 Reported 38§ 499103615 ImmutableArrayBuffer Write Protection Bypass in WASM Turboshaft DataView Setter 384773802 Fixed 39§ 499150035 Register Allocation Mismatch in F16x8ReplaceLane Instruction Selector on x64 40052865 Reported 40§ 499155348 SIGSEGV/DCHECK Failure in SetOrCopyDataProperties via Object.assign on Shared-Space Objects 40062686 Fixed ∗ Assigned CVE-2026-2649. † Each awarded $11,000 bounty. ‡ Awarded $8,000 bounty and CVE-2026-7902. ⋄ Awarded $5,000 bounty. § Requires experimental flag.
5.1
Experimental Setup
Environments. We conducted all our experiments on servers running Ubuntu 24.04.3, each equipped with two Intel Xeon Gold 6248R CPUs (48 cores total) and 256 GB of RAM. As described in §4, agents run in isolated Docker containers limited to 6 hours of soft time and 12 hours of hard time. We limited each agent to 32 GB of RAM to prevent resource exhaustion. For LLM API calls, we used Claude Opus 4.6 via the Claude Agent SDK [16], which provides an interface to Claude Code [17]. We used OpenAI’s text-embedding-3-large model for text embeddings in seed scheduling. We evaluated on the V8 JavaScript engine (§2.5), with additional experiments on SpiderMonkey and JavaScriptCore (§5.7). Seed corpus and pre-analysis. We collected a total of 3,146 seeds from the Chromium issue tracker (see §4). For RQ1 (§5.3), we used the full corpus of 3,146 seeds to maximize the chance of finding new bugs in V8, though we managed to run about 750 of them within our budget. For RQ2–RQ5, we could not afford the pre-analysis cost of seed scheduling, which requires running Analyzer on each seed to extract its root cause and bug mechanism (see §3.3). Therefore, we limited the scope of our evaluation to 669 seeds selected from the main components of V8: parser, interpreter, and compilers.
For RQ2–RQ5, we pre-analyzed 669 seeds using the Claude Opus 4.6 model with high effort, which cost $1,068 in API calls ($1.60 per seed on average) and took 5,526 minutes (8.3 minutes per seed on average). We then embedded the pre-analysis outputs using OpenAI’s text-embedding-3-large model at negligible cost (under $0.0001) and ran DPP-MAP over the resulting embeddings. Note that preanalysis is a one-time cost per seed: once a seed is pre-analyzed and embedded, its embedding can be reused across multiple scheduling rounds without additional API calls.
5.2
Threat to Validity
Budget constraints. Our budget limited the accuracy, breadth, and depth of our evaluation. We had to restrict our evaluation to the 669 seeds and the Claude Opus 4.6 model, and capped most experiments at $1,000 or 100 seeds. Also, because LLM outputs are non-deterministic, a larger number of repetitions would be needed for statistical confidence, but our budget did not allow this. A larger budget would also have allowed us to evaluate on more seeds and compare across different models. Tool and model updates. Agent behavior can change due to updates to the tools and models. We observed that updates to Claude
Agentic Fuzzing: Opportunities and Challenges
Table 2: Pipeline design choice comparison. # is the number of seeds processed. TP and FP are true and false positives. Cost ($) Effort
Pipeline
Time (min)
#
TP
FP
Total
Avg.
Total
Avg.
(a) Fixed budget (∼$1,000) Four-stage High Three-stage One-stage
39 62 82
3 3 8
1 2 0
986.3 994.0 993.7
25.3 16.0 12.1
5,081.3 5,121.9 4,294.5
130.3 82.6 52.4
Medium
Four-stage Three-stage One-stage
53 92 110
2 4 5
2 0 1
995.5 993.6 999.4
18.8 10.8 9.1
4,269.1 4,122.8 3,880.1
80.5 44.8 35.3
Low
Four-stage Three-stage One-stage
127 237 300
4 3 2
0 1 2
996.3 997.5 998.5
7.8 4.2 3.3
4,359.1 4,579.5 3,654.9
34.3 19.3 12.2
(b) Fixed seeds (100 each) Four-stage High Three-stage One-stage
100 100 100
9 3 8
1 2 1
2,845.5 1,583.0 1,188.6
28.5 15.8 11.9
13,483.5 7,597.2 5,070.7
134.8 76.0 50.7
Medium
Four-stage Three-stage One-stage
100 100 100
3 4 4
3 0 1
1,909.6 1,090.5 917.9
19.1 10.9 9.2
8,484.6 4,474.7 3,507.3
84.8 44.7 35.1
Low
Four-stage Three-stage One-stage
100 100 100
4 3 0
0 0 0
766.2 409.0 286.3
7.7 4.1 2.9
3,305.0 1,826.0 1,045.9
33.0 18.3 10.5
High
Code (e.g., the addition of general-purpose subagents [18]) can alter our agents’ behavior. Therefore, for evaluation, we pinned the versions of Claude Agent SDK [16] and Claude Code [17] to v0.1.49 and v2.1.77, respectively, which were the latest versions available at the time. However, our results are still susceptible to silent model changes that may have occurred during our evaluation, as some public reports claim that model behavior changed [60].
5.3
Table 3: Bug reproducibility across pipeline design choices. pass@5 counts how many of the 21 bugs were rediscovered at least once across five runs; Total counts the total rediscoveries across all runs. For per-bug detail, see Table 7 of Appendix.
RQ1. Discovered New Bugs by AFuzz
Over a three-month span from 2026-02 to 2026-04, we ran AFuzz for about one month on about 750 of the 3,146 seeds collected from the Chromium issue tracker [41]. During this period, AFuzz discovered 40 bugs as listed in Table 1, including three duplicates. So far, 28 have been fixed, two confirmed, and the remaining seven non-duplicate bugs are still under review. Four of the bugs received VRP bounties: bug #2 ($11,000), bug #4 ($11,000), bug #8 ($8,000), and bug #6 ($5,000), totaling $35,000. Bug #2 and #8 were each assigned CVE-2026-2649 and CVE-2026-7902 respectively. Although we instructed agents to avoid using experimental flags as explained in §4, they occasionally ignored our instructions during exploration and found six bugs that require an experimental flag to trigger. We still reported these bugs as they were valid and should be fixed before the features are enabled by default. These results show that AFuzz can find new bugs in V8, including security vulnerabilities that were not previously reported. AFuzz reported bugs in various V8 subsystems, including the optimizing compilers (e.g., Maglev and TurboFan), the parser, the interpreter, the WASM pipeline, and architecture-specific backends. The bugs also cover various types of issues, from specification violations to exploitable type confusions. We provide detailed case studies of two interesting bugs in Appendix D.
Medium
Low
Pipeline
pass@5
Total
pass@5
Total
pass@5
Total
Four-stage Three-stage One-stage
15/21 8/21 13/21
32/105 15/105 25/105
9/21 11/21 9/21
19/105 19/105 17/105
4/21 5/21 6/21
12/105 8/105 7/105
5.4
RQ2. Pipeline Design Choices
Experiment setup. Table 2 compares three pipeline designs using Claude Opus 4.6 at three effort levels (high, medium, and low), which control the model’s reasoning depth, with our DPPMAP scheduling. The four-stage pipeline is the full AFuzz pipeline (Analyzer → Investigator → Scenario Analyzer → Validator) as described in §3.2. The three-stage pipeline (Analyzer → Bug Finder → Validator) merges Investigator and Scenario Analyzer into a single Bug Finder agent that both explores the codebase and generates PoCs. The one-stage pipeline runs a single Bug Finder agent that performs analysis, investigation, PoC generation, and validation within one execution. For fair comparison, we included all detailed prompts and instructions of AFuzz for Bug Finder agent in the three- and one-stage designs, except for the explicit stage descriptions. This way, they can have similar information and guidance to the four-stage pipeline. However, because Bug Finder agent does not explicitly formulate scenarios, the scenario coverage (§3.3) is not used in the three- and one-stage designs. We evaluated each design in two ways. First, we ran each design once under two resource settings (Table 2): (a) a fixed API budget of $1,000, and (b) a fixed count of 100 seeds. Second, because LLMbased agents are non-deterministic, we additionally measured the reproducibility of discovered bugs across pipeline designs and effort levels. We took the seeds that produced bug discoveries in the first experiment (18 mapped to Table 1; 3 were independently fixed by V8 developers before we reported them), reran them five times each, and counted how often each bug was rediscovered (Table 3; see Table 7 of Appendix for detail). Results. Our results show that no single pipeline design dominates across both resource settings. The depth of the pipeline trades off against the number of seeds a fixed budget can process. Under a fixed seed count of 100, the four-stage pipeline at high effort found the most bugs (9, vs. 8 for one-stage and 3 for three-stage) and achieved the highest rediscovery rates across five runs (15 of 21 at pass@5, 32 total discoveries out of 105). However, it spent $2,846, roughly 2.4× the one-stage pipeline’s $1,189. Under a fixed budget of $1,000, this cost difference reverses the ranking: the one-stage pipeline at high effort found 8 bugs from 82 seeds while the fourstage pipeline found only 3 from 39 seeds. We observed that the one-stage agent frequently invokes auxiliaries like subagents [18] and todo list management [20], which let a single agent decompose the task and manage its workflow without explicit stage separation. In short, the best pipeline design depends on whether the bottleneck is seeds (prefer four-stage, more bugs per seed) or dollars (prefer one-stage, more bugs per dollar).
Junyoung Park and Insu Yun
Table 4: Evaluation of seed scheduling strategies. # is the number of seeds in each run. Cov. measures the fraction of scenarios that pass the coverage redundancy check. Cost ($) Strategy
#
TP
FP
Cov.
Total
Avg.
Total
Effort
Cov.
Total
Avg.
Total
Avg.
Without analyzer and reference bugs High∗ 2 1 2 76.4% Medium∗ 20 1 2 81.1% Low 61 0 0 73.0%
1,006.1 1,103.7 992.5
503.1 55.2 16.3
4,398.3 4,718.6 4,290.7
2,199.2 235.9 70.3
With analyzer and reference bugs (AFuzz) High 39 3 1 97.7% 986.3 25.3 5,081.3 Medium 53 2 2 99.0% 995.5 18.8 4,269.1 Low 127 4 0 91.7% 996.3 7.8 4,359.1 ∗ Includes one additional iteration that exceeded the $1,000 budget.
130.3 80.5 34.3
99.0% 83.2% 90.2%
995.5 984.2 973.8
18.8 22.4 19.5
4,269.1 4,222.0 4,456.4
80.5 96.0 89.1
(b) Fixed seeds (100 each) DPP-MAP 100 3 Newest 100 2 Random 100 6
3 2 2
94.4% 80.0% 90.7%
1,909.6 2,260.7 1,936.4
19.1 22.6 19.4
8,484.6 10,275.7 9,242.5
84.8 102.8 92.4
RQ3. Seed Scheduling Strategies
Experiment setup. To evaluate the effectiveness of our DPP-MAP seed scheduling strategy (§3.3), we compared it against two other strategies: Newest-first and Random. Newest-first prioritizes seeds based on their creation date, with newer seeds being processed first. Random selects seeds randomly from the corpus without any specific ordering. We ran each strategy under the same two resource settings as in §5.4: (a) a fixed API budget of $1,000, and (b) a fixed count of 100 seeds. All runs used Claude Opus 4.6 with the medium effort level, which is the default. Results. Among the three strategies, DPP-MAP shows the highest scenario approval rates (99.0% (a) for the fixed API budget and 94.4% (b) for the fixed seed count), compared to Newest-first (83.2% (a) /80.0% (b) ) and Random (90.2% (a) /90.7% (b) ). The higher approval rates of DPP-MAP indicate that its selected seeds produce scenarios that overlap less with previously explored ones, confirming that our diversity-based scheduling reduces redundant investigations. This was also reflected in the average cost and time per seed: DPP-MAP is the most efficient with $18.8 (a) /$19.1 (b) and 80.5 (a) /84.8 (b) minutes, while the other two strategies cost more ($22.4 (a) /$22.6 (b) and $19.5 (a) /$19.4 (b) ) and take longer (96.0 (a) /102.8 (b) and 89.1 (a) /92.4 (b) minutes). Unfortunately, even though DPP-MAP showed better efficiency, it did not find more bugs than the other strategies in our experiments. We attribute this to the small absolute bug counts (one to six per strategy), which make the differences inconclusive. Due to the budget limit described in §5.2, we could not run more seeds or repeat runs to achieve statistical confidence.
RQ4. Effect of Reference Bugs
Experiment setup. To measure how much reference bugs contribute to bug discovery, we disabled Analyzer stage and ran the remaining three stages. We instructed Investigator to explore the parser, interpreter, and compiler subsystems of V8 for bugs, following the same scope as our seed corpus. We ran experiments with Claude Opus 4.6 at three effort levels (high, medium, and low) under a fixed API budget of $1,000. At the high and medium efforts, we included one additional iteration that exceeded the budget because excluding it would leave the budget significantly unused. Results. Table 5 shows that Analyzer stage and reference bugs contribute to bug discovery. Removing them resulted in discovering
#
TP
FP
Time (min)
Avg.
2 1 1
5.6
Cost ($)
Time (min)
(a) Fixed budget (∼$1,000) DPP-MAP 53 2 Newest 44 1 Random 50 2
5.5
Table 5: Results without Analyzer stage and reference bugs. # is the number of repeated iterations (without reference bugs) or seeds (AFuzz).
fewer bugs at each effort level: 1, 1, and 0 bugs at high, medium, and low effort, respectively, compared to 3, 2, and 4 bugs in AFuzz. Without reference bugs, Investigator had to survey the codebase for general vulnerability hypotheses on its own each iteration, increasing per-iteration cost by 2.1–19.9×. In AFuzz, Analyzer extracts seed-specific root causes once and passes them to Investigator, which naturally spreads the search across different components and bug mechanisms. Without this, the agent fell back to broader searches that produced more overlapping scenarios, dropping the scenario coverage check pass rate by 17.9–21.3%p (from 91.7–99.0% down to 73.0–81.1%).
5.7
RQ5. Cross-Engine Fuzzing
Experiment setup. To evaluate whether AFuzz can find bugs in other JavaScript engines using the seeds collected from V8, we ran AFuzz on SpiderMonkey and JavaScriptCore. We used the same four-stage pipeline with Claude Opus 4.6 and DPP-MAP scheduling. We ran each engine under a fixed API budget of $1,000 and a fixed count of 100 seeds, following the same setup as in §5.4. However, due to the budget and time constraints, we ran all experiments only at the high effort level to maximize per-seed bug discovery as shown in §5.4. Results. Table 6 shows that reference bugs from one project can be used to find bugs in similar software. With 100 V8 seeds per engine, AFuzz found five bugs (including one duplicate) in SpiderMonkey and 14 in JavaScriptCore. AFuzz extracted root causes from V8 bugs, found relevant code in the other engines, and hypothesized how similar ideas could trigger bugs there. For example, seed 40057622 (CVE-2021-38001) [58] is a V8 bug where the property access cache mistakes which object it should read a property from, during super property access. From this seed, AFuzz found JSC bug #7 (Issue 312681), where JavaScriptCore’s property access cache makes the same mistake in a different caching mechanism, reading a property value from a stale object instead of the intended one.
5.8
Additional Experiments
Open Source Model. We ran mini-experiments with two opensource models, Gemma 4 [44] and GLM-5.1 [98], to test whether they can be used in place of commercial models in AFuzz. As a result, we found that neither is yet competitive. Gemma 4 frequently produced malformed tool calls, causing the agent to fail before
Agentic Fuzzing: Opportunities and Challenges
Table 6: Bugs discovered by AFuzz in SpiderMonkey and JavaScriptCore. Ref. ID refers to the V8 seed that led to the discovery. Detail
Ref. ID
Status
SpiderMonkey 1 2032677 2 2032761 3 2032821 4 2032819 5 2032943
#
ID
Packed Field Narrowing/Widening Bypass in Wasm GC Struct Scalar Replacement Missing canonicalizeValueZero in GenerateImportJitExit Externref Path JSOp::ArgumentsLength returns wrong value for block-hoisted function arguments(){} for (using x of iterable) in Generators — Disposal Skipped on Generator Close LOONG64 JIT [REDACTED]
40090201 40090201 40089200 40092882 380604249
Duplicate Reported Fixed Reported Fixed
JavaScriptCore 1 312632 2 312664 3 312667 4 312669 5 312672 6 312675 7 312681 8 312682 9 312684 10 312685 11 312687 12 312688 13 312689 14 312690
SIGSEGV in FTL [REDACTED] Hole-to-NaN Conversion in DFG Object Allocation Sinking Phase DFG [REDACTED] DFG operationStringProtoFuncReplaceAllGeneric Skips Global Flag Check for RegExp Array ToPrimitive Fast Path Ignores Object.prototype.valueOf Override Incorrect Scope Resolution for Sloppy Function Hoisting from eval() in Default Parameter Expressions Incorrect Property Read in Megamorphic Cache due to ownProperty Flag Confusion LLInt/BBQ JIT Discrepancy in WebAssembly div/rem Constant Folding Unchecked [REDACTED] Set Spread in DFG/FTL Missing Per-Instance Prototype Check Incorrect Math.round Result via floor(x+0.5) JIT Fast Path YARR Omits Named Group from indices.groups via Tracking-Slot Reset on Backtrack BBQ JIT Constant Folding Signed Zero Mishandling in computeFloatingPointMinOrMax Input Position Corruption in Yarr Backreference Backward Matching via Surrogate Pair Rewind
382547699 382547699 442086665 442086665 406871259 40089200 40057622 40055671 40064614 385386138 416128193 40093076 40070548 40053946
Reported Fixed Reported Reported Reported Reported Fixed Fixed Reported Reported Reported Reported Fixed Reported
it could make meaningful progress; it found no bugs across 100 seeds. GLM-5.1 handled tool call formatting correctly but produced weaker hypotheses: it found only one bug after running 27 seeds, consuming approximately 700M tokens. These results suggest that open-source models are not yet suitable for agentic fuzzing at the level AFuzz requires, though we expect their performance to gradually improve in the future. Generalization to Other Software. Although our evaluation mainly targets JavaScript engines, the core techniques of AFuzz are not specific to them. To test this, we ran AFuzz on two additional targets outside our main evaluation. On ANGLE, Google Chrome’s GPU graphics layer, AFuzz found one heap buffer overflow vulnerability [70]. We also found several vulnerabilities by adapting AFuzz to the Windows kernel, a closed-source target. Unfortunately, the Windows kernel lacks public bug details, so we had to manually craft seeds based on CVE entries. These results suggest that AFuzz can generalize beyond JavaScript engines and can even work on closed-source software when suitable seeds are provided. As future work, we plan to evaluate AFuzz on more targets and further explore its generalization capabilities.
6
Open Problems
Despite its effectiveness, agentic fuzzing is still in its early stages. There are many open problems that need to be addressed. Cost effectiveness. Cost effectiveness remains a major challenge for agentic fuzzing. AFuzz is still expensive to run. As a result, we could evaluate only about 23.8% of the collected seeds from the Chromium issue tracker [41] (see §5.3). This limitation also prevents us from evaluating AFuzz on more projects. While we attempted to mitigate this limitation by introducing techniques like scenario coverage (see §3.3.1) and seed scheduling (see §3.3.2), we believe that more research is needed to further improve the cost efficiency of agentic fuzzing while maintaining its effectiveness. No reference bug. AFuzz assumes that reference bugs are available; however, this is not always the case. Reference bugs guide the agent toward specific components and root causes, as shown in §5.6:
without them, the agent falls back to broad, undirected searches that cost more and find fewer bugs. For well-studied open-source targets like V8, years of public bug reports with detailed root causes and PoCs provide a rich seed corpus. However, not all projects provide such references. Closed-source software like Windows only publishes CVE entries with short descriptions (e.g., “Windows kernel buffer overflow”), which lack the detail AFuzz can refer to. Newer or less-documented open-source projects may simply have too few prior reports. In these settings, AFuzz cannot be directly applied. One possible direction is to bootstrap seeds from related projects, as our cross-engine experiments (§5.7) suggest that root causes can transfer across implementations that share architectural similarities. Another direction is to let the agent build its own seed corpus from documentation, changelogs, or code review history, though this remains unexplored. Design uncertainty. Design choices for agentic fuzzing are hard to justify definitively. Our pipeline comparison (§5.4) demonstrates this: the four-stage pipeline achieved the highest per-seed bug discovery (9 bugs from 100 seeds at high effort), but the one-stage pipeline is competitive (8 bugs with the same setup) because the agent self-organizes using subagents and task management on its own. This aligns with recent findings that single-agent systems can outperform multi-agent designs under equal token budgets [76]. We cannot confidently say which design is better—it depends on budget, model, and target. More broadly, AFuzz’s design is based on empirical observations about current LLMs, not on well-understood principles. This makes the design inherently heuristic and fragile across model generations. For example, few-shot prompting [27] improved performance in earlier non-reasoning models, but the effect is reduced in reasoning models [47]. A design choice that works today may not survive the next model update.
7
Discussion
Bug Explainability. Compared to traditional fuzzing or static analysis tools, AFuzz provides an advantage in explaining bugs.
Junyoung Park and Insu Yun
Traditional tools typically report a crash or a violation of an assertion, which may not provide much insight into the root cause of the bug. In contrast, AFuzz generates detailed reports that include the steps taken to discover the bug, the reasoning behind each step, and the potential impact of the bug. This level of detail can help developers understand the underlying issue more quickly and accurately, leading to faster and more effective fixes. For example, when we reported a duplicate bug (Issue 489494031), which was found by the fuzzers of the V8 team a day before our report, a V8 developer commented “Our fuzzers didn’t provide an explanation of what’s happening, so thanks for that!”. This feedback suggests that AFuzz’s explanations can be valuable even for bugs that are already known, as they can help developers save time and effort in diagnosing and fixing the issue. Implications. Our results imply that current commercial LLMs, with proper harnessing, can discover vulnerabilities that skilled human auditors can find. This raises a concern: threat actors can use the same techniques to find vulnerabilities that were previously out of reach and exploit them for real attacks. At the same time, the defenders’ side is already under pressure. Bug report volume is growing, and AI-generated slop reports (e.g., [23]) add noise that developers must still triage. Developers increasingly turn to AI-based techniques such as Automatic Program Repair (APR) to keep up, but APR still requires human review to ensure correctness. The result is an asymmetry: attackers can scale discovery through automation, while defenders remain bottlenecked by human verification. This imbalance disproportionately affects low-resource entities that lack the budget to absorb the cost of either AI-assisted defense or the increased volume of vulnerabilities.
8
Related Work
LLM-based vulnerability discovery. Researchers have recently been using LLM agents to discover vulnerabilities. Big Sleep [25] discovered several impactful vulnerabilities in multiple open-source projects, including SQLite [52] and Chromium [75], using LLM agents in variant analysis. ÆSIR [38] also found 21 CVEs in AI infrastructure by performing variant analysis of new CVEs. XBOW [31], PentestGPT [32], and other works [30, 50, 73] automate penetration testing with LLM agents by giving them tools to dynamically test the target system, while IRIS [63] and LLMxCPG [62] combine LLMs with static analysis for vulnerability detection. Similar to Big Sleep, AFuzz discovers new bugs from reference bugs using LLM agents. However, we disclose AFuzz’s architecture and details while Big Sleep does not, and we also introduce several optimizations that can make AFuzz more cost-effective for general users. Moreover, AFuzz found new bugs in the same V8 environment where Big Sleep had already found vulnerabilities. LLM-assisted fuzzing. A line of work has focused on using LLMs to assist fuzzing. Several works [33, 34, 89, 94, 96] use LLMs to generate or mutate test inputs for language processors or deep learning libraries. ELFuzz [28] and G2Fuzz [99] extend this by generating and mutating input generators rather than test inputs. ChatAFL [68] leverages LLMs’ knowledge of protocol specifications to guide protocol fuzzing, while KernelGPT [95] uses LLMs to generate syzkaller specifications for kernel fuzzing. PromptFuzz [66] uses LLMs to iteratively fuzz LLM prompts to generate fuzzing harnesses. CovRL [36]
combines LLM-based mutation with fine-tuning LLM from coverage feedback in JavaScript engine fuzzing. While these works focus on augmenting fuzzing, AFuzz uses deep agents to directly reason about code semantics to find bugs. Variant analysis. Traditionally, variant analysis found bugs by matching code patterns or signatures. CodeQL [39] and Joern [93] provide a query language to define buggy code patterns and allow these patterns to be matched against codebases. VUDDY [57], TRACER [56], and others [37, 54, 55, 87, 88, 90, 92] detect variants by matching abstracted code signatures, code hashes, program slices, or traces. These approaches rely on syntactic or structural similarity, which limits their ability to find logic bug variants that share semantic patterns but differ in code structure. JavaScript engine fuzzing. Fuzzing has been the predominant technique used to find bugs in JavaScript engines. JavaScript engine fuzzing spans 1 grammar-based fuzzing [21, 53, 81, 82], 2 semantics-aware generation [48, 86], 3 language model-based generation [36, 61], 4 mutation-based fuzzing [45, 51, 83, 84, 91], 5 differential and oracle-based testing [22, 80, 85], 6 binding-layer and cross-language fuzzing [35, 64], and 7 conformance testing [71, 97]. While these fuzzers have shown their effectiveness in finding bugs, they still struggle to find logic bugs that require semantic understanding.
9
Conclusion
We propose agentic fuzzing, which takes reference bugs as seeds and uses deep agents to find similar bugs through code reasoning. We designed an agentic fuzzer AFuzz with a four-stage agent pipeline, scenario coverage to avoid redundant investigations across seeds, and DPP-MAP seed scheduling to cover diverse root causes early. We evaluated AFuzz primarily on the V8 JavaScript engine, where it found 40 bugs (including three duplicates) with a total bounty of $35,000 and two CVEs (CVE-2026-2649 and CVE-2026-7902). Several of these are complex logic bugs that conventional fuzzing and static analysis struggle to find. We further showed that V8 seeds can be used in other engines, finding five bugs in SpiderMonkey (including one duplicate) and 14 in JavaScriptCore. However, agentic fuzzing is still in its early stages, with open problems including cost effectiveness, the need for reference bugs, and design uncertainty.
References [1] 2017. Proceedings of the 38th IEEE Symposium on Security and Privacy (Oakland). San Jose, CA. [2] 2019. Proceedings of the 26th Annual Network and Distributed System Security Symposium (NDSS). San Diego, CA. [3] 2020. Proceedings of the 29th USENIX Security Symposium (Security). Boston, MA. [4] 2022. Proceedings of the 29th ACM Conference on Computer and Communications Security (CCS). Los Angeles, CA. [5] 2023. Proceedings of the 32nd USENIX Security Symposium (Security). Anaheim, CA. [6] 2024. Proceedings of the 31st ACM Conference on Computer and Communications Security (CCS). Salt Lake City, UT. [7] 2024. Proceedings of the 33rd USENIX Security Symposium (Security). Philadelphia, PA. [8] 2024. Proceedings of the 46th International Conference on Software Engineering (ICSE). Lisbon, Portugal. [9] 2025. Proceedings of the 32nd Annual Network and Distributed System Security Symposium (NDSS). San Diego, CA. [10] 2025. Proceedings of the 34th USENIX Security Symposium (Security). Seattle, WA.
Agentic Fuzzing: Opportunities and Challenges
[11] [email protected]. 2025. DCHECK failure in (builder_>current_block()) == nullptr in maglev-graph-builder.cc. https://issues.chromium. org/issues/439945236. Accessed: 2026-04-23. [12] [email protected]. 2025. DCHECK failure in (builder_>current_block()) == nullptr in maglev-graph-builder.cc. https://issues.chromium. org/issues/440145531. Accessed: 2026-04-23. [13] [email protected]. 2025. DCHECK failure in (current_block()) == nullptr in maglev-graph-builder.cc. https://issues.chromium.org/issues/ 439752700. Accessed: 2026-04-23. [14] [email protected]. 2025. DCHECK failure in (current_block()) == nullptr in maglev-graph-builder.cc. https://issues.chromium.org/issues/ 439970326. Accessed: 2026-04-23. [15] [email protected]. 2025. DCHECK failure in new_nodes_at_end_.empty() in maglev-reducer.h. https://issues.chromium.org/issues/ 439752712. Accessed: 2026-04-23. [16] Anthropic. 2026. Agent SDK overview. https://platform.claude.com/docs/en/ agent-sdk/overview. Accessed: 2026-04-23. [17] Anthropic. 2026. Claude Code by Anthropic | AI Coding Agent, Terminal, IDE. https://claude.com/product/claude-code. Accessed: 2026-04-23. [18] Anthropic. 2026. Create custom subagents. https://code.claude.com/docs/en/subagents. Accessed: 2026-04-23. [19] Anthropic. 2026. Introducing Claude Opus 4.6. https://www.anthropic.com/ news/claude-opus-4-6. Accessed: 2026-04-23. [20] Anthropic. 2026. Todo Lists. https://code.claude.com/docs/en/agent-sdk/todotracking. Accessed: 2026-04-23. [21] Cornelius Aschermann, Tommaso Frassetto, Thorsten Holz, Patrick Jauernig, Ahmad-Reza Sadeghi, and Daniel Teuchert. 2019. NAUTILUS: Fishing for Deep Bugs with Grammars, See [2]. [22] Lukas Bernhard, Tobias Scharnowski, Moritz Schloegel, Tim Blazytko, and Thorsten Holz. 2022. JIT-Picking: Differential Fuzzing of JavaScript Engines, See [4]. [23] Kritik Bhattarai. 2026. V8 Sandbox bypass via untagged ExternalIntPtr in AccessBuilder::ForExternalIntPtr (Chrome 145.0.7632.159). https://issues.chromium. org/issues/491749534. Accessed: 2026-04-23. [24] Big Sleep. 2026. Big Sleep Tracker - Issue Tracker. https://issuetracker.google. com/savedsearches/7155917. Accessed: 2026-04-23. [25] Big Sleep team. 2024. From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code. https://projectzero.google/2024/ 10/from-naptime-to-big-sleep.html. Accessed: 2026-04-23. [26] Konstantin Borimechkov. 2025. Stop the Bleed: The Developer’s Guide to Taming Claude Code. https://theexcitedengineer.substack.com/p/stop-the-bleed-thedevelopers-guide. Accessed: 2026-04-23. [27] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel Ziegler, Jeffrey Wu, Clemens Winter, Chris Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Radford, Ilya Sutskever, and Dario Amodei. 2020. Language Models are Few-Shot Learners. In Proceedings of the 34th Annual Conference on Neural Information Processing Systems (NeurIPS). Virtual. [28] Chuyang Chen, Brendan Dolan-Gavitt, and Zhiqiang Lin. 2025. ELFuzz: Efficient Input Generation via LLM-driven Synthesis Over Fuzzer Space, See [10]. [29] Laming Chen, Guoxin Zhang, and Eric Zhou. 2018. Fast Greedy MAP Inference for Determinantal Point Process to Improve Recommendation Diversity. In Proceedings of the 32nd Annual Conference on Neural Information Processing Systems (NeurIPS). Montreal, Canada. [30] Isaac David and Arthur Gervais. 2025. Multi-Agent Penetration Testing AI for the Web. arXiv preprint arXiv:2508.20816 (2025). [31] Oege de Moor. 2024. Introducing XBOW. https://xbow.com/blog/introducingxbow. Accessed: 2026-04-23. [32] Gelei Deng, Yi Liu, Víctor Mayoral-Vilches, Peng Liu, Yuekang Li, Yuan Xu, Tianwei Zhang, Yang Liu, Martin Pinzger, and Stefan Rass. 2024. PentestGPT: Evaluating and harnessing large language models for automated penetration testing, See [7]. [33] Yinlin Deng, Chunqiu Steven Xia, Haoran Peng, Chenyuan Yang, and Lingming Zhang. 2023. Large Language Models Are Zero-Shot Fuzzers: Fuzzing DeepLearning Libraries via Large Language Models. In Proceedings of the International Symposium on Software Testing and Analysis (ISSTA). Seattle, WA.
[34] Yinlin Deng, Chunqiu Steven Xia, Chenyuan Yang, Shizhuo Dylan Zhang, Shujing Yang, and Lingming Zhang. 2024. Large Language Models are Edge-Case Generators: Crafting Unusual Programs for Fuzzing Deep Learning Libraries, See [8]. [35] Sung Ta Dinh, Haehyun Cho, Kyle Martin, Adam Oest, Kyle Zeng, Alexandros Kapravelos, Gail Joon Ahn, Tiffany Bao, Ruoyu Wang, Adam Doupé, and Yan Shoshitaishvili. 2021. Favocado: Fuzzing the Binding Code of JavaScript Engines Using Semantically Correct Test Cases. In Proceedings of the 28th Annual Network and Distributed System Security Symposium (NDSS). Virtual. [36] Jueon Eom, Seyeon Jeong, and Taekyoung Kwon. 2024. Fuzzing JavaScript Interpreters with Coverage-Guided Reinforcement Learning for LLM-Based Mutation. In Proceedings of the 33rd International Symposium on Software Testing and Analysis (ISSTA). Vienna, Austria. [37] Siyue Feng, Yueming Wu, Wenjie Xue, Sikui Pan, Deqing Zou, Yang Liu, and Hai Jin. 2024. FIRE: Combining Multi-Stage Filtering with Taint Analysis for Scalable Recurring Vulnerability Detection, See [7]. [38] Peter Girnus. 2026. Introducing ÆSIR: Finding Zero-Day Vulnerabilities at the Speed of AI. https://www.trendmicro.com/en_us/research/26/a/aesir.html. Accessed: 2026-04-23. [39] GitHub. [n. d.]. CodeQL. https://codeql.github.com/. Accessed: 2026-04-23. [40] Google. [n. d.]. Build, debug & deploy with AI | Gemini CLI. https://geminicli. com/. Accessed: 2026-04-23. [41] Google. [n. d.]. Chromium Issue Tracker. https://issues.chromium.org/. Accessed: 2026-04-23. [42] Google. [n. d.]. ClusterFuzz. https://github.com/google/clusterfuzz. Accessed: 2026-04-23. [43] Google Big Sleep. 2025. V8: Integer truncation during Maglev compilation leading to memory corruption. https://issues.chromium.org/issues/444048019. Accessed: 2026-04-23. [44] Google DeepMind. 2026. Gemma 4 — Google DeepMind. https://deepmind. google/models/gemma/gemma-4. Accessed: 2026-04-23. [45] Samuel Groß, Simon Koch, Lukas Bernhard, Thorsten Holz, and Martin Johns. 2023. FUZZILLI: Fuzzing for JavaScript JIT Compiler Vulnerabilities. In Proceedings of the 30th Annual Network and Distributed System Security Symposium (NDSS). San Diego, CA. [46] Samuel Groß. 2024. The V8 Sandbox. https://v8.dev/blog/sandbox. Accessed: 2026-04-23. [47] Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Peiyi Wang, Qihao Zhu, Runxin Xu, Ruoyu Zhang, Shirong Ma, Xiao Bi, et al. 2025. DeepSeek-R1 incentivizes reasoning in LLMs through reinforcement learning. Nature 645, 8081 (2025), 633–638. [48] HyungSeok Han, DongHyeon Oh, and Sang Kil Cha. 2019. CodeAlchemist: Semantics-aware Code Generation to Find Vulnerabilities in JavaScript Engines, See [2]. [49] Insu Han and Jennifer Gillenwater. 2020. MAP inference for customized determinantal point processes via maximum inner product search. In International Conference on Artificial Intelligence and Statistics. PMLR, 2797–2807. [50] Andreas Happe and Jürgen Cito. 2023. Getting pwn’d by AI: Penetration Testing with Large Language Models. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). San Francisco, CA. [51] Xiaoyu He, Xiaofei Xie, Yuekang Li, Jianwen Sun, Feng Li, Wei Zou, Yang Liu, Lei Yu, Jianhua Zhou, Wenchang Shi, and Wei Huo. 2021. SoFi: Reflection-Augmented Fuzzing for JavaScript Engines. In Proceedings of the 28th ACM Conference on Computer and Communications Security (CCS). Virtual. [52] Richard D Hipp. 2026. SQLite Home Page. https://sqlite.org. Accessed: 2026-0423. [53] Christian Holler, Kim Herzig, and Andreas Zeller. 2012. Fuzzing with Code Fragments. In Proceedings of the 21st USENIX Security Symposium (Security). Bellevue, WA. [54] Kaifeng Huang, Chenhao Lu, Yiheng Cao, Bihuan Chen, and Xin Peng. 2024. VMud: Detecting Recurring Vulnerabilities with Multiple Fixing Functions via Function Selection and Semantic Equivalent Statement Matching, See [6]. [55] Jiyong Jang, Abeer Agrawal, and David Brumley. 2012. ReDeBug: Finding Unpatched Code Clones in Entire OS Distributions. In Proceedings of the 33rd IEEE Symposium on Security and Privacy (Oakland). San Francisco, CA. [56] Wooseok Kang, Byoungho Son, and Kihong Heo. 2022. TRACER: Signature-based Static Analysis for Detecting Recurring Vulnerabilities, See [4].
Junyoung Park and Insu Yun
[57] Seulbae Kim, Seunghoon Woo, Heejo Lee, and Hakjoo Oh. 2017. VUDDY: A Scalable Approach for Vulnerable Code Clone Discovery, See [1]. [58] Kunlun Lab. 2021. Security: TianfuCup RCE bug Type confusion in LoadIC::ComputeHandler. https://issues.chromium.org/issues/40057622. Accessed: 2026-04-23. [59] LangChain. [n. d.]. deepagents. https://github.com/langchain-ai/deepagents. Accessed: 2026-04-23. [60] Stella Laurenzo. 2026. [MODEL] Claude Code is unusable for complex engineering tasks with the Feb updates. https://github.com/anthropics/claudecode/issues/42796. Accessed: 2026-04-23. [61] Suyoung Lee, HyungSeok Han, Sang Kil Cha, and Sooel Son. 2020. Montage: A Neural Network Language Model-Guided JavaScript Engine Fuzzer, See [3]. [62] Ahmed Lekssays, Hamza Mouhcine, Khang Tran, Ting Yu, and Issa Khalil. 2025. LLMxCPG: Context-Aware Vulnerability Detection Through Code Property Graph-Guided Large Language Models, See [10]. [63] Ziyang Li, Saikat Dutta, and Mayur Naik. 2025. IRIS: LLM-Assisted Static Analysis for Detecting Security Vulnerabilities. In Proceedings of the 13th International Conference on Learning Representations (ICLR). Singapore. [64] Jiayi Lin, Changhua Luo, Mingxue Zhang, Lanteng Lin, Penghui Li, and Chenxiong Qian. 2026. Fuzzing JavaScript Engines by Fusing JavaScript and WebAssembly. In Proceedings of the 48th International Conference on Software Engineering (ICSE). Rio de Janeiro, Brazil. [65] LLVM Project. 2026. libFuzzer - a library for coverage-guided fuzz testing. https://llvm.org/docs/LibFuzzer.html. Accessed: 2026-04-23. [66] Yunlong Lyu, Yuxuan Xie, Peng Chen, and Hao Chen. 2024. Prompt Fuzzing for Fuzz Driver Generation, See [6]. [67] Odile Macchi. 1975. The coincidence approach to stochastic point processes. Advances in Applied Probability 7, 1 (1975), 83–122. [68] Ruijie Meng, Martin Mirchev, Marcel Böhme, and Abhik Roychoudhury. 2024. Large Language Model guided Protocol Fuzzing. In Proceedings of the 31st Annual Network and Distributed System Security Symposium (NDSS). San Diego, CA. [69] OpenAI. [n. d.]. Codex. https://openai.com/codex. Accessed: 2026-04-23. [70] Junyoung Park. 2026. ANGLE: [REDACTED]. https://issues.chromium.org/ issues/501476576. Accessed: 2026-04-23. [71] Jihyeok Park, Seungmin An, Dongjun Youn, Gyeongwon Kim, and Sukyoung Ryu. 2021. JEST: N+1-Version Differential Testing of Both JavaScript Engines and Specification. In Proceedings of the 43rd International Conference on Software Engineering (ICSE). Madrid, Spain. [72] SeRya. 2010. Issue 1374005: Percise rounding parsing octal and hexadecimal strings.... (Closed). https://codereview.chromium.org/1374005. Accessed: 202604-23. [73] Xiangmin Shen, Lingzhi Wang, Zhenyuan Li, Yan Chen, Wencheng Zhao, Dawei Sun, Jiashui Wang, and Wei Ruan. 2025. PentestAgent: Incorporating LLM Agents to Automated Penetration Testing. In Proceedings of the 20th ACM Symposium on Information, Computer and Communications Security (ASIACCS). Ha Noi, Vietnam. [74] tckwgd. 2026. [BUG] Compaction death spiral - 211 compactions consuming all tokens with zero progress. https://github.com/anthropics/claude-code/issues/ 24179. Accessed: 2026-04-23. [75] The Chromium Authors. 2026. Chromium. https://www.chromium.org/Home. Accessed: 2026-04-23. [76] Dat Tran and Douwe Kiela. 2026. Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets. arXiv preprint arXiv:2604.02460 (2026). [77] Vivek Trivedy. 2026. The Anatomy of an Agent Harness. https://www.langchain. com/blog/the-anatomy-of-an-agent-harness. Accessed: 2026-04-23.
[83] Jiming Wang, Yan Kang, Chenggang Wu, Yuhao Hu, Yue Sun, Jikai Ren, Yuanming Lai, Mengyao Xie, Charles Zhang, Tao Li, and Zhe Wang. 2024. OptFuzz: Optimization Path Guided Fuzzing for JavaScript JIT Compilers, See [7]. [84] Jiming Wang, Chenggang Wu, Jikai Ren, Yuhao Hu, Yan Kang, Xiaojie Wei, Yuanming Lai, Mengyao Xie, and Zhe Wang. 2025. BCFuzz: Bytecode-Driven Fuzzing for JavaScript Engines. In Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). Seoul, South Korea. [85] Junjie Wang, Zhiyi Zhang, Shuang Liu, Xiaoning Du, and Junjie Chen. 2023. FuzzJIT: Oracle-Enhanced Fuzzing for JavaScript Engine JIT Compiler, See [5]. [86] Wai Kin Wong, Dongwei Xiao, Cheuk Tung Lai, Yiteng Peng, Daoyuan Wu, and Shuai Wang. 2025. Extraction and Mutation at a High Level: Template-Based Fuzzing for JavaScript Engines. In Proceedings of the Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) 2025. Singapore. [87] Seunghoon Woo, Eunjin Choi, Heejo Lee, and Hakjoo Oh. 2023. V1SCAN: Discovering 1-day Vulnerabilities in Reused C/C++ Open-source Software Components Using Code Classification Techniques, See [5]. [88] Seunghoon Woo, Hyunji Hong, Eunjin Choi, and Heejo Lee. 2022. MOVERY: A Precise Approach for Modified Vulnerable Code Clone Discovery from Modified Open-Source Software Components. In Proceedings of the 31st USENIX Security Symposium (Security). Boston, MA. [89] Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. 2024. Fuzz4All: Universal Fuzzing with Large Language Models, See [8]. [90] Yang Xiao, Bihuan Chen, Chendong Yu, Zhengzi Xu, Zimu Yuan, Feng Li, Binghong Liu, Yang Liu, Wei Huo, Wei Zou, and Wenchang Shi. 2020. MVP: Detecting Vulnerabilities using Patch-Enhanced Vulnerability Signatures, See [3]. [91] Haoran Xu, Zhiyuan Jiang, Yongjun Wang, Shuhui Fan, Shenglin Xu, Peidai Xie, Shaojing Fu, and Mathias Payer. 2024. Fuzzing JavaScript Engines with a Graph-based IR, See [6]. [92] Shangzhi Xu, Jialiang Dong, Weiting Cai, Juanru Li, Arash Shaghaghi, Nan Sun, and Siqi Ma. 2025. Enhancing Security in Third-Party Library Reuse Comprehensive Detection of 1-day Vulnerability through Code Patch Analysis, See [9]. [93] Fabian Yamaguchi, Nico Golde, Daniel Arp, and Konrad Rieck. 2014. Modeling and discovering vulnerabilities with code property graphs. In Proceedings of the 35th IEEE Symposium on Security and Privacy (Oakland). San Jose, CA. [94] Chenyuan Yang, Yinlin Deng, Runyu Lu, Jiayi Yao, Jiawei Liu, Reyhaneh Jabbarvand, and Lingming Zhang. 2024. WhiteFox: White-Box Compiler Fuzzing Empowered by Large Language Models. In Proceedings of the Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) 2024. Pasadena, CA. [95] Chenyuan Yang, Zijie Zhao, and Lingming Zhang. 2025. KernelGPT: Enhanced Kernel Fuzzing via Large Language Models. In Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). Rotterdam, Netherlands. [96] Yupeng Yang, Shenglong Yao, Jizhou Chen, and Wenke Lee. 2025. Hybrid Language Processor Fuzzing via LLM-Based Constraint Solving, See [10]. [97] Guixin Ye, Zhanyong Tang, Shin Hwei Tan, Songfang Huang, Dingyi Fang, Xiaoyang Sun, Lizhong Bian, Haibo Wang, and Zheng Wang. 2021. Automated conformance testing for JavaScript engines via deep compiler fuzzing. In Proceedings of the 2021 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). Virtual. [98] Z.AI. 2026. GLM-5.1. https://docs.z.ai/guides/llm/glm-5.1. Accessed: 2026-04-23. [99] Kunpeng Zhang, Zongjie Li, Daoyuan Wu, Shuai Wang, and Xin Xia. 2025. LowCost and Comprehensive Non-textual Input Fuzzing with LLM-Synthesized Input Generators, See [10].
[78] V8 Project Authors. [n. d.]. What is V8? https://v8.dev. Accessed: 2026-04-23. [79] Toon Verwaest, Leszek Swirski, Victor Gomes, Olivier Flückiger, Darius Mercadier, and Camillo Bruni. 2023. Maglev - V8’s Fastest Optimizing JIT. https: //v8.dev/blog/maglev. Accessed: 2026-04-23. [80] Liam Wachter, Julian Gremminger, Christian Wressnegger, Mathias Payer, and Flavio Toffalini. 2025. DUMPLING: Fine-grained Differential JavaScript Engine Fuzzing, See [9]. [81] Junjie Wang, Bihuan Chen, Lei Wei, and Yang Liu. 2017. Skyfire: Data-Driven Seed Generation for Fuzzing, See [1]. [82] Junjie Wang, Bihuan Chen, Lei Wei, and Yang Liu. 2019. Superion: GrammarAware Greybox Fuzzing. In Proceedings of the 41st International Conference on Software Engineering (ICSE). Montreal, Canada.
A
Ethical Considerations
As shown in Table 1 and Table 6, all bugs found during our research, including those found in §5.8, were reported to the respective vendors (e.g., Google). We redacted some bug details to avoid public disclosure before each vendor’s disclosure deadline — 90 days after a fix is released.
Agentic Fuzzing: Opportunities and Challenges
B
Generative AI Usage
We used generative AI in two ways: as the core component of AFuzz and as a development aid. First, AFuzz runs on Claude models, primarily Claude Opus 4.6 [19]. As described in §4, the agents use Claude Opus 4.6 through the Claude Agent SDK [16], and the scenario coverage check (§3.3) uses a lighter Claude model (i.e., Haiku) for semantic comparison. We also used open-source models gemma4 [44] and GLM 5.1 [98] for evaluation (§5.8). Therefore, all bug reports of AFuzz are produced by generative AI models. We independently checked every bug report by reviewing it, reproducing the PoC, and confirming the claimed behaviors before submitting the report to the respective vendor. Second, we used Claude Code [17] with the Opus 4.6 model [19] to quickly prototype and develop AFuzz, including the evaluation variants (e.g., the different pipeline designs). We thoroughly supervised the entire development process, and we conducted all experiments and checked all their results manually.
C
Example of AFuzz Finding a Bug
Using the motivating example (§2.1), we walk through how the pipeline discovers the Turboshaft variant from the Maglev reference bug. Given the reference bug CVE-2025-10892 [43] as a URL, Analyzer starts by fetching the issue contents, including the discussion, patches, and PoC code. Analyzer then dispatches Explore subagents to read relevant source files such as maglev-ir.h, maglev-graph-builder.cc, and base/bit-field.h. After reading these files, Analyzer determines that the root cause of the reference bug is an integer overflow in a compiler IR metadata field (i.e., size_t input_count in Operation) that is only guarded by a debug assertion. Analyzer captures this insight as the bug mechanism of the reference bug, which is a concise description of the root cause that later stages can use to search for variants. Investigator takes the report from Analyzer and scans the V8 codebase for similar root causes. It starts with Maglev, where the reference bug was found, and searches for other integer fields in Maglev’s IR classes that are guarded only by debug assertions. After thoroughly searching Maglev code, Investigator widens the search to other backends with grep queries such as BitField64.*Count and uint16_t.*input_count, and lands on Turboshaft, which shares a similar mechanism with Maglev. In Turboshaft, the Operation constructor (operations.h) narrows an incoming size_t input count to a uint16_t and guards it with a DCHECK. Investigator traces the construction path from the start of graph building to the PhiOp construction, and notices that PhiOp does not have an explicit pre-construction check. Investigator hypothesizes that a PhiOp with more than 65,535 predecessors would cause the count to be silently truncated, leading to memory corruption, and submits a scenario describing the trigger conditions, affected source locations, and an advisory note pointing to br_table as a way to inflate the predecessor count. Scenario Analyzer takes the scenario from Investigator and writes a PoC to trigger the vulnerability. It reads the relevant source files such as turboshaft-graph-interface.cc and ReduceSwitch, and learns that each br_if or br_table target adds one predecessor at the destination block. It also finds the per-table cap
kV8MaxWasmFunctionBrTableSize = 65,520 by reading wasm-limits.h. Thinking that a single br_table cannot exceed the 16-bit limit, it decides to use two br_table instructions in opposite arms of an if-else, each with 33,000 entries targeting the same outer block, to trigger the overflow (shown in Figure 1b). Scenario Analyzer then initially runs the PoC on a release build, which completes without any observable evidence because the integer truncation silently occurs. Scenario Analyzer then re-runs the same PoC on a debug build, where the DCHECK on operations.h fires, confirming that the truncation occurs and violates the invariant defined by the DCHECK. Validator independently verifies the bug by re-executing the PoC on a clean V8 build and observing the same release and debug results. It confirms that the debug assertion failure matches the hypothesized integer truncation rather than an unrelated one, and that no security-disabling flags or debug-only natives are used in reproducing the bug. After verification, Validator accepts the scenario and writes a vulnerability report covering summary, trigger conditions, reproduction steps with both release and debug outputs, and a suggested patch with an input-count check before PhiOp construction.
D
Case Studies
Bug #9: parseInt exponent overflow. V8 has a bug in the JavaScript parseInt function (converts strings to integers) that makes the function return 0 instead of Infinity when parsing long strings with a power-of-two radix (e.g., 32). When V8 parses a long string whose numeric value exceeds 53-bit precision, it truncates the low bits of the integer and tracks the excess as an integer exponent. The problem is that for radix 32, the exponent can grow large enough to overflow a signed integer when a string of more than 429,496,740 characters is parsed (e.g., parseInt("1".repeat(429496741), 32)). The overflow makes the exponent negative, so instead of returning Infinity as it should, parseInt incorrectly returns 0. This bug has existed since March 2010 [72], for over 16 years. AFuzz could recognize the tricky trigger conditions of this bug by analyzing the code and reasoning about how the exponent grows with string length and radix. Because the bug requires a string of over 429 million characters, it needs 64-bit builds to trigger, since V8 limits string length to about 512MB (i.e., (1 << 29) − 24) on 64-bit builds and about 256MB (i.e., (1 << 28) − 24) on 32-bit builds. Among power-of-2 radixes, only the maximum radix 32 has an overflow threshold that fits under the string length limit, so the bug is specific to radix 32. Because of these specific and non-obvious trigger conditions, this bug has survived for over 16 years without being discovered by fuzzing or manual auditing, demonstrating the effectiveness of AFuzz in finding hard-to-find bugs that require deep understanding and complex reasoning. Bug #12: Turboshaft loop unrolling. Turboshaft had a bug in its loop unrolling optimization that caused incorrect calculations of iteration counts for loops that contain subtractions. Before unrolling a loop, Turboshaft simulates the loop execution to compute how many iterations it will run. However, its simulation logic wrongly assumes that the subtraction operator is commutative, making it wrongly compute loop variable updates of i = c - i as if they were
Junyoung Park and Insu Yun 1 2 3 4 5 6 7 8 9 10 11 12 13
function f() { let count = 0; for (let i = 2; i >= 0; i = (3 - i) | 0) { // i oscillates: 2 -> 1 -> 2 -> 1 -> ... count = (count + 1) | 0; if (count >= 5) break; } return count; // should be 5 } %PrepareFunctionForOptimization(f); f(); %OptimizeFunctionOnNextCall(f); f(); // interpreter: 5 (correct), Turboshaft: 2 (wrong)
Figure 5: Minified PoC for bug #12. The loop update i = (3 - i) | 0 oscillates i between 2 and 1, so count reaches 5. After loop peeling, which extracts the first iteration and makes 𝑖 = 3 − 2 = 1, Turboshaft simulates the update as i - 3 instead of 3 - i, predicts the loop exits after 1 iteration, and unrolls it to return 2. i = i - c. As a result, Turboshaft miscomputes the loop variable’s value and predicts the wrong iteration count, which can lead to under-unrolling and miscompilation. AFuzz managed to construct a non-trivial oscillating loop to trigger this bug, shown in Figure 5. The loop variable i is updated as i = (3 - i) | 0, which oscillates i between 2 and 1. The loop body increments count and breaks when count >= 5, so the loop runs for 5 iterations before breaking. However, in the case of Turboshaft, after the loop peeling phase extracts the first iteration with i=2, the remaining loop has the update i = 3 - i with an initial value i=1. Turboshaft then simulates this update as if it were i = i - 3, which produces the sequence 1 → 1 − 3 = −2, and predicts the loop exits after just 1 iteration. Therefore, it unrolls the loop into only two iterations, making the optimized code return 2 instead of 5.
Agentic Fuzzing: Opportunities and Challenges
Table 7: Detailed bug reproducibility across pipeline design choices. Each cell shows the number of times (out of 5 runs) a bug was discovered by the given design. Bugs that correspond to entries in Table 1 are annotated with their bug number and ID. Three bugs (marked –) were independently fixed before we reported them and are therefore not listed in Table 1. High #
ID
– 13 23 – 26 24 27 7 28 38 21 22 14 20 12 32 31 30 25 – 17
– 498010834 499254996 – 499659062 499323105 499672315 499659070 499834467 499103615 499206651 499254994 498904291 499188872 491881374 500536164 500507436 500507435 499520013 – 499018901
Detail Maglev Phi Representation Selector Type Confusion ARM32 Assembler ClearInternalState Invariant Missing Immutability Check for using/await using Exports Stack Overflow in Generate_ResumeGeneratorTrampoline Fast API kUint64 Signed/Unsigned Confusion Missing PrecededByMember Check in ParseReturnStatement Private Name Resolution via FinalizeBlockScope Skip Bit Loss TurboFan SpeculativeAdditiveSafeIntegerAdd Type Narrowing Deoptimizer Undefined NaN Constant Mishandling Immutability Bypass in JIT DataView Setters Missing Escape Sequence Check for using Keyword Double-Dispose of using in C-style For-Loop Wrong DCHECK in DependOnContextCell Missing Prototype Chain Dependency for ModuleExport Non-Commutative Subtraction in Turboshaft Loop Unrolling IterableForEach Missing Array Prototype Check RISCV64 Maglev CompareIntPtrAndBranch Codegen RISCV64 Maglev ToUint8Clamped Codegen JSBuiltinsConstructStub Stack Overflow on RISCV/LOONG64/MIPS64 LOONG64 Maglev Branch Offset Overflow LOONG64 PatchToJump SIGSEGV via Missing RwxMemoryWriteScope pass@5 Total
Medium
Low
Four
Three
One
Four
Three
One
Four
Three
One
1/5 5/5 3/5 5/5 1/5 4/5 1/5 1/5 1/5 3/5 1/5 1/5 0/5 2/5 2/5 0/5 0/5 0/5 1/5 0/5 0/5
0/5 3/5 1/5 5/5 0/5 1/5 0/5 0/5 0/5 0/5 2/5 1/5 1/5 0/5 1/5 0/5 0/5 0/5 0/5 0/5 0/5
0/5 4/5 1/5 3/5 0/5 1/5 0/5 0/5 0/5 1/5 3/5 3/5 1/5 0/5 4/5 1/5 1/5 1/5 0/5 0/5 1/5
0/5 5/5 1/5 2/5 0/5 3/5 0/5 0/5 0/5 1/5 2/5 0/5 0/5 1/5 0/5 2/5 0/5 0/5 2/5 0/5 0/5
0/5 3/5 0/5 3/5 0/5 3/5 0/5 0/5 0/5 1/5 3/5 1/5 1/5 1/5 0/5 1/5 0/5 0/5 1/5 1/5 0/5
0/5 4/5 0/5 2/5 0/5 1/5 0/5 0/5 0/5 0/5 1/5 4/5 0/5 1/5 2/5 0/5 0/5 0/5 0/5 1/5 1/5
0/5 4/5 0/5 5/5 0/5 1/5 0/5 0/5 0/5 0/5 2/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5
0/5 2/5 0/5 1/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 2/5 0/5 0/5 0/5 1/5 0/5 0/5 2/5 0/5 0/5
0/5 0/5 0/5 1/5 0/5 0/5 0/5 0/5 0/5 0/5 1/5 1/5 1/5 0/5 0/5 0/5 0/5 0/5 2/5 0/5 1/5
15/21 32/105
8/21 15/105
13/21 25/105
9/21 19/105
11/21 19/105
9/21 17/105
4/21 12/105
5/21 8/105
6/21 7/105