1.1. POV and Patch Generation

In AIxCC, participants are tasked with building autonomous vulnerability detection and patching systems that operate effectively on real-world open-source projects. These systems must fulfill two critical requirements: (1) automatically generate Proofs-of-Vulnerability (POVs), and (2) produce patches in the form of diff files that remediate the discovered issues.

Proof-of-Vulnerability (POV). Given a target software that contains one or more vulnerabilities (either seeded by AIxCC or zero-days), for each vulnerability, generate an input that triggers a sanitizer error when processed by a fuzzer harness. AIxCC targets vulnerabilities in C and Java projects, and it uses OSS-Fuzz (oss, [n. d.])-compatible fuzzers, such as libFuzzer and AFL for C projects, and Jazzer for Java projects, to prove a vulnerability. For C projects, the software can be compiled using various sanitizers: AddressSanitizier, MemorySanitizer, and Undefined-BehaviourSanitizer.

where $H$ represents a collection of fuzzer harnesses, $S$ is the target software, and $h\in H$ is a fuzzer harness, $san$ a sanitizer type, and $I$ a sanitizer-error triggering input. The generated POV serves as concrete evidence of the vulnerability’s exploitability and also provides a test case for patch validation.

These requirements provide a degree of confidence that patches not only remove vulnerabilities but also preserve intended functionality, minimizing the introduction of regressions.

Importantly, when the patches submitted by a team are evaluated, the set POVs for a vulnerability is taken to be the union of valid proofs submitted for the vulnerability across all teams. Therefore, to be valid, it is not enough for a team’s patch to simply eliminate the POVs discovered by the team; the patch must be general enough to work for POVs discovered by other teams as well.

Using the diff format for patches enables seamless integration with existing version control systems and open-source development workflows, facilitating review and maintainability.

1.2. Three Challenge Modes

To address diverse vulnerability management scenarios in real-world software development, AIxCC defines three distinct challenge modes that participating systems shall support: Delta-Scan, Full-Scan, and Static Analysis Report-Based (SARIF (Fanning and Golding, 2023)). Each mode corresponds to a different class of inputs and evaluation tasks.

1.3. Competition Scoring

POV (VDS): $2\times\tau$ if crash, else $0$

Patch (PRS): $6\times\tau$ if valid, else $0$

SARIF Assessment (SAS): $1\times\tau$ if correct, else $0$

Bundle Score (BDL): $1\times\tau$ if valid, else $0$

AIxCC had a total number of 60 challenges in the final round. Each challenge score is the sum of valid POV, patch, SARIF assessment, and bundle points, scaled by an accuracy multiplier. Each valid POV earns 2 points, patch 6 points, and SARIF assessment 1 point, all decaying over time to a 50% minimum. In addition, bundle points (BDL) are awarded for grouped submissions. Details can be found in the AIxCC final scoring guide (aix, 2025).

2.1. Task Decomposition

Figure 2 illustrates the workflow for decomposing and distributing tasks across FuzzingBrain’s services. Upon receiving a task (which contains metadata describing the challenge, e.g., a delta-scan or a full-scan of a target project), the CRS Web Service first builds the target project and its fuzzers using OSS-Fuzz utilities. Each fuzzer is an executable binary generated from a fuzzer harness instrumented with a sanitizer (AddressSanitizer, MemorySanitizer, or UndefinedBehaviorSanitizer for C/C++¹¹1FuzzingBrain also supports C++, besides C and Java projects., and Jazzer for Java).

The service then prepares isolated workspaces by cloning the target repository, constructing project-specific Docker containers, and generating fuzzer binaries for all supported sanitizer configurations. A single project may yield dozens of fuzzers: for example, dropbear contains 17 fuzzer harnesses, each compiled with three sanitizers, producing more than 50 binaries.

All fuzzers are distributed across the Worker Services to enable concurrent execution. To minimize communication overhead, only the fuzzer path (fuzzer name and sanitizer type) is sent to a worker. The corresponding binary and Docker image are reconstructed locally on the worker node.

In parallel, the task is also dispatched to the Static Analysis Service and the Submission Service. The former conducts program analysis, while the latter manages bookkeeping for POV and patch submissions.

2.2. Libfuzzer and LLM-based Fuzzing

