FuzzingBrain V2: A Multi-Agent LLM System for Automated Vulnerability Discovery and Reproduction
arXiv:2605.21779v1 [cs.CR] 20 May 2026
Ze Sheng Texas A&M University [email protected]
Zhicheng Chen Texas A&M University [email protected]
Kewen Zhu Texas A&M University [email protected]
Qingxiao Xu Texas A&M University [email protected]
Jeff Huang Texas A&M University [email protected]
Abstract Software vulnerabilities pose critical security threats, with nearly 50,000 CVEs reported in 2025. While Large Language Models (LLMs) show promise for automated vulnerability detection, three key challenges remain. First, LLM-generated vulnerability reports suffer from high false positive rates and lack reproducible verification. Second, existing LLM-based approaches use suboptimal granularities for vulnerability localization: function-level analysis overlooks bugs when context becomes extensive, while line-level analysis lacks sufficient context. Third, existing approaches have difficulty reasoning about vulnerabilities with complex cross-function dependencies and triggering conditions. We present FuzzingBrain V2, a multi-agent system that addresses these gaps through four key contributions: (1) fully automated vulnerability analysis built on Google’s OSS-Fuzz, ensuring all reported vulnerabilities are fuzzer-reproducible; (2) Suspicious Point, a novel control-flow-based abstraction for precise vulnerability localization at the optimal granularity; (3) logic-driven hierarchical function analysis with duallayer fuzzing enhancing function coverage under resource constraints; (4) MCP-based static and dynamic analysis tools with context engineering enhancing complex vulnerability reasoning. On the AIxCC 2025 Final Competition C/C++ dataset, FuzzingBrain V2 achieved 90% detection rate (36 of 40 vulnerabilities). In real-world deployment, FuzzingBrain V2 discovered 29 zero-day vulnerabilities across 12 open-source projects, all confirmed and fixed by maintainers, with 2 assigned CVE IDs.
1
Figure 1: Annual CVE disclosures from 2020 to 2025, showing a sharp increase in reported vulnerabilities.
code while exhibiting overconfidence in its safety [10, 21]. Studies from Microsoft and Google indicate that approximately 70% of security vulnerabilities in C/C++ codebases stem from memory safety issues [19, 26], a finding reinforced by CISA’s 2025 guidance on memory safe languages [4]. The MongoBleed vulnerability (CVE-2025-14847) in December 2025, which exposed over 87,000 MongoDB servers to unauthenticated memory leaks, underscores how memory safety issues continue to threaten critical infrastructure [28]. Effective vulnerability detection is therefore essential for modern software development. State-of-the-art vulnerability detection approaches fall into two categories: static analysis and dynamic analysis. Static analysis tools leverage techniques such as code property graphs [30], abstract interpretation [3], and query-based analysis [2] to examine source code for potential vulnerabilities. However, these approaches suffer from high false positive rates that overwhelm manual review. Dynamic analysis, particularly fuzz testing with tools like AFL [33] and libFuzzer [17], discovers vulnerabilities through input mutation and crash monitoring. However, fuzzing operates without semantic understanding of program logic, limiting its ability to reach deep vulnerabilities protected by complex path constraints
Introduction
Software vulnerabilities remain a critical threat to system security. CVE disclosures have surged in recent years, with over 40,000 new vulnerabilities reported in 2024 and nearly 50,000 in 2025. Moreover, recent studies indicate that developers using AI coding assistants tend to produce less secure 1
such as checksums, magic numbers, or multi-stage protocol handshakes. Large Language Models (LLMs) offer a potential solution by combining code comprehension with reasoning capabilities. Models trained on code corpora can understand program semantics, identify suspicious patterns, and reason about data flow across functions. The success of DARPA’s AIxCC 2025 competition [6], where LLM-based systems discovered real vulnerabilities in production software, demonstrates this potential. However, directly applying LLMs to vulnerability detection faces significant challenges. According to recent surveys on LLM-based vulnerability detection [23, 35], three fundamental gaps remain:
captures vulnerability-relevant code regions with control flow context, bridging the gap between LLM analysis and fuzzing-based reproduction. • We propose a logic-driven hierarchical search strategy with dual-layer fuzzing. Rather than matching known vulnerability patterns, our system analyzes business logic to identify suspicious behaviors, enabling deep understanding of vulnerabilities with complex contextual dependencies. • We evaluate FuzzingBrain V2 on the AIxCC C/C++ dataset, achieving 90% detection rate (36 of 40 vulnerabilities), and discovered 41 zero-day vulnerabilities across 19 open-source projects.
Gap 1: LLM-reported vulnerabilities cannot be verified without executable proof-of-concept inputs, leaving security teams unable to distinguish true vulnerabilities from hallucinations.
The remainder of this paper is organized as follows: Section 2 provides background on fuzzing and LLM agents. Section 3 describes FuzzingBrain V2’s system design. Section 4 discusses implementation details. Section 5 presents our evaluation. Section 6 discusses limitations and future work. Section 7 concludes.
Gap 2: Current approaches operate at suboptimal granularities. Function-level analysis is too coarse—LLMs exhibit attention bias toward certain patterns while overlooking others. Line-level analysis is too fine—insufficient context leads to high false positive rates. Gap 3: Complex contextual dependencies—cross-function data flow, indirect calls, and stateful operations—limit LLM understanding of vulnerabilities spanning multiple functions. We propose FuzzingBrain V2, an MCP-based multi-agent vulnerability detection system that addresses these gaps. For Gap 1, we adopt Google’s OSS-Fuzz framework as our verification backend, ensuring that every reported vulnerability is reproducible through established fuzzers and sanitizers—OSS-Fuzz integrates over 1,000 open-source projects, enabling direct deployment at scale. For Gap 2, we introduce Suspicious Point (SP), a novel abstraction between line-level and function-level granularity that captures vulnerability-relevant code regions with control flow context, enabling both precise localization and systematic reproduction. For Gap 3, we employ a multi-agent architecture with hierarchical search strategy, where specialized agents collaborate to gather cross-function context, analyze complex data flows, and reason about program state. Our system leverages LLM code comprehension to analyze business logic and identify suspicious behaviors that deviate from expected program semantics. This paper makes the following contributions:
2 2.1
Background and Related Work Fuzzing and OSS-Fuzz
Fuzz testing (fuzzing) is a dynamic analysis technique that discovers software vulnerabilities by feeding programs with randomly generated or mutated inputs and monitoring for abnormal behaviors. Modern fuzzers such as AFL [33] and libFuzzer [17] employ coverage-guided mutation strategies, prioritizing inputs that explore new code paths to maximize code coverage. To detect vulnerabilities beyond simple crashes, fuzzers are typically paired with sanitizers—compiler-based instrumentation tools that detect memory errors at runtime. AddressSanitizer (ASan) detects out-of-bounds accesses and use-after-free errors, MemorySanitizer (MSan) identifies uninitialized memory reads, and UndefinedBehaviorSanitizer (UBSan) catches undefined behavior such as integer overflows. OSS-Fuzz [22] is Google’s continuous fuzzing infrastructure for open-source software. We adopt OSS-Fuzz as our fuzzing backend for three reasons: (1) Easy integration: OSS-Fuzz integrates over 1,000 open-source projects, allowing FuzzingBrain V2 to be directly deployed without additional configuration; (2) Extensibility: custom fuzzers and harnesses can be easily added to target specific functions or code paths; (3) Built-in analysis toolchain: OSS-Fuzz integrates Fuzz Introspector, which provides call graph and reachability analysis along with runtime coverage information, which we leverage for code understanding and coverageguided exploration. In this work, we focus on C/C++ projects and use libFuzzer as the primary fuzzing engine.
• We present FuzzingBrain V2, a fully automated multiagent vulnerability detection system built on Google’s OSS-Fuzz and the Model Context Protocol (MCP). The system can be directly deployed on over 1,000 opensource projects, guarantees 100% reproducibility for confirmed vulnerabilities, and automatically generates submission-ready vulnerability reports. • We introduce Suspicious Point (SP), a novel abstraction between line-level and function-level granularity that 2
2.2
Vulnerability Definition
is crucial for LLM-based detection, achieving significant improvements when sufficient context is provided. Huynh et al. [12] explored prompt engineering strategies for vulnerability detection. LLMxCPG [13] uses code property graphs to extract minimal context slices for LLM analysis. However, these approaches primarily treat vulnerability detection as a classification task without providing reproducible proof-ofconcept inputs. LLM-based Fuzzing. Recent work has explored using LLMs to enhance fuzzing. Fuzz4All [29] uses LLMs to generate test inputs across multiple languages. WhiteFox [31] applies LLMs to white-box compiler fuzzing, generating inputs that trigger optimization bugs. KernelGPT [32] uses LLMs to generate syscall specifications for Syzkaller. Most relevant to our work, OSS-Fuzz-Gen [7] uses LLMs to automatically generate fuzz drivers for OSS-Fuzz. While these approaches improve fuzzing efficiency, they focus on input or harness generation rather than vulnerability-directed exploration. Hybrid Approaches. To improve reliability, recent work combines LLMs with traditional analysis tools. IRIS [5] uses LLMs to filter false positives from static analysis. LLM4Vuln [25] provides a unified framework to evaluate and enhance LLM vulnerability reasoning. Vul-RAG [34] uses retrieval-augmented generation to incorporate known vulnerability knowledge. LLM-SmartAudit [27] introduces a multi-agent architecture for smart contract vulnerability detection. Unlike these approaches, FuzzingBrain V2 integrates LLM analysis with fuzzing-based verification for C/C++ programs, ensuring every reported vulnerability is reproducible through crash-triggering inputs.
In this paper, we adopt a fuzzing-centric definition of vulnerability. Given a program P and a code location v: v ∈ V (P) ⇐⇒ ∃ i : ∀ run, loc(crash(exec(P, i))) = v (1) A location v is vulnerable if and only if there exists an input i that consistently triggers a sanitizer-detected crash at v across all executions. This definition ensures every reported vulnerability is verifiable and reproducible, eliminating the uncertainty inherent in static analysis or LLM-only approaches.
2.3
LLM Agents and Model Context Protocol
An LLM agent is an autonomous system that combines a large language model with external tools and iterative reasoning to accomplish complex tasks. Unlike simple LLM queries, agents can plan multi-step actions, invoke tools (e.g., code search, compilers, fuzzers), observe results, and adapt their strategy accordingly. Multi-agent systems extend this concept by coordinating multiple specialized agents, each responsible for a specific subtask, to solve problems beyond the capability of a single agent. The Model Context Protocol (MCP) [1] is an open standard by Anthropic for LLM-tool integration. Without MCP, each AI application requires custom code to connect to each tool. MCP defines a unified interface: AI applications implement a Client, tools implement a Server, and they interoperate automatically. We adopt FastMCP [18] as the MCP framework for FuzzingBrain V2: (1) FuzzingBrain V2 itself is wrapped as an MCP-callable tool, allowing external LLM applications to invoke vulnerability detection as a service; (2) all internal agents follow the MCP protocol, enabling modular design and seamless inter-agent communication.
2.4
3
System Design
3.1
Overview
Figure 2 presents the architecture of FuzzingBrain V2. The system operates in three stages: (1) Static Analysis extracts function metadata and call graphs via Fuzz Introspector, storing results in a database; (2) Agent Pipeline employs specialized LLM agents to discover and verify Suspicious Points through hierarchical search; (3) PoC Generation combines PoC Generator reasoning with dual-layer fuzzing to generate reproducible crash-triggering inputs. The system takes an OSS-Fuzz project as input and outputs vulnerability reports with crash-triggering inputs. Each worker handles a specific fuzzer-sanitizer pair (e.g., libpng_read_fuzzer with ASan), enabling parallel analysis across different sanitizers. FuzzingBrain V2 supports two scan modes:
Related Work
LLM-based Vulnerability Detection. Recent surveys [23, 35] provide comprehensive overviews of this rapidly evolving field. Early work applied deep learning to vulnerability detection: VulDeePecker [15] pioneered using BLSTM on code slices, while Devign [36] leveraged graph neural networks to learn from AST, CFG, and DFG structures. Pre-trained language models further advanced this field: CodeBERT [9] introduced bimodal pre-training on code and natural language, and VulBERTa [11] specialized RoBERTa for C/C++ vulnerability detection. Recent work has examined LLM capabilities more critically—Ding et al. [8] systematically evaluated code LLMs and found their vulnerability detection performance falls short of expectations. GRACE [20] attempts to improve LLM detection by combining graph structures with in-context learning. Li et al. [14] demonstrated that context
• Full-Scan Mode: Given a fuzzer, performs comprehensive vulnerability analysis across the entire codebase. • Delta-Scan Mode: Given a fuzzer and two code versions (e.g., a commit), analyzes whether the changes introduce 3
Figure 2: System overview of FuzzingBrain V2. The Controller orchestrates static analysis, agent pipeline execution, and fuzzing. Components communicate through a shared database, with the SP abstraction bridging SP Generator, SP Verifier, and PoC Generator. new vulnerabilities.
Suspicious Point Example
Table 1 lists the model tiers and specialized agents in FuzzingBrain V2.
3.2
function: png_read_row (pngread.c) sources: [png_fuzzer + ASan, png_read_fuzzer + ASan] description: In the else branch of the if (png_ptr->transformations) check, after calling png_do_read_transformations(), the memcpy at the end of the function copies row_bytes into row without verifying that row has sufficient space when row_bytes exceeds the originally allocated size. vuln_type: heap-buffer-overflow score: 0.82 is_verified: true poc_guidance: Craft PNG with large row_bytes after transformation; set transformations flag to trigger the else branch. is_real: true poc_attempted_by: [png_fuzzer, png_read_fuzzer] poc_ids: [a3f2c1d8-..., b7e4f9a2-...]
Suspicious Point
During logic-driven search (Section 3.4), the SP Generator analyzes functions to identify potential vulnerabilities. Each identified vulnerability is captured as a Suspicious Point (SP)—the core abstraction that bridges SP Generator, SP Verifier, and PoC Generator. SP addresses the granularity problem in LLM-based vulnerability detection. Rather than asking the LLM to output a vague analysis of an entire function, SP requires the LLM to produce a structured report for each suspicious code location—treating it as a real vulnerability. Each SP is independent, enabling parallel verification and PoC generation. 3.2.1
SP Structure and Lifecycle
Figure 3 shows an example SP. We use control-flow descriptions instead of line numbers because LLMs frequently hallucinate exact line numbers. An SP progresses through three stages (see Figure 2), with fields populated progressively:
Figure 3: Example Suspicious Point. The description uses control-flow landmarks instead of line numbers. Fields are populated progressively: is_verified and poc_guidance after verification; is_real, poc_attempted_by, and poc_ids after PoC generation.
• Creation: The SP Generator analyzes functions for suspicious patterns and performs preliminary feasibility checks, populating function, sources, description, vuln_type, and initial score.
• PoC Generation: The PoC Generator crafts inputs for fuzzer and sanitizer to trigger the vulnerability, setting is_real, poc_attempted_by, and poc_ids upon success.
• Verification: The SP Verifier performs deeper analysis, tracing call paths and checking for safety boundaries, then updates is_verified, score, and poc_guidance. 4
Table 1: Model tiers and specialized agents in FuzzingBrain V2. Tier
Models
Usage
T1 (Reasoning) T2 (Main) T3 (Utils)
O3, GPT-5.2-Pro, Claude-Opus-4.5 Claude-Sonnet-4.5, GPT-5.2, Gemini-3-Pro Claude-Haiku-4.5, GPT-5-Mini, Gemini-3-Flash
Complex reasoning, strategic planning Code analysis, core agent work Context compression
Agent
Role
Model Tier
Section
Direction Generator SP Generator SP Deduplicator SP Verifier PoC Generator Report Agent Seed Generator Context Compressor
Divide codebase into logical directions Initial screening for suspicious patterns Identify and merge duplicate SPs In-depth verification of SPs Craft inputs to trigger vulnerabilities Refine SP and generate vulnerability report Generate fuzzer seeds from directions/FPs Compress context for cross-function analysis
T1 T2 T3 T1 T2 T2 T2 T3
3.4.1 3.4.3 3.4.3 3.4.4 3.4.5 3.4.5 3.6 3.4.4
3.3
Task Processing and Worker Distribution
3.3.1
Static Analysis and Call Graph
FuzzingBrain V2 begins by constructing a call graph from static analysis results. While we use Fuzz-Introspector [22] by default, the system accepts any tool that provides function metadata and call relationships. The static analysis extracts: (1) function metadata (name, file path, source code), (2) call relationships (caller-callee edges), and (3) fuzzer reachability (which fuzzers can reach each function). From this data, we construct a global call graph containing all functions reachable by at least one fuzzer. Each function maintains a reached_by_fuzzers field indicating which fuzzers can reach it. We compute call_depth for each function via BFS from entry points (functions directly called by fuzzers).
Figure 4: Worker distribution. The scheduler allocates each (fuzzer, sanitizer) pair to a separate worker, enabling parallel analysis across different fuzzers and sanitizers.
3.4 3.3.2
Worker Distribution
Logic-Driven Search (Full-Scan Mode)
In Full-Scan mode (lower-left of Figure 5), a worker analyzes the entire codebase reachable by its assigned fuzzersanitizer pair. The Direction Generator reads the fuzzer and codebase to generate directions—each representing a business feature. The SP Generator then analyzes functions according to a tiered scheduling strategy, producing SPs that are subsequently verified. Finally, verified SPs undergo PoC generation with dual-layer fuzzing support.
After static analysis, FuzzingBrain V2 distributes work across parallel workers. Each worker handles a specific task—a (fuzzer, sanitizer) pair such as (png_read_fuzzer, AddressSanitizer). This design reflects a key insight: different fuzzers reach different code paths, and different sanitizers detect different vulnerability classes. For a project with F fuzzers and S sanitizers, we spawn up to F × S workers (Figure 4). Each worker operates on a filtered subgraph of the global call graph containing only functions reachable by its assigned fuzzer, then executes the full agent pipeline independently.
3.4.1
Direction
A direction represents a logical feature of the codebase. We organize search by directions rather than vulnerability patterns (e.g., “buffer overflow”, “use-after-free”) based on a key insight: fuzzers are designed to test features, not to find specific bug types. This semantic grouping extracts related
Each worker executes the agent pipeline according to its scan mode (Figure 5): Full-Scan mode performs comprehensive analysis via direction-based search, while Delta-Scan mode focuses on changed functions from a commit. 5
Figure 5: Per-worker pipeline. Upper: single agent implementation with LLM tiers (T1 reasoning, T2 main, T3 utils) and MCP tools (SAST, DAST, Utils). Lower: agent layer workflow showing Full-Scan mode (direction-based) and Delta-Scan mode (commit-based) converging into the SP generation, verification, and PoC generation pipeline. 3.4.2
functions, enabling subsequent agents to focus on cohesive code regions. LLMs excel at code semantic understanding, making them well-suited for this task.
Priority Scheduling
From each direction, we extract functions into two pools based on their role: • Core Pool: Entry functions and core functions identified by the Direction Generator—high-priority targets.
Direction Example (libpng [16]) name: PNG chunk parsing entry_functions: [read_chunk_header, ...] core_functions: [handle_IHDR, handle_PLTE, ...] risk_level: high/medium/low risk_reason: Parses untrusted chunk data with variable-length fields
• General Pool: Other reachable functions within the direction—analyzed on a best-effort basis. We adopt a function-centric analysis strategy: each function is analyzed individually. When given multiple functions at once, LLMs tend to selectively focus on some while overlooking others. By analyzing one function at a time—while providing callers, callees, and MCP tools to explore context—we ensure the agent examines all suspicious patterns within each function thoroughly. Functions are scheduled according to a priority matrix (Table 2) combining pool membership and global analysis status. Priority scheduling improves search efficiency. Since a function may appear in the core pools of multiple directions, this design prevents the same function from being analyzed repeatedly by different directions within a short period, maximizing the breadth of function coverage.
Figure 6: Example direction for libpng [16]. Each direction includes a business feature name, entry/core functions defining analysis scope, and risk level for prioritization.
The Direction Generator (prompt in Figure 12) first analyzes the fuzzer’s source code to understand what it tests, then explores the codebase via MCP tools before invoking create_direction to generate at most 5 directions per worker (Figure 6). For each direction, it produces: a name describing the business feature, entry_functions where this feature’s logic begins, core_functions implementing the logic, and risk_level (high/medium/low) for prioritization.
3.4.3
SP Generation & Deduplication
The SP Generator (prompt in Figure 13) performs initial screening on each function. It adopts a high-recall strategy: re6
3.4.5
Table 2: Priority scheduling matrix combining pool membership and analysis status. Pool
Unanalyzed
Analyzed†
Core General
Priority 1* Priority 3
Priority 2 Priority 4
The PoC Generator (prompt in Figure 15) processes SPs from the priority queue, iteratively crafting inputs to trigger each vulnerability. For each attempt, the generator produces Python code that outputs multiple blob variants—using code generation rather than direct byte output ensures format correctness and enables structured exploration of the input space. Each blob is verified individually: on success, the SP is confirmed as a real vulnerability; on failure, the generator receives execution output hints and the blob is added to the SP Fuzzer corpus (Section 3.6) for mutation. After several failed attempts, dynamic tracing becomes available, revealing which functions were executed and where the path diverged from the target. This progressive strategy balances token cost: dynamic tracing provides more information but consumes more context, so we reserve it for difficult cases. The generator iterates until a crash is confirmed or configurable attempt limits are reached. When an SP is reachable by multiple fuzzers, each fuzzer attempts PoC generation independently, increasing success probability through different entry paths. Upon successful crash, a Report Agent analyzes the crash trace to refine the SP description, then generates a structured JSON output along with a human-readable vulnerability report. The report can be directly submitted to GitHub Issues or Security Advisories.
* Highest priority. † Examined by other directions but may yield different insights.
port potential issues liberally, as a dedicated Verifier will filter false positives later. The generator is sanitizer-aware, focusing on patterns detectable by the current worker’s sanitizer (e.g., buffer operations for AddressSanitizer, uninitialized memory for MemorySanitizer). Since the same vulnerability may be discovered multiple times—by different directions within a worker, by different workers analyzing overlapping code, or by the same generator in different iterations—we employ an SP Deduplicator (T3 model) to identify duplicates. The deduplicator compares each new SP against existing SPs in the database, checking function name, vulnerability type, and description similarity. Duplicates are merged rather than discarded: source information is combined, and the higher confidence score is retained. 3.4.4
PoC Generation and Reporting
SP Verification
The SP Verifier (prompt in Figure 14) performs in-depth analysis on each SP. As the most capable agent in the pipeline, it has full access to code analysis tools and employs a T3 utility model for intelligent context compression when tracing cross-function data flows. The Verifier examines three aspects:
3.5
Delta-Scan Processing
In Delta-Scan mode, FuzzingBrain V2 analyzes code changes between two versions (e.g., a commit) rather than the entire codebase. The system parses the diff to extract reachable modified functions—these functions replace directions as the analysis scope. We preserve commit messages and comments in the diff context, as they may help agents understand the intent behind code changes; if irrelevant, the Context Compressor removes them automatically. The subsequent pipeline (SP Generation, SP Verification, PoC Generation) follows the same logic as Full-Scan.
• Reachability: Not just function reachability, but whether fuzzer input can reach the specific vulnerable code path. • Safety boundaries: Traces context to verify whether existing protections (bounds checks, input validation) are actually correct—they often contain subtle flaws. • Accuracy: Validates whether the SP description matches the actual code. If the location is correct but the description is wrong, the Verifier corrects it rather than rejecting the SP.
3.6
Dual-layer Fuzzing
FuzzingBrain V2 employs two fuzzer layers (Figure 5): Global Fuzzer for breadth and SP Fuzzer for depth.
The design principle remains conservative: PoC failure is cheap, but missing a real bug is expensive. The Verifier only rejects SPs when 100% certain they are false positives. The Verifier classifies each SP as either TP (true positive candidate) or FP (false positive). TPs enter a priority queue ordered by importance and score, proceeding to PoC generation with basic guidance. FPs are handled by the fuzzing layer (Section 3.6).
Global Fuzzer. Runs continuously in the background for broad exploration. The Seed Generator produces seeds from two sources: (1) directions—when a direction is created, the generator analyzes the fuzzer entry point and core functions to produce targeted seeds; (2) false positives—SPs that the Verifier determined to be non-exploitable are still “near misses” where the LLM identified suspicious patterns, so we generate seeds to explore these code regions. Crashes discovered by 7
• RQ3 (Ablation Study): How do the different components of FuzzingBrain V2 contribute to its overall effectiveness?
background fuzzer execution (either Global or SP Fuzzer) are directly packaged as vulnerability reports. SP Fuzzer. Activated for each SP during PoC generation, operating in two modes: (1) verification mode—executes each blob generated by the PoC Generator to check if it triggers a crash; (2) background mode—failed PoC attempts are added to the corpus for mutation while the LLM reasons about the next attempt. This parallel execution ensures “the fuzzer mutates while the LLM thinks.”
4
• RQ4 (Zero-day Discovery): Can FuzzingBrain V2 discover previously unknown vulnerabilities in real-world open-source projects?
5.1
Dataset. We evaluate on the C/C++ portion of the AIxCC 2025 Final Challenge dataset (AFC), which contains 40 vulnerabilities across 12 open-source projects including curl, Wireshark, systemd, and libxml2. The dataset includes 20 Full-scan challenges and 20 Delta-scan challenges. Each vulnerability is verified through sanitizer-detected crashes, ensuring ground truth correctness. Baselines. We compare against seven baselines: (1) six AIxCC finalist teams: Team Atlanta (AT, 1st place), Trail of Bits (TB, 2nd), Theori (TI, 3rd), FuzzingBrain V1 (FB, 4th), Shellphish (SP, 5th), and 42-beyond-bugs (42, 6th); (2) Claude Code (CC, Claude-Opus-4.5), a state-of-the-art general-purpose coding agent. For CC, we provide the groundtruth fuzzer-sanitizer pair and allow up to 2 hours of humanin-the-loop interaction per challenge to guide the analysis. Configuration. Each AIxCC challenge specifies multiple fuzzers and sanitizers, and competition teams run parallel workers across all combinations. For our evaluation, we run FuzzingBrain V2 with only the ground-truth fuzzer-sanitizer pair for each challenge, simulating a single-worker configuration. This setup isolates the system’s detection capability from parallelization overhead. We set limits of 120 minutes and $150 for Delta-scan, and 240 minutes and $400 for Full-scan challenges. We fix model tiers as T1: Claude Opus 4.5, T2: Claude Sonnet 4.5, T3: Claude Haiku 4.5. All experiments run on a server with Intel Xeon Platinum 8272CL CPU (48 cores) and 94GB RAM.
Implementation
We implement FuzzingBrain V2 in Python, refactoring and extending our prior work [24] with a distributed worker architecture. Tasks are dispatched through a Redis message queue to parallel worker processes, each handling one fuzzersanitizer pair. MongoDB stores task states, SPs, and vulnerability reports. A separate Analyzer Server process provides code analysis capabilities (call graphs, function extraction, reachability queries) to agents via RPC. Agent Implementation. All agents inherit from a unified BaseAgent class that implements the MCP tool-calling loop: the agent sends a request to the LLM, receives tool calls, executes them via MCP, and returns results to the LLM until it stops. Each agent instance receives an isolated MCP server (via a factory pattern) to prevent state interference during parallel execution. LLM Integration. As shown in Table 1, we use a threetier model configuration with fallback chains: if the primary model fails (rate limit, timeout, or service unavailable), the system automatically retries with alternative models in the same tier. Temperature is set to 0.1 for near-deterministic outputs. Fuzzing Integration. Both Global and SP Fuzzers use libFuzzer with sanitizer instrumentation (ASan, MSan, UBSan). The system monitors fuzzer output for crashes and automatically triggers PoC verification. Evaluation Infrastructure. Real-time monitoring tracks token consumption, execution time, tool invocations, and agent status by querying database state.
5
Experimental Setup
5.2
RQ1: Effectiveness and Efficiency
Figure 7 shows the vulnerability discovery results across all 40 AIxCC challenges. FuzzingBrain V2 discovers 36 out of 40 vulnerabilities, ranking first among all systems. This is 7 more than the AIxCC champion Team Atlanta (29) and 22 more than FuzzingBrain V1 (14), representing a 157% improvement over our previous system. Notably, FuzzingBrain V2 solves 9 out of 12 hard challenges—vulnerabilities that most competition teams failed to discover (see Section 5.3 for hard challenge definition). Claude Code (CC), despite being a general-purpose coding agent, achieves 26 vulnerabilities, demonstrating LLM potential but also the benefit of domain-specific optimization. Table 3 shows detailed per-challenge metrics. For each challenge, SPtot and SPded denote the total and deduplicated
Evaluation
We evaluate FuzzingBrain V2 on the AIxCC 2025 Final Competition dataset and real-world open-source projects. Our evaluation answers the following research questions: • RQ1 (Effectiveness and Efficiency): How effective and efficient is FuzzingBrain V2 at discovering vulnerabilities compared to state-of-the-art approaches? • RQ2 (Complex Case Analysis): How does FuzzingBrain V2 perform on vulnerabilities with deep call chains and complex dependencies? 8
Figure 7: Vulnerability discovery results on the AFC (AIxCC Final Challenge) dataset. Each column represents a challenge (xx-del-xx for Delta-scan, xx-fu-xx for Full-scan). A dot indicates successful PoC generation. Challenges marked with * are high-difficulty vulnerabilities that most teams failed to find. The thick horizontal line separates competition teams (above) from our experimental baselines (below). Σdelta/Σfull show per-mode totals, ΣHard counts high-difficulty challenges solved, and ΣPoC shows overall totals. suspicious points generated; TPv and FP indicate how the Verifier classified them; TPa shows the cumulative discovery count; and By indicates whether the vulnerability was found by the Global Fuzzer (G) or SP-targeted Fuzzer (S). The SP pipeline generated 1,277 suspicious points (1,030 after deduplication). The Verifier classified 96 as TPv and 938 as FP. Of the 36 discovered vulnerabilities, 35 were correctly classified as TPv (recall 97.2%); one (ws1-fu-12) was misclassified as FP but still discovered through FP-generated seeds. This validates our design choice to prioritize recall—false positives are eliminated by the PoV Generator when no crash is triggered, but missed vulnerabilities are hard to recover. Efficiency. Successful Delta-scan challenges average 12 minutes and $19.4, while Full-scan averages 18 minutes and $35.2. The four failed challenges (av2-del-02, ex2-del-01, sd1-fu-05, ss1-fu-04) consumed significant resources before timeout, indicating complex vulnerabilities requiring deeper analysis. Total cost across all 40 challenges was $1,785.60 with 526M tokens.
5.3
SP Fuzzer, not the Global Fuzzer. This highlights the importance of deep exploration capability: while the Global Fuzzer relies on coverage-guided mutation, the SP Fuzzer combines static analysis with dynamic feedback, enabling it to reason about complex call chains and craft inputs that reach deeply nested vulnerable code. We present two case studies that illustrate FuzzingBrain V2’s capability to discover vulnerabilities requiring deep domain knowledge. We select Case A (discovered by 2 of 9 teams) and Case B (discovered only by FuzzingBrain V2). We omit a third case from this analysis—though also uniquely discovered by FuzzingBrain V2—because its vulnerability type and PoV structure are similar to Case B. Figure 8 shows the call stack and PoV structure for each case; Figure 9 shows the exploration progress over iterations. Case A (Leap Second OOB). This vulnerability in a protocol’s timestamp handler triggers only when parsing a response containing a leap second (seconds=60). The bug lies at call depth 10 in a response handler function, where a timestamp lookup array is accessed with index 60 in a 60-element array. The challenge: most leap second timestamps are rejected by the date validation function; only specific historical leap seconds bypass validation. FuzzingBrain V2’s agent discovered this through iterative hypothesis testing—after DAST tools revealed that the vulnerable function was not being reached, the agent systematically tried different historical leap seconds until finding one that worked. Case B (Type Confusion). This vulnerability exploits a protocol bit collision: two protocol constants share the same bit value, allowing an unexpected protocol handler to be reached through the fuzzer. The bug at call depth 7 dereferences an enum value as a pointer. The challenge: reaching the vulnerable code requires (1) discovering the bit collision, (2) implementing correct AES-256-CBC encryption with hard-
RQ2: Complex Case Analysis
As shown in Figure 7, we manually reviewed all 40 challenges and identified 12 hard challenges based on the following criteria: (1) deep call chains with complex dependencies; (2) vulnerabilities masked by other bugs, where triggering the target vulnerability is blocked by earlier crashes; (3) requiring sequential PoC execution to reach the vulnerable code path. We excluded most Wireshark (ws), systemd (sd), and libavif (av) vulnerabilities, as their detection failures stemmed from build process difficulties rather than analysis complexity. FuzzingBrain V2 discovers 9 out of 12 hard challenges (75%), significantly outperforming Team Atlanta (5/12, 42%). Notably, all 9 discovered hard challenges were found by the 9
Table 3: Detailed FuzzingBrain V2 results on AFC dataset. SP = Suspicious Points (Total/Deduplicated). TPv = verifier-confirmed TPs. TPa = actual TPs. By = discovery method (G=Global Fuzzer, S=SP Fuzzer). Challenge
San.
Type
PoC
By
SPtot
SPded
TPv
TPa
FP
Time
Tok.(K)
Cost
OOB-W NPD NPD Stack-OF NPD Fmt-Str OOB-W Heap-OF Stack-OF Heap-OF Arb-W Heap-OF Heap-OF Heap-OF Stack-OF Stack-OF Heap-OF Global-OF Global-OF Heap-OF
✗ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
– S S G S S S – G S S G G S G G G G G G
3 1 10 5 5 6 1 4 0 3 3 4 0 1 1 1 1 1 2 1
3 1 10 5 5 6 1 3 0 3 3 4 0 1 1 1 1 1 1 1
3 1 5 2 4 5 1 2 1 3 3 2 1 1 1 1 1 1 1 1
0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 5 3 1 1 0 2 0 0 0 2 0 0 0 0 0 0 1 0
T/O 3m 1h7m 2m 1h40m 12m 31m T/O 51s 10m 15m 3m 60s 11m 1s 14s 17s 23s 18s 8s
44,363 4,663 31,437 4,358 42,726 9,926 9,142 38,421 57 1,123 4,884 4,645 92 1,759 55 518 454 1,941 2,156 487
$135.05 $23.76 $110.77 $13.34 $130.32 $41.23 $27.79 $118.62 $1.70 $3.71 $14.66 $22.01 $2.80 $5.37 $0.50 $2.18 $1.55 $6.70 $7.24 $1.82
NPD Stack-OF Int-OF Heap-OF Heap-OF NPD Stack-OF DblFree Heap-OF Heap-OF Heap-OF Heap-OF Heap-OF Stack-OF UAF Fmt-Str Heap-OF Buf-OF NPD UAF
✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓
S S S G S G G – G S S G – G G G G G S G
133 171 54 10 9 14 5 487 8 22 22 14 438 5 5 5 5 5 8 56
48 62 12 10 6 10 3 465 5 15 15 9 412 5 5 5 5 5 6 20
7 12 3 4 3 5 2 12 2 5 5 3 14 1 1 1 1 1 5 6
1 2 1 1 2 3 1 4 1 3 4 2 5 2 5 3 1 4 6 1
36 45 5 6 2 4 1 453 2 8 8 5 398 0 0 0 0 0 1 14
1h50m 2h10m 48m 51m 6m 11m 3m T/O 2m 7m 7m 4m T/O 3m 5m 4m 3m 4m 10m 40m
43,984 65,946 7,960 18,119 3,739 4,619 4,713 113,373 1,850 5,680 5,720 3,420 98,752 2,148 2,716 2,168 2,070 2,271 5,842 13,204
$150.38 $227.20 $29.07 $56.78 $14.89 $17.89 $18.22 $379.38 $6.12 $18.75 $18.92 $11.28 $348.65 $10.24 $13.52 $10.78 $10.08 $11.35 $28.65 $44.75
526,403
$1,785.60
Delta-scan Challenges av2-del-02 cu2-del-06 cu3-del-07 cu4-del-03 cu4-del-08 cu5-del-01 cu5-del-02 ex2-del-01 ex3-del-02 fp2-del-02 fp3-del-03 lx3-del-04 mg1-del-01 mg2-del-02 ws1-del-03 ws2-del-04 ws3-del-06 ws4-del-07 ws5-del-08 ws7-del-13
ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN
Full-scan Challenges cm1-fu-01* cm1-fu-02 da1-fu-01* mg1-fu-00* sd1-fu-01* sd1-fu-03 sd1-fu-04 sd1-fu-05 ss1-fu-00* ss1-fu-01 ss1-fu-02 ss1-fu-03 ss1-fu-04 ws1-fu-01* ws1-fu-02 ws1-fu-05 ws1-fu-10 ws1-fu-11 ws1-fu-12 xz1-fu-01* Total
ASAN ASAN UBSAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN ASAN
36/40
*First vulnerability of each Full-scan challenge; same prefix (e.g., cm1-fu-01, cm1-fu-02) = same challenge, shared SP analysis. Metrics are cumulative snapshots at discovery.
10
Figure 8: PoV requirements for two hard challenges. (a) Leap second OOB requires historical timestamp. (b) Type confusion requires protocol bit collision and AES encryption. Both require precise multi-field coordination that random fuzzing cannot achieve.
Figure 9: PoV generation progress. FuzzingBrain V2 progressively deepens while FBv1 and CC remain stuck at shallow depths.
coded key/IV found in source code, and (3) sending an exact trigger string. The agent reversed the encryption scheme by reading the source code and correctly implemented the threephase protocol handshake.
5.4
RQ3: Ablation Study
To understand the contribution of each component, we conduct ablation experiments with the same resource limits as RQ1. Figure 10 shows the results; Table 4 shows the average time per successful discovery. Removing dynamic analysis tools (w/o DAST) reduces detection from 36 to 28, with hard challenge coverage dropping from 9/12 to 1/12. Average time increases (Delta: 25 vs 12 min, Full: 27 vs 18 min) while effectiveness drops significantly. Without execution feedback, agents cannot verify whether target code paths are reached, leaving them stuck at shallow depths. Without verification (w/o Verifier), detection drops from 36 to 30. More critically, average time increases 3× for Deltascan (38 vs 12 min), and most Full-scan tasks timeout due to SP accumulation. Interestingly, one vulnerability (ss1-fu04) was found without the Verifier but missed by the full system—likely due to bypassing a blocking vulnerability that previously prevented reaching the target. Removing directions (w/o Direction) reduces detection from 36 to 29. Delta-scan time remains unchanged (12 min) since Delta-scan does not use the direction generation module. However, Full-scan time increases nearly 3× (48 vs 18 min) due to no priority scheduling—without Core Pool and General Pool, low-priority functions consume PoC Generator resources and cause timeouts. Without the Global Fuzzer (w/o Global Fuzzer), FuzzingBrain V2 achieves 35/40 with 8/12 hard challenges but takes longer (Delta: 24 vs 12 min, Full: 31 vs 18 min). Without the SP Fuzzer (w/o SP Fuzzer), the system is fast (2 min) but
Both cases demonstrate that FuzzingBrain V2 can reason about complex constraints that defeat random fuzzing. Figure 9 shows the exploration progress over iterations. In Case A, FuzzingBrain V2 requires 127 iterations to reach depth 10; DAST enables a breakthrough after iteration 40 by revealing that the vulnerable function was not being reached. In Case B, FuzzingBrain V2 requires 108 iterations to reach depth 7; DAST at iteration 50 helps the agent discover the protocol bit collision and reverse the AES encryption. In both cases, FBv1 and Claude Code remain stuck at shallow depths (2–5), unable to reason about the complex constraints required to reach the vulnerable code. These case studies demonstrate FuzzingBrain V2’s deep vulnerability detection capability. Through MCP-based tool invocation, agents autonomously leverage both static analysis (to understand code structure, trace data flow, and identify constraints) and dynamic analysis (to obtain concrete execution feedback and verify hypotheses). This combination enables systematic exploration of complex input constraints that neither traditional fuzzing nor standalone LLM agents can achieve. The three unsolved hard challenges reveal FuzzingBrain V2’s limitations: one requires simultaneous multi-input attacks unsupported by our architecture; one triggered a similar shallower bug causing premature worker termination; and one involves an implicit state machine our static analysis could not reconstruct. 11
Figure 10: Ablation study results. Stars indicate vulnerabilities found by ablation configurations but missed by FuzzingBrain V2 (full). achieves only 19/40 with zero hard challenges. This confirms that LLM-guided SP exploration is essential for complex vulnerabilities, while background fuzzing provides broad but shallow coverage.
Table 5: Zero-day vulnerabilities discovered by FuzzingBrain V2. Project
Table 4: Average time per successful vulnerability discovery. Configuration FuzzingBrain V2 (full) w/o DAST w/o Verifier w/o Direction w/o Global Fuzzer w/o SP Fuzzer
Delta (min)
Full (min)
12 25 38 12 24 2
18 27 T/O* 48 31 2
* Most Full-scan tasks timeout due to SP accumulation; not
statistically meaningful.
Lang. Found Submitted Confirmed* Fixed
OpenPrint CUPS C bluez C fwupd C upx C++ avro Java/C pdfbox Java imagemagick C V2xHub C++ busybox C cjson C flatbuffers C++ jq C MongoDB C++ mongoose C njs C openldap C paddle C++ simdutf C++ tcpreplay C
6 5 4 4 3 3 2 2 2 1 1 1 1 1 1 1 1 1 1
6 5 4 4 3 3 2 2 2 1 1 1 1 1 1 1 1 1 1
6 0 4 4 3 0 2 0 0 0 0 1 1 1 1 0 1 1 1
6 0 4 4 3 0 2 0 0 0 0 0 0 1 1 0 1 1 0
Total
41
41
26
23
–
* Acknowledged by maintainers with issue tracking.
5.5
Table 5 summarizes the results. FuzzingBrain V2 discovered 41 previously unknown vulnerabilities across 19 projects. Our deployment began in early 2026 and is still in its initial stage; as of submission, 26 have been confirmed (acknowledged by maintainers with issue tracking) and 23 have been fixed. Although this paper focuses on C/C++ evaluation, FuzzingBrain V2 can also handle Java projects through OSS-Fuzz’s Jazzer integration. While we did not implement Java-specific optimizations (as we did for C), we included Java targets (avro, pdfbox) in our deployment and successfully discovered vulnerabilities. We did not request CVE assignments from developers, as our collaboration with open-source projects is directly reported to DARPA for verification. Nevertheless, some
RQ4: Zero-day Discovery
To evaluate FuzzingBrain V2’s real-world applicability, we deployed the system on OSS-Fuzz projects and collaborative targets from our lab partnerships. Each project was allocated a $200 budget, adjusted based on the number of fuzzers available. All targets are either directly from OSS-Fuzz or adapted to the OSS-Fuzz infrastructure. 12
6
maintainers proactively applied for CVEs—for example, ImageMagick vulnerabilities were assigned CVE-2026-23874 and CVE-2026-23952.
6.1
Notable discoveries include 6 vulnerabilities in OpenPrint CUPS, and 4 each in fwupd and upx. These projects are mature and well-fuzzed, yet FuzzingBrain V2’s semantic analysis identified vulnerabilities in code paths that traditional fuzzers had not explored.
Discussion Limitations
Despite achieving 90% detection rate (36/40) on the AFC benchmark, FuzzingBrain V2 has notable limitations. Multi-input vulnerabilities. FuzzingBrain V2’s architecture assumes a single-input fuzzing model, where one PoC triggers one vulnerability. However, some vulnerabilities require coordinated multi-input attacks—for example, sending a malformed request that corrupts state, followed by a normal request that triggers the crash. Our current SP model cannot represent such temporal dependencies. Implicit state machines. When program behavior depends on implicit state transitions not reflected in the source code (e.g., protocol handlers with undocumented modes), our static analysis fails to reconstruct the necessary preconditions. The agent may repeatedly generate inputs that are rejected by state validation, unable to discover the correct sequence. Shallow bug masking. When a shallower bug exists on the path to a deeper vulnerability, FuzzingBrain V2 may terminate exploration prematurely. Although the Verifier attempts to filter duplicate crashes, semantically similar bugs with different root causes can still cause early termination. Build and environment complexity. Several AFC challenges failed not due to analysis limitations but due to build process difficulties. Complex build systems, missing dependencies, or environment-specific configurations can prevent FuzzingBrain V2 from successfully instrumenting and running the target. Context management. Our current context compression strategy is simplistic, causing significant information loss during summarization. As a result, agents may repeatedly analyze the same functions across iterations, leading to redundant API calls and increased costs. More sophisticated context management—such as hierarchical summarization or retrieval-augmented memory—could reduce this overhead.
Figure 11 shows the distribution of vulnerability types. NULL pointer dereferences (7) and heap buffer overflows (6) are the most common, followed by memory leaks (5) and denial-of-service vulnerabilities (5). This distribution closely mirrors the AFC benchmark dataset, suggesting that FuzzingBrain V2’s detection capabilities generalize well to real-world scenarios.
Figure 11: Distribution of vulnerability types.
Case Study: Write-Before-Check in Project A. Project A is a mature Unicode processing library (1,700+ stars, no vulnerabilities reported in six months). FuzzingBrain V2 discovered a heap-buffer-overflow caused by a “write-before-check” pattern in the UTF-16 to UTF-8 conversion. Why traditional fuzzing missed it. The existing OSS-Fuzz harness targets the standard conversion API, which internally allocates a sufficiently large output buffer. The vulnerable code path is only reachable through the _safe() variant, which accepts a user-provided buffer with explicit size constraints.
6.2
Future Work
Multi-language support. While FuzzingBrain V2 currently focuses on C/C++ with limited Java support through Jazzer, extending to other languages (Rust, Go, Python) would broaden applicability. Each language requires adapting the static analysis pipeline and integrating appropriate sanitizers. Context management. Adopting retrieval-augmented memory or hierarchical context summarization could significantly reduce redundant analysis and lower operational costs. Techniques from long-context LLM research may also help agents maintain coherent analysis across extended sessions. Patch generation. A natural extension is automatic patch generation for discovered vulnerabilities. The agent already understands the root cause through PoC generation; generating and validating fixes would complete the vulnerability
How FuzzingBrain V2 found it. The Direction agent flagged _safe() functions as high-priority, reasoning that safetycritical wrappers often hide edge cases. The SP Fuzzer generated a targeted harness that supplies minimal output buffers. Within 12 minutes, the verifier confirmed a heap overflow: the ASCII fast-path optimization writes output bytes before checking buffer bounds, causing overflow when triggered near the boundary. The maintainers fixed the bug within one week and sent a letter of appreciation. 13
lifecycle. Binary reproduction. Currently FuzzingBrain V2 requires source code for instrumentation. Supporting binary-only targets through emulation-based fuzzing (e.g., QEMU, Unicorn) would enable analysis of closed-source software and firmware.
7
Conclusion
We presented FuzzingBrain V2, a multi-agent system that combines LLM-driven semantic analysis with coverageguided fuzzing for automated vulnerability discovery. By introducing the Suspicious Point abstraction, FuzzingBrain V2 enables systematic exploration of potentially vulnerable code while avoiding the infinite search space problem that plagues pure LLM approaches. On the AFC benchmark, FuzzingBrain V2 detected 36 of 40 vulnerabilities (90%), including 9 of 12 hard challenges requiring deep semantic understanding. In real-world deployment across 19 OSS-Fuzz projects, FuzzingBrain V2 discovered 41 previously unknown vulnerabilities, of which 26 have been confirmed and 23 fixed by maintainers. Our results demonstrate that LLM agents can effectively guide vulnerability discovery when grounded by concrete execution feedback and structured by well-defined analysis abstractions. We hope FuzzingBrain V2 inspires further research at the intersection of program analysis and large language models.
14
References
[11] Hazim Hanif and Sergio Maffeis. VulBERTa: Simplified source code pre-training for vulnerability detection. In 2022 International Joint Conference on Neural Networks (IJCNN), pages 1–8. IEEE, 2022.
[1] Anthropic. Model context protocol. Anthropic, 2024. https://modelcontextprotocol.io/.
[12] Larry Huynh, Yinghao Zhang, Djimon Jayasundera, Woojin Jeon, Hyoungshick Kim, Tingting Bi, and Jin B. Hong. Detecting code vulnerabilities using LLMs. In 2025 55th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2025.
[2] Pavel Avgustinov, Oege de Moor, Michael Peyton Jones, and Max Sheridan. QL: Object-oriented queries on relational data. In European Conference on ObjectOriented Programming, pages 2–27. Springer, 2016. [3] Cristiano Calcagno, Dino Distefano, Peter W. O’Hearn, and Hongseok Yang. Compositional shape analysis by means of bi-abduction. In Proceedings of the 36th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 289–300. ACM, 2009.
[13] Ahmed Lekssays, Hamza Mouhcine, Khang Tran, Ting Yu, and Issa Khalil. LLMxCPG: Context-aware vulnerability detection through code property graph-guided large language models. In 34th USENIX Security Symposium. USENIX Association, 2025.
[4] CISA and NSA. Memory safe languages: Reducing vulnerabilities in modern software development. Cybersecurity Information Sheet, 2025. https://media.de fense.gov/2025/Jun/23/2003742198/-1/-1/0/C SI_MEMORY_SAFE_LANGUAGES.PDF.
[14] Yue Li, Xiao Li, Hao Wu, Minghui Xu, Yue Zhang, Xiuzhen Cheng, Fengyuan Xu, and Sheng Zhong. Everything you wanted to know about LLM-based vulnerability detection but were afraid to ask. arXiv preprint arXiv:2504.13474, 2025.
[5] Roland Croft, Yusuf Newaz, Ziqi Chen, and Muhammad Ali Babar. IRIS: LLM-assisted static analysis for detecting security vulnerabilities. In arXiv preprint arXiv:2405.17238, 2024.
[15] Zhen Li, Deqing Zou, Shouhuai Xu, Xinyu Ou, Hai Jin, Sujuan Wang, Zhijun Deng, and Yuyi Zhong. VulDeePecker: A deep learning-based system for vulnerability detection. In Proceedings of the 2018 Network and Distributed System Security Symposium (NDSS). Internet Society, 2018.
[6] DARPA. AIxCC: Artificial intelligence cyber challenge. DARPA Program, 2025. https://aicyberchallen ge.com/.
[16] libpng Development Team. libpng: The official PNG reference library. libpng.org, 2024. http://www.libp ng.org/pub/png/libpng.html.
[7] Yinlin Deng, Chunqiu Steven Yang, Chaoyu Wei, Jiayi Yao, Jiawei Liu, and Lingming Zhang. LLM-assisted fuzz driver generation for OSS-Fuzz. In arXiv preprint arXiv:2312.02632, 2024.
[17] LLVM Project. libFuzzer: A library for coverage-guided fuzz testing, 2015. https://llvm.org/docs/LibFuz zer.html.
[8] Yangruibo Ding, Yanjun Fu, Omniyyah Ibrahim, Chawin Sitawarin, Xinyun Chen, Basel Alomari, David Wagner, Baishakhi Ray, and Yizheng Chen. Vulnerability detection with code language models: How far are we? In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering (ICSE). ACM, 2024.
[18] Jeremiah Lowin. FastMCP: The fast, pythonic way to build MCP servers and clients. GitHub, 2024. https: //github.com/jlowin/fastmcp. [19] Matt Miller. A proactive approach to more secure code. Microsoft Security Blog, 2019. https://msrc.micro soft.com/blog/2019/07/a-proactive-approac h-to-more-secure-code/.
[9] Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, and Ming Zhou. CodeBERT: A pretrained model for programming and natural languages. In Findings of the Association for Computational Linguistics: EMNLP 2020, pages 1536–1547. ACL, 2020.
[20] Van Nguyen, Trung Le, Navid Ahmadi, Lizhen Huynh, Dinh Phung, and Anwarul Haque. GRACE: Empowering LLM-based software vulnerability detection with graph structure and in-context learning. In Journal of Systems and Software, volume 212, page 112031. Elsevier, 2024.
[10] Mohamed Amine Ferrag, Fatima Alwahedi, Ammar Battah, Bilel Cherif, Abdechakour Mechri, Norbert Tihanyi, Tamas Bisztray, and Merouane Debbah. Generative AI in cybersecurity: A comprehensive review of LLM applications and vulnerabilities. Internet of Things and Cyber-Physical Systems, 5:100082, 2025.
[21] Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh. Do users write more insecure code with AI assistants? In Proceedings of the 2023 ACM SIGSAC 15
[32] Chenyuan Yang, Zijie Zou, and Lingming Zhang. KernelGPT: Enhanced kernel fuzzing via large language models. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, 2024.
Conference on Computer and Communications Security, pages 2785–2799. ACM, 2023. [22] Kostya Serebryany. OSS-Fuzz: Google’s continuous fuzzing service for open source software. In USENIX Security Symposium, 2017.
[33] Michał Zalewski. American Fuzzy Lop: A securityoriented fuzzer. Google, 2014. https://lcamtuf.co redump.cx/afl/.
[23] Ze Sheng, Zhicheng Chen, Shuning Gu, Heqing Huang, Guofei Gu, and Jeff Huang. LLMs in software security: A survey of vulnerability detection techniques and insights. ACM Computing Surveys, 58(5), 2025.
[34] Xueying Zhang, Jiongyi Zhang, Zhengyang Su, Yanlin Chen, Shiyu Xu, Zhi Lin, Lianxiao Tan, Yichi Guo, Yuqun Gu, and Shuiguang Deng. Vul-RAG: Enhancing LLM-based vulnerability detection via knowledge-level RAG. In arXiv preprint arXiv:2406.11147, 2024.
[24] Ze Sheng, Qingxiao Xu, Jianwei Huang, Matthew Woodcock, Heqing Huang, Alastair F. Donaldson, Guofei Gu, and Jeff Huang. All you need is a fuzzing brain: An llmpowered system for automated vulnerability detection and patching, 2025.
[35] Xin Zhou, Sicong Cao, Xiaobing Sun, and David Lo. Large language model for vulnerability detection and repair: Literature review and the road ahead. ACM Transactions on Software Engineering and Methodology, 34:1–31, 2024.
[25] Yuqiang Sun, Daoyuan Wu, Yue Xue, Han Liu, Wei Ma, Lyuye Zhang, Yang Shi, and Yang Liu. LLM4Vuln: A unified evaluation framework for decoupling and enhancing LLMs’ vulnerability reasoning. In arXiv preprint arXiv:2401.16185, 2024.
[36] Yaqin Zhou, Shangqing Liu, Jingkai Siow, Xiaoning Du, and Yang Liu. Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks. In Advances in Neural Information Processing Systems, volume 32, 2019.
[26] The Chromium Projects. Memory safety. Chromium Security Documentation, 2020. https://www.chromi um.org/Home/chromium-security/memory-safet y/. [27] Zhiyuan Wei, Jing Sun, Yuqiang Sun, Ye Liu, Daoyuan Wu, Zijian Zhang, Xianhao Zhang, Meng Li, Yang Liu, Chunmiao Li, Mingchao Wan, Jin Dong, and Liehuang Zhu. Advanced smart contract vulnerability detection via LLM-powered multi-agent systems. IEEE Transactions on Software Engineering, 51(10):2830–2846, 2025.
A
[28] Wiz Research. MongoBleed: Critical MongoDB vulnerability CVE-2025-14847. Wiz Blog, 2025. https: //www.wiz.io/blog/mongobleed-cve-2025-148 47-exploited-in-the-wild-mongodb. [29] Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. Fuzz4All: Universal fuzzing with large language models. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering (ICSE). ACM, 2024. [30] Fabian Yamaguchi, Nico Golde, Daniel Arp, and Konrad Rieck. Modeling and discovering vulnerabilities with code property graphs. In 2014 IEEE Symposium on Security and Privacy, pages 590–604. IEEE, 2014. [31] Chenyuan Yang, Yinlin Deng, Runyu Lu, Jiayi Yao, Jiawei Liu, Reyhaneh Jabbarvand, and Lingming Zhang. WhiteFox: White-box compiler fuzzing empowered by large language models. In Proceedings of the ACM on Programming Languages, volume 8, pages 1–27. ACM, 2024. 16
Agent Prompts
Direction Generator Prompt (Abridged) You are a security architect analyzing a codebase to find vulnerabilities. Background -- Divide codebase into logical "directions" based on BUSINESS LOGIC for independent analysis. CRITICAL: Understanding Your Constraints -- FUZZER determines reachability; SANITIZER determines detectability. Static call graph misses function pointer calls. Your Mission 1. Read the fuzzer source code FIRST • Understand what the fuzzer is testing (its PURPOSE) • Identify what data format/protocol it processes (its TARGET) • List the business functions it exercises (its SCOPE) 2. Divide by BUSINESS LOGIC, not vulnerability type • Each direction should represent a logical feature or sub-feature • Think: "What different things does this code DO?" • NOT: "What types of bugs might exist?" 3. Create directions for each business area • Assign risk levels based on input proximity and complexity • Ensure full coverage of reachable functions What is a Direction? A direction is a logical grouping of functions that handle ONE BUSINESS FEATURE. GOOD direction names (business logic oriented): • Named after WHAT the code DOES (a specific feature or sub-feature) • Represents a complete logical unit of functionality • Can be understood without security knowledge BAD direction names (DO NOT DO THIS): • "Memory Management" (too generic, crosses all features) • "Input Parsing" (too vague, every feature parses input) • "Buffer Operations" (this is a vulnerability pattern, not a business) Security Risk Assessment -- HIGH: direct untrusted input parsing. MEDIUM: validated data processing. LOW: minimal input dependency. Available Tools -- get_function_source, get_callers, get_callees, get_call_graph, get_reachable_functions, get_unreached_functions, search_code, create_direction. CRITICAL: Function Pointer Reachability -- Static analysis cannot track indirect calls. Must actively discover patterns: struct members holding function pointers, callbacks, handler dispatch. These are HIGH VALUE targets. Workflow -- (1) Read fuzzer source. (2) Get reachable functions. (3) Discover indirect call patterns. (4) Identify business features. (5) Create directions with name, risk_level, core_functions, entry_functions. Important Guidelines -- Max 5 directions. Full coverage including pointer-reachable functions. Prioritize HIGH RISK first.
Figure 12: Direction Generator Prompt (abridged; full prompt available in supplementary material)
17
SP Generator Prompt (Abridged) You are a vulnerability hunter. Your job is to FIND suspicious code patterns. Your Role: Initial Screening -- You are the FIRST PASS - an expert Verify Agent will review every SP you create. You don’t need to be 100% certain or fully verify reachability. Key Principle: It’s better to report a potential issue and be wrong, than to miss a real bug because you talked yourself out of it. Your Constraints • Fuzzer: Only code reachable from this fuzzer matters • Sanitizer: Only bugs this sanitizer can detect matter – AddressSanitizer: buffer overflow, OOB, use-after-free, double-free – MemorySanitizer: uninitialized memory read – UndefinedBehaviorSanitizer: integer overflow, null deref, div-by-zero When to Create an SP • CREATE: Dangerous pattern + input influence + uncertain protection • DON’T skip just because there’s a bounds check nearby (it might be wrong) Confidence Scores -- 0.6-1.0: Clear pattern. 0.4-0.6: Suspicious. 0.3-0.4: Worth checking. Only skip if < 0.3. Available Tools -- get_function_source, get_callers, get_callees, search_code, create_suspicious_point. SP Format -- Describe using control flow, not line numbers: “In function X, when processing Y, the length parameter flows to memcpy without bounds check.” Remember -- Report first, let experts verify. Better to report 10 SPs with 3 real bugs than to report 2 SPs and miss 1 real bug.
Figure 13: SP Generator Prompt (abridged; full prompt available in supplementary material)
SP Verifier Prompt (Abridged) You are a security researcher filtering out obviously wrong suspicious points. Your Role: FILTER, Deep Verify -- Filter out wrong SPs through in-depth analysis (truly unreachable, wrong sanitizer type). Let uncertain cases PASS to PoC agent for actual testing. PoC failure is cheap; missing a real bug is expensive. Key Principle: When in doubt, let it through. Only mark FP when you are 100% certain. Function Pointer Reachability -- Static analysis may mark functions as “unreachable” when they are actually called via function pointers. Check for: struct method dispatch, callback functions, handler patterns. If function pointer pattern found, the function IS reachable. Strict False Positive Rules -- Only mark FP when: • TRULY UNREACHABLE: No direct call AND no function pointer pattern • WRONG SANITIZER: Bug type incompatible with sanitizer • 100% CERTAIN protection exists (bounds checks can be wrong!) Verification Steps -- (1) Check static reachability. (2) Check function pointer patterns if static says unreachable. (3) Verify sanitizer compatibility. (4) Analyze source code. (5) Make judgment. PoC Guidance -- When passing to PoC agent, provide brief guidance: what input to generate, how to reach the vulnerable code. Available Tools -- get_function_source, get_callers, get_callees, search_code, update_suspicious_point.
Figure 14: SP Verifier Prompt (abridged; full prompt available in supplementary material)
18
PoC Generator Prompt (Abridged) You are a security researcher generating POV (Proof of Vulnerability) inputs to trigger a specific vulnerability. Your Task -- Generate binary input (blob) that triggers the identified vulnerability and causes a sanitizer-detectable crash. Target Configuration • Fuzzer: Defines the INPUT FORMAT your blob must match • Sanitizer: Defines what CRASH TYPES can be detected (ASan: buffer overflow, UAF; MSan: uninitialized read; UBSan: integer overflow, null deref) Workflow -- (1) UNDERSTAND: Read vulnerable function, trace data flow from fuzzer input. (2) DESIGN: Plan what bytes trigger the vulnerability. (3) CREATE: Write generator code that produces 3 DIFFERENT blob variants. (4) VERIFY: Test each blob, iterate if no crash. Generator Code Format -- Your generate(variant) function receives variant number (1, 2, or 3). Return DIFFERENT blobs for each variant. Available Tools -- get_function_source, get_file_content, get_callers, get_callees, search_code, create_pov, verify_pov, trace_pov (available after 15 attempts). Tips -- Read fuzzer source FIRST. Each variant should try a different approach. Start simple, add complexity. If verify fails, analyze output and adjust. Limits -- Max 40 create_pov calls. Each attempt generates 3 variants. trace_pov available after 15 attempts. Stop when crashed=True.
Figure 15: PoC Generator Prompt (abridged; full prompt available in supplementary material)
19