DARPA's AI Cyber Challenge (AIxCC) showed that cyber reasoning systems (CRSs) can go beyond vulnerability discovery to autonomously confirm and patch bugs: seven teams built such systems and open-sourced them after the competition. Yet all seven open-sourced CRSs remain largely unusable outside their original teams, each bound to the competition cloud infrastructure that no longer exists. We present OSS-CRS, an open, locally deployable framework for running and combining CRS techniques against real-world open-source projects, with budget-aware resource management. We ported the first-place system (Atlantis) and discovered 10 previously unknown bugs (three of high severity) across 8 OSS-Fuzz projects. OSS-CRS is publicly available.
Figures & tables
CRS
Comp.
Infra
Middleware
Local
Composable
Atlantis [ 23 ]
9+
TF+K8s
Ka/PG+R ∗
×
×
Buttercup [ 8 ]
14+
TF+Helm
R/M
∘
×
RoboDuck [ 4 ]
1
TF+VMs
–/S ∗
∘
×
FuzzingBrain [ 49 ]
4
TF+K8s
–/– ∗
∘
×
Artiphishell [ 6 ]
53
TF+Helm
RMQ/PG+N ∗
△
×
BugBuster [ 7 ]
16
TF+Helm
RMQ/PG+R ∗
×
×
TABLE I: Deployment characteristics of the AIxCC finalist CRSs. “Local”: can run end-to-end on a single machine against a new target without cloud provisioning. “Composable”: analysis components can be extracted and recombined across systems.
Fig. 1: Architecture overview of OSS-CRS . Users provide a target project and configuration (optionally with code diffs or bug candidates) and receive PoVs and patches as outputs through the three-phase interface ( prepare , build-target , run ). CRSs run in resource-managed containers with isolated networks and interact with the platform through libCRS . All LLM calls are routed through the LiteLLM proxy, which handles model routing and per-CRS budget enforcement. The exchange sidecar deduplicates artifacts in file-based storage and synchronizes them across all CRSs.
Fig. 2: Docker workflow across the three operational phases, showing image construction (top), container execution (middle), and file artifact flow (bottom).
Category
Command
Purpose
Build outputs
submit-build-output
Publish build artifacts
Runtime setup
register-shared-dir
Share files within CRS
Artifact exchange
register-submit-dir
Register for background submission
Artifact exchange
register-fetch-dir
Register for background fetching
Artifact exchange
submit
Submit artifact (PoV, seed, patch)
Artifact exchange
fetch
One-shot fetch of artifacts
TABLE II: Representative libCRS commands used by CRS developers.
Fig. 3: Builder sidecar workflow. The sidecar restores a snapshot of the compiled target, applies the patch diff, and performs an incremental rebuild.
CRS
Type
Languages
LLM
crs-libfuzzer
Bug-finding
C/C++
None
Atlantis-C
Bug-finding
C/C++
✓
Atlantis-Java
Bug-finding
Java
✓
Atlantis-MultiLang
Bug-finding
C/C++/Java
✓
ClaudeCode
Bug-fixing
C/C++/Java
✓
TABLE III: CRSs integrated into OSS-CRS .
Variable
Purpose
OSS_CRS_TARGET
Target project name
OSS_CRS_TARGET_HARNESS
Harness binary name
OSS_CRS_NAME
CRS name (for service discovery)
OSS_CRS_CPUSET
Allocated CPU cores ( e . g ., 4-7 )
OSS_CRS_MEMORY_LIMIT
Memory limit ( e . g ., 16G )
OSS_CRS_LLM_API_URL
LLM proxy endpoint
TABLE IV: Environment variables injected into CRS containers.
Evaluating the ability of large language models (LLMs) to discover software bugs is increasingly important. Existing benchmarks typically evaluate this capability by asking the model to generate a proof-of-concept input that triggers a predefined target vulnerability. However, this setup may overlook valid crashes discovered by the model when they do not match the predefined target. As a result, the evaluation may not reflect the model's real capability. We present FuzzingBrain-Bench, a benchmark for assessing AI models' ability to discover bugs in open-source software. Models are given an open-source project and a sanitizer-instrumented harness in a self-contained Docker image. Their goal is to generate inputs that trigger as many distinct crashes as possible through the harness. A model's performance on each challenge is scored based on the number of distinct crash signatures it produces, capped at a predefined maximum and weighted by a difficulty coefficient. FuzzingBrain-Bench V1 consists of 77 challenges drawn from 43 open-source projects, with 36 C, 32 C++, and 9 Java/JVM challenges. We evaluate Claude Haiku 4.5, Claude Sonnet 4.6, and Claude Opus 4.8 on the full benchmark. Claude Opus 4.8 performs best, triggering crashes in 60 of 77 challenges and achieving a score of 196 out of 579. None of the three models triggers a crash in 13 challenges. The FuzzingBrain-Bench corpus and harnesses are publicly available at https://github.com/fuzzingbrain/FuzzingBrain-Bench.
AI has the potential to transform cybersecurity by enabling systems that can autonomously detect, analyze, and remediate software vulnerabilities. However, existing cybersecurity evaluations of AI systems are limited in scale or scope, and fail to capture the end-to-end lifecycle of real-world software vulnerability discovery and remediation. To address this gap, we propose CyberGym-E2E, a large-scale and realistic end-to-end cybersecurity benchmark that comprehensively evaluates AI agents' abilities across the full lifecycle of vulnerability discovery, PoC generation, and patch generation. CyberGym-E2E is comprehensive and scalable, as we build an automated, agent-enhanced pipeline for transforming open-source vulnerability data into realistic evaluation environments. Currently, the benchmark consists of 920 real-world vulnerabilities across 139 different open-source projects.
Tianneng Shi, Robin Rheem, Dongwei Jiang +13
1UC Berkeley · 2Johns Hopkins University · 3UC Santa Cruz +1
The release decision for frontier AI systems increasingly relies on cyber capability benchmarks, yet public vulnerability benchmarks can expose agents to previously published advisories, exploits, and fixes, making it difficult to distinguish prior exposure from capability on unseen vulnerabilities. We evaluate open-weight and proprietary AI models on exploit generation, vulnerability repair and subsequent attacks in five nonpublic software environments, including vulnerabilities we privately disclosed while they remained unpatched. Researcher-developed and reviewed deterministic graders, not LLM judges, determine task scores. Comparisons with 209 disclosed vulnerabilities and cryptographic challenges reveal substantial variation across systems and vulnerability types. Repair scores exceed attack scores in two nonpublic environments and fall below them in three. Passing an initial security test is also insufficient: another exploit succeeds in 92 of 524 non-independent defender test intervals after the initial exploit is stopped. These results motivate vulnerability-specific attack-repair comparisons and subsequent resistance tests.
Tobias Heldt, Matt Turk, Christoph Landolt +1
XOR · Protege · CISPA Helmholtz Center for Information Security