Upon receiving a target fuzzer, a Worker Service first builds the corresponding fuzzer binary, and then proceeds to generate POV inputs and patches specific to that fuzzer. Both traditional fuzzing and LLM-powered fuzzing are performed on the same file system to discover inputs that can trigger sanitizer errors. Each fuzzer executes inside a Docker container with all required runtime dependencies.

The traditional fuzzing setup is intentionally minimal: we rely solely on libFuzzer, whose fuzzing corpus is configured to reside in a shared directory accessible by the LLM-based fuzzing strategies. All LLM-based strategies execute in parallel, and the inputs they generate that do not immediately trigger crashes are preserved in the shared corpus. These inputs are often close to valid crash-inducing cases and therefore serve as valuable seeds for libFuzzer. Since the parallel strategies can generate a very large number of test inputs per second, the shared corpus directory is periodically cleaned to prevent uncontrolled growth. Rather than performing libFuzzer’s built-in corpus minimization, our approach removes files based on age: any input older than 10 minutes is deleted. This lightweight policy keeps the corpus size manageable while still allowing recently generated inputs (which are more likely to be relevant) to contribute to subsequent fuzzing iterations.

For each LLM-based fuzzing strategy, the Worker Service spawns a dedicated Python subprocess. Once a POV is identified, the workflow transitions to the patching phase, where multiple patching processes are launched in parallel.

FuzzingBrain currently incorporates 23 distinct LLM-based strategies (10 for POV and 13 for patches), categorized by their operational mode and target language focus, as summarized in Table 2. Each strategy executes in an independent process but adheres to a unified interface for receiving task specifications and returning results in a consistent format. Further details of our LLM-based POV generation and patching strategies are presented in Sections 3 and 4, respectively.

2.3. XPatch without POV

For certain complex challenges, generating POVs may be infeasible within the competition timeframe. To handle such cases, we developed XPatch, a strategy that attempts to produce patches even when no POV has been found. XPatch is triggered only after half of the competition time has elapsed without a successful POV. According to the competition rules, such patches can still earn credit as long as they remediate the introduced vulnerability and do not regress against any known POVs. A detailed discussion of XPatch is provided in Section 4.7.

2.4. Static Analyses

Upon receiving a task, the Static Analysis Service performs whole-program static analysis of the target project and supports three types of queries from Worker Services: (1) Function Metadata—given a function name and an optional file name or path, return all matching functions along with their metadata, including parameters and source code; (2) Reachability—given a fuzzer harness, identify all functions reachable from its entrypoint, returning each function’s name, file path, and start/end line numbers; (3) Call Paths—given a fuzzing harness and a target function, enumerate call paths from the fuzzer entrypoint to the target. Each call path comprises an ordered sequence of functions, including their file paths, names, and line ranges. To mitigate path explosion, we cap the number of call paths at 20, returning the first 20 if more exist. We also enforce a maximum call path depth (default: 50 for C/C++ and 10 for Java) to avoid excessively long paths. These defaults were chosen heuristically based on empirical observations from the exhibition rounds: in C/C++ projects, vulnerabilities are often buried deep within complex call chains, making a higher threshold useful, whereas in Java projects, exploitable issues are typically exposed through shorter, higher-level entrypoints, so a smaller depth bound is sufficient in practice.

Developing static analysis tools for real-world projects proved to be both challenging and time-consuming. We encountered numerous performance and soundness issues, ultimately leading us to build two customized static analysis frameworks: one for C/C++ and one for Java. We present further details in Section 6.

2.5. Submission Deduplication

The Submission Service receives all POV and patch submissions from Worker Services and applies several mechanisms to eliminate duplicates. Deduplication is essential because redundant submissions reduce the accuracy multiplier.

For POV submissions, each entry is accompanied by a signature, defined as the crash location (source file and line number) extracted from the crash call stack. If the crash location is unavailable, heuristics are applied to construct a signature from the crash output and sanitizer. Two POVs are considered duplicates if they share the same signature. However, distinct signatures may still correspond to the same underlying vulnerability. To capture such cases, we employ LLM-based comparison: crash reports from two POVs are provided as input to three different LLMs, and the submissions are marked as duplicates if at least two of the models consider them redundant.

