OSS-CRS: Liberating AIxCC Cyber Reasoning Systems for Real-World Open-Source Security

Andrew Chin; Dongkwan Kim; Yu-Fu Fu; Fabian Fleischer; Youngjoon Kim; HyungSeok Han; Cen Zhang; Brian Junekyu Lee

cs.CRMar 9, 2026

OSS-CRS: Liberating AIxCC Cyber Reasoning Systems for Real-World Open-Source Security

Authors: Andrew Chin, Dongkwan Kim, Yu-Fu Fu, Fabian Fleischer, Youngjoon Kim, HyungSeok Han, Cen Zhang, Brian Junekyu Lee,

Organizations: Georgia Institute of Technology · Microsoft

Abstract

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 ∗	$\times$	$\times$
Buttercup [ 8 ]	14+	TF+Helm	R/M	$\circ$	$\times$
RoboDuck [ 4 ]	1	TF+VMs	–/S ∗	$\circ$	$\times$
FuzzingBrain [ 49 ]	4	TF+K8s	–/– ∗	$\circ$	$\times$
Artiphishell [ 6 ]	53	TF+Helm	RMQ/PG+N ∗	$\triangle$	$\times$
BugBuster [ 7 ]	16	TF+Helm	RMQ/PG+R ∗	$\times$	$\times$

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.

Cybersecurity

Cybersecurity develops methods to protect digital and cyber-physical systems from attacks, vulnerabilities, data loss, and misuse.

See all 354 papers

FuzzingBrain-Bench V1: Evaluating Open-Ended Bug Discovery by LLMs
Aug 25, 2026Ze Sheng, Aleksandar Kezic, Zhicheng Chen +1Software Engineering Benchmarks Automated Software Testing
Texas A&M University · University of Novi Sad
CyberGym-E2E: Scalable Real-World Benchmark for AI Agents' End-to-End Cybersecurity Capabilities
Jun 3, 2026Tianneng Shi, Robin Rheem, Dongwei Jiang +13Automated Program Repair Software Vulnerability Detection
1UC Berkeley · 2Johns Hopkins University · 3UC Santa Cruz +1
Does AI Help Cyber Attackers or Defenders? Evidence from Nonpublic Vulnerabilities and Subsequent Attacks
Oct 5, 2026Tobias Heldt, Matt Turk, Christoph Landolt +1Automated Exploit Generation Automated Program Repair
XOR · Protege · CISPA Helmholtz Center for Information Security

Aug 25, 2026J/K move · Enter open · S save

FuzzingBrain-Bench V1: Evaluating Open-Ended Bug Discovery by LLMs

Ze Sheng, Aleksandar Kezic, Zhicheng Chen, Jeff Huang

Texas A&M University · University of Novi Sad

Software Engineering Benchmarks Automated Software Testing LLM Security

Open paper AskPDF arXiv

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.

Abstract

Cybersecurity

Explore similar work

FuzzingBrain-Bench V1: Evaluating Open-Ended Bug Discovery by LLMs

CyberGym-E2E: Scalable Real-World Benchmark for AI Agents' End-to-End Cybersecurity Capabilities

Does AI Help Cyber Attackers or Defenders? Evidence from Nonpublic Vulnerabilities and Subsequent Attacks