Patch submissions require a different strategy, since multiple distinct patches may be valid attempts for the same vulnerability, and some patches may fail during validation. Deduplication is therefore applied more conservatively, using three rules: (1) If two patch diffs are highly similar, we compute their Levenshtein distance and discard duplicates with a distance below 10. (2) If two patches are submitted within a short interval (3 seconds) and correspond to the same POV signature, the second of the two patches is discarded. (3) We cap the number of patch submissions per vulnerability at five.

For XPatch, where no POV is available, we assume that each task corresponds to a single introduced vulnerability. In this case, the canonical signature is derived from the task itself, and the submission cap is stricter: at most three XPatches are allowed per task.

2.6. SARIF Assessment

For each SARIF broadcast, FuzzingBrain performs validation through LLM-based assessment and leverages the information for POV generation when appropriate. If a SARIF report is deemed valid and no POV has yet been discovered for the corresponding vulnerability, the CRS Web Service forwards the SARIF to Worker Services to guide POV generation. We present further details in Section 5.

2.7. Bundle Creation

Each bundle groups together two or more items (POV, patch, and/or SARIF broadcast) that correspond to the same underlying vulnerability. In our approach, to enable consistent grouping, we associate each vulnerability with a canonical signature, defined as the signature of the first submitted POV. Patch submissions may also include an optional pov_signature when the patch is explicitly derived from a known POV.

2.8. Technology Stack

As illustrated in Figure 2, FuzzingBrain is implemented primarily in two programming languages: Go and Python. For the CRS services, we selected Go with the Gin web framework. This choice reflects Go’s strengths in efficiently handling large numbers of concurrent operations and its mature ecosystem for building high-performance, production-grade web services.

In contrast, all LLM-based POV and patching strategies are implemented as independent Python modules. Python was chosen due to its rich ecosystem for LLM development and its extensive set of third-party libraries, which allow rapid prototyping and flexible experimentation. Each strategy module can execute independently, enabling modularity and isolation.

Finally, for model routing, we developed a custom framework for model selection, routing, and fallback. Existing off-the-shelf solutions were found to be unreliable and prone to errors under competition workloads (e.g., failing to handle high request volume, rate limits, server overloaded, etc). To enhance robustness against individual model failures or limitations, our framework employs a multi-model fallback mechanism. The system maintains a prioritized list of models, including those from Anthropic, Google, and OpenAI. When invoking an LLM, the framework attempts models in the predefined order; if one becomes unavailable or encounters an error, the request is automatically redirected to the next available model in the list. This design ensures continuity of service and minimizes disruptions during critical operations.

2.9. Parallelization

A central design principle of FuzzingBrain is parallelization: every component that can be parallelized is parallelized, in order to maximize the speed of vulnerability discovery and patch generation.

This large-scale parallelization enables simultaneous processing of multiple challenges while maintaining high resource utilization and system throughput. The result is an architecture capable of scaling efficiently under heavy workloads, ensuring both rapid vulnerability detection and timely patch generation.

3.1. Base Strategies

FuzzingBrain implements a baseline strategy (xs0_delta) for delta-scans, as illustrated in Figure 3. This strategy establishes core prompting and feedback patterns that most other strategies inherit and extend.

The approach operates entirely via multi-turn, text-based dialogue with LLMs, cleanly decoupling analysis logic from the execution environment.

3.2. Advanced Strategies

The as0_delta strategy introduces several enhancements over the base approach to improve vulnerability discovery effectiveness. The primary differences among strategies are summarized in Table 3 and Table 4. In this section, we highlight advanced modules that extend the base strategy; different strategies compose these modules in different combinations.

Multi-Input Generation. Unlike the base strategy, which produces a single test case per iteration, as0_delta generates multiple candidates. Each LLM interaction emits a Python script that creates five binary inputs (x1.bin–x5.bin), yielding five exploitation opportunities per iteration instead of one.

Modified-Function Context Injection. Beyond the commit diff, we identify all modified files and functions and append the full source of each modified function to the prompt to provide precise context. To stay within model context limits and emphasize salient code, we cap the injected source at 2,000 lines per function.

Call-Path–Based Analysis. This module queries the Static Analysis Service for call paths from the fuzzer entrypoint to all modified (and thus potentially vulnerable) functions. For each call path, the system crafts a targeted prompt asking the LLM to generate an input that exercises that path, steering toward code regions likely to trigger the vulnerability. We limit the number of call paths to 20. If all per-path attempts fail, a final aggregated prompt combines all paths for one last POV-generation attempt.

3.3. Full-Scan Strategies

For full-scan scenarios, where no commit diff is available, FuzzingBrain employs a set of strategies that analyze the entire codebase to identify potentially vulnerable functions.

Call Graph–Based Analysis. The xs0_c_full and
xs0_java_full strategies employ static analysis to narrow the search space prior to applying LLM-based vulnerability detection. Specifically, they query the Static Analysis Service to enumerate functions reachable from fuzzer entrypoints. This pruning step typically reduces the candidate set from thousands of functions to a more tractable subset of reachable targets.

LLM-Based Vulnerable Function Ranking. Once reachable functions are extracted, LLMs are used to score and rank them based on their likelihood of containing vulnerabilities. The ranking incorporates language-specific vulnerability patterns tailored to C/C++ and Java.

Enhanced Full-Scan Strategies. The xs1_c_full,
xs1_java_full, and xs2_java_full strategies extend the baseline full-scan approach with more refined call graph construction, advanced ranking heuristics, and specialized vulnerability pattern recognition for their respective languages.

Advanced Full-Scan Integration. The as0_full strategy integrates all of the above modules (static call graph analysis, LLM-based ranking, and advanced vulnerability heuristics) into a unified workflow for large-scale vulnerability discovery across entire codebases.

4.1. Patch Validation Criteria

4.2. Basic Patch Strategy

Table 5 shows a high-level comparison of the patching strategies. The baseline strategy, patch_delta, operates through multi-turn LLM-driven conversations, similar to the POV generation process. In each iteration, the LLM proposes a candidate patch, which is validated against the criteria above. Successful patches are submitted; failures trigger detailed feedback and another iteration, up to the MAX_ITERATION limit.

Leveraging POV Generation Context. This strategy reuses conversation history from the POV generation phase. The additional context, including prior failure cases and reasoning traces, improves the LLM’s ability to generate correct and targeted patches.

Function Metadata Extraction. Once target functions are identified, the system queries the Static Analysis Service to extract detailed metadata, including function boundaries, complete source code, and precise file locations. This ensures the LLM has sufficient context to propose syntactically and semantically valid patches.

Multi-Model Resilience and Validation. To improve reliability, the patching process employs multiple LLMs from different providers (e.g., Anthropic, Google, and OpenAI). For each model, the system runs an iterative loop in which the LLM generates a candidate patch, the patch is applied to the codebase, and its validity is tested through compilation, execution of known POVs using the fuzzer harnesses (with sanitizers enabled), and, when available, functionality tests. If the patch fails at any stage, structured feedback—including compiler errors, failed diffs, or fuzzer output—is appended to the conversation, and the LLM attempts a revised patch in the next iteration. This process repeats until a valid patch is produced, the maximum iteration limit is reached, or the timeout expires. If one model fails to produce a valid patch, the system automatically falls back to the next model in the priority list.

4.3. Greedy Strategy

The patch0_delta strategy implements a greedy approach that assumes vulnerable functions are guaranteed to appear within the commit diff.

By extracting modified functions directly from the diff, this strategy reduces the computational overhead of LLM-driven identification in scenarios where vulnerabilities are clearly introduced through recent code changes.

4.4. Path-Aware Strategy

The patch2_delta strategy enhances patch generation through dynamic execution analysis and enriched prompting.

Control-Flow Integration. When patches fail validation, runtime control-flow data is incorporated into subsequent LLM prompts, similar to feedback mechanisms in POV generation. For C/C++ projects, coverage data is collected using LLVM profiling; for Java projects, JVM bytecode coverage analysis is employed. This information is embedded in prompts to enable path-aware patch generation.

4.5. Knowledge-Enhanced Strategy

The patch3_delta strategy augments patch generation with expert vulnerability analysis and a curated patch catalog.

Expert Analysis Integration. The strategy incorporates the initial analysis response from the POV generation phase as an expert assessment, providing contextual understanding of the vulnerability’s characteristics and exploitation patterns.

Sample Patch Catalog. The strategy retrieves vulnerability-specific patch examples from a catalog indexed by sanitizer signatures and vulnerability categories. These examples serve as concrete guidance for remediation approaches.

4.6. Full-Scan Patch Strategy

The main difference between full-scan patching strategies and delta-scan is the absence of a commit-based context, which forces function identification to rely solely on crash log analysis and LLM reasoning. To compensate, full-scan strategies employ enhanced prompting for more accurate target selection. Specifically, specialized prompts guide the LLM in analyzing beyond the immediate crash stack trace, encouraging exploration of indirectly related functions that may also contain vulnerabilities.

4.7. XPatch Strategy

The XPatch strategy addresses cases where no POVs or crash logs are available.

For delta-scans, this process is relatively straightforward because the commit diff provides strong contextual clues about where the vulnerability was introduced. We extract all modified functions from the diff and supply their full source code as context to the LLM.

For full-scans, where no commit information is available, XPatch relies on LLM-based scoring of all fuzzer-reachable functions. The LLM assigns likelihood scores to candidate functions based on predefined rubrics, and the top $k$ functions (default: 5) are saved. These functions are then used as the input context for patch generation.

Function Scoring Prompts. The scoring prompt is tailored to both language and vulnerability class.

In all cases, the LLM outputs a JSON array containing function names, assigned scores, and short justifications, sorted by descending score. Only functions with scores $\geq 7$ are retained.

Patch Generation. Once candidate functions are identified, their metadata and source code are provided to the LLM, with explicit instructions that the vulnerability lies within one or more of these functions. The LLM is then tasked with generating candidate patches to mitigate the issue.

Patch Validation with LibFuzzer. Since XPatch operates without known POVs, validation relies entirely on fuzzing. After applying a candidate patch, we execute LibFuzzer on the patched binary for 60 seconds. If the fuzzer produces a new crash during this run, the patch is deemed unsuccessful. Otherwise, the patch is considered valid under the available test conditions.

6.1. Static Analysis for C/C++

Our C/C++ analysis pipeline integrates three external tools: LLVM (llv, [n. d.]), SVF (svf, [n. d.]), and Bear (bea, [n. d.]). The workflow is as follows: generate LLVM bitcode for each fuzzer binary, use SVF to construct a call graph, compute all functions reachable from each fuzzer, and then build call paths from the fuzzer entrypoint to each reachable function. To improve efficiency, all fuzzers are analyzed in parallel, and for each fuzzer–function pair, call paths are constructed concurrently using breadth-first search (BFS). The maximum call path depth is limited to 50.

Generating LLVM bitcode presented significant engineering difficulties. Simply appending -emit-llvm to clang often failed due to missing dependent headers. To address this, we first collect all compile commands of the target project into a compilation database by building it inside the OSS-Fuzz base Docker image via the command: bear -o /out/compile_commands.json compile. This uses the Bear tool (bea, [n. d.]) to intercept and store the compilation command associated with each source file. We then process each compile command entry to produce bitcode for each source file, maintaining separate bitcode sets for fuzzer harnesses and project source files. For each fuzzer, all bitcode files are subsequently linked into a single bitcode module. Despite this, errors persisted, requiring fallback heuristics such as hardcoding common header paths and compiler flags. Ultimately, our tool successfully generated bitcode for over 95% of source files across tested projects, including curl, dropbear, and sqlite3.

Performance posed an additional challenge. Linked bitcode files could exceed 50 MB, and SVF frequently exceeded 1 hour or ran out of memory when constructing call graphs from such large bitcode files. To mitigate this, we trim oversized bitcode modules to a manageable size (e.g., 25 MB), apply lightweight type-based call graph analysis, and enforce a 10-minute timeout. If SVF fails to complete within this time budget, the Static Analysis Service will return empty results for that query.

6.2. Static Analysis for Java

For Java projects, we leverage CodeQL (cod, [n. d.]), which provides a more mature and reliable analysis infrastructure than the toolchain used for C/C++. The workflow consists of three main steps: (1) building a CodeQL database from the project source code, (2) executing queries against the database, (3) decoding query results and computing per-fuzzer data structures (i.e., reachable functions and call paths). We implemented two custom queries: one for extracting reachable functions, and another for computing call paths. These queries are designed to handle challenges such as function overloading and dynamic loading, which complicate traditional static analysis approaches.

To maximize performance, multiple call path queries are batched to reduce database connection overhead (the primary latency bottleneck). The number of fuzzer–target pairs can be extremely large (up to 100K), so we employ a batch execution mode with a batch size of 1,000. To avoid race conditions, the database is cloned for each fuzzer path, ensuring that every fuzzer operates on an isolated copy.

The call path analysis employs a balanced approach to cycle handling that prioritizes comprehensive path discovery over strict cycle prevention, that is, the code prevents direct cycles (intermediate methods cannot be the source or target method) but does not fully prevent indirect cycles. This design choice recognizes that indirect cycles often represent legitimate and valuable execution patterns in real world projects, such as recursive algorithms. The Analysis Service mitigates the theoretical risk of infinite recursion through a practical depth limit (10 calls), ensuring both computational efficiency and analytical completeness.

In addition, we developed a lightweight baseline analysis that conservatively identifies function callees using only class types and function names. This approach sacrifices precision but serves as a fallback mechanism when CodeQL queries fail or become too costly.

Our Java static analysis pipeline completes within five minutes for representative OSS-Fuzz projects such as Apache Zookeeper, Tika, and Commons-Compress.

Sanitizer Selection.

We disabled UndefinedBehaviorSanitizer for all projects and disabled MemorySanitizer for projects with more than ten fuzzer harnesses, prioritizing AddressSanitizer where we observed the highest yield.

Time Budgeting for LLM-Based Fuzzing.

To control API spend, each worker’s LLM-based fuzzing is capped at 60 minutes, and reduced to 45 minutes if other fuzzers have already produced POVs for the same target.

libFuzzer Time Management.

Parallelism and Isolation.

Because patching requires full rebuilds (often minutes per attempt), we run 3–5 parallel processes for each patching strategy. A single VM may execute 20–30 patching processes concurrently for one vulnerability. Each process operates in its own isolated workspace to prevent cross-contamination between attempts.

Patch Submission Caps per Vulnerability.

Submitting too many patches, even if valid, reduces the accuracy multiplier and lowers the overall score. Because patches contribute the largest share of points, we balance patching success probability against scoring penalties by capping the number of submissions per vulnerability (keyed by canonical signature): at most five POV-based patches and at most three XPatches.

These treatments reflect tradeoffs between efficiency and coverage, aiming to optimize performance under resource constraints. However, they may not guarantee the best possible score in every setting. For example, if many vulnerabilities can only be triggered under MemorySanitizer or UndefinedBehaviorSanitizer, skipping these sanitizers would cause FuzzingBrain to miss them, leading to lower overall performance in the final round.

8.1. Concurrency and Parallelization

8.2. LLM-Generated Code and Debugging

More than 90% of our system code was generated with LLM assistance. While this accelerated development, it also made debugging significantly harder, as we were not as familiar with code we did not write ourselves. This experience highlighted the tradeoff between rapid prototyping and long-term maintainability when relying heavily on LLMs for code generation.

8.3. Configuration Management

With multiple services (each requiring its own API keys), we maintained four separate .env files across subdirectories. In one exhibition round, a critical service failed because its file was not updated with the correct keys. This underscored the need for centralized and automated secret management, rather than relying on manual updates.

8.4. Logging and Observability

8.5. Validation and Silent Failures

Post-final analysis revealed a critical flaw in our patch validation pipeline: a missing parameter in a Python function call caused all Python subprocesses (invoked from Go to handle LLM-based patching) to crash silently. Consequently, many patches were submitted without verification against known POVs, leading to a significant drop in accuracy. This highlights the need for robust error handling, explicit status reporting, and fail-safe validation mechanisms when orchestrating heterogeneous components.

8.6. Diverse Fuzzing Strategies

Our system made only minimal use of traditional fuzzing (only libFuzzer). While LLM-based fuzzing was highly effective, we likely missed opportunities to discover additional POVs by not integrating alternative fuzzers such as AFL++ (afl, [n. d.]) or Honggfuzz (hon, [n. d.]). Incorporating diverse fuzzing engines could have improved overall coverage and robustness.