Source-linked AI summary
CVE-Bench: A Benchmark for AI Agents' Ability to Exploit Real-World Web Application Vulnerabilities
Yuxuan Zhu, Antony Kellermann, Dylan Bowman, Philip Li, Akul Gupta, Adarsh Danda, Richard Fang, Conner Jensen, Eric Ihli, Jason Benn, Jet Geronimo, Avi Dhir, Sudhit Rao, Kaicheng Yu, Twm Stone, Daniel Kang
TL;DR
LLM agents’ cyberattack capabilities create a need for real-world evaluation of web-application vulnerabilities, beyond limited prior benchmarks. CVE-Bench provides a sandboxed benchmark using critical web-application CVEs, and agents exploit up to 13% of vulnerabilities in the one-day setting.
Problem
Existing benchmarks provide limited coverage of real-world web-application vulnerabilities, while reproducing exploits and evaluating diverse attacks require substantial specialized effort.
Method
CVE-Bench combines vulnerable web-application containers, eight standardized attack targets, automated grading, and reference exploits across 40 critical CVEs.
Results
LLM agents exploit up to 10% of vulnerabilities under the zero-day setting and 13% under the one-day setting.
Takeaways & Limitations
The findings indicate potential threats to web-application security and highlight the need for continued evaluation, red-teaming, and regulation of AI agents.
Takeaways & Limitations
The benchmark evaluates only eight predefined attack types and 40 web-related CVEs from a specific date range.
Abstract
from arXiv · showhide
Large language model (LLM) agents are increasingly capable of autonomously conducting cyberattacks, posing significant threats to existing applications. This growing risk highlights the urgent need for a real-world benchmark to evaluate the ability of LLM agents to exploit web application vulnerabilities. However, existing benchmarks fall short as they are limited to abstracted Capture the Flag competitions or lack comprehensive coverage. Building a benchmark for real-world vulnerabilities involves both specialized expertise to reproduce exploits and a systematic approach to evaluating unpredictable threats. To address this challenge, we introduce CVE-Bench, a real-world cybersecurity benchmark based on critical-severity Common Vulnerabilities and Exposures. In CVE-Bench, we design a sandbox framework that enables LLM agents to exploit vulnerable web applications in scenarios that mimic real-world conditions, while also providing effective evaluation of their exploits. Our evaluation shows that the state-of-the-art agent framework can resolve up to 13% of vulnerabilities.
1. Introduction
CVE-Bench addresses the lack of comprehensive real-world web-vulnerability benchmarks by combining a sandbox framework, reproducible exploits, standardized attack targets, and automatic evaluation. It evaluates agents across zero-day and one-day settings using 40 critical-severity web-application CVEs.
- Motivation: Existing benchmarks inadequately assess exploitation of real-world web vulnerabilities because they emphasize code snippets, abstract CTF challenges, or limited task and attack coverage.Real-world exploitation also requires understanding application architecture and attacks affecting servers or users.
- Motivation: Building such a benchmark requires reproducible vulnerable applications, reference exploits, and reliable detection of diverse cyberattacks.Exploit reproduction required 5–24 person-hours per vulnerability, while attack detection lacks a one-size-fits-all solution.
- Framework: CVE-Bench uses isolated target containers, eight standardized attack vectors, automatic grading, and reference exploits for each vulnerability.Agents are directed to achieve any one of the eight standard attack targets.
- Benchmark: The benchmark contains 40 critical-severity web-application CVEs spanning applications such as education, e-commerce, LLM services, mail servers, and webpage management.The CVEs are rated critical under CVSS version 3.
- Evaluation: Zero-day tasks provide only task descriptions, whereas one-day tasks additionally provide high-level vulnerability descriptions for exploit construction.The benchmark evaluates agents under both vulnerability-information settings.
2. Background
Prior cybersecurity-agent research uses agent frameworks for cyberattacks, but existing benchmarks remain insufficiently representative of real-world web vulnerabilities. CVE-Bench is introduced to address these limitations.
- Existing LLM Agents for Cyberattacks: Cybench uses an act–execute–update loop to analyze environmental feedback during cyberattack tasks.This is a reactive, ReAct-style agent framework.
- Motivation: Real-world cybersecurity benchmarks are presented as crucial for comprehensively evaluating threats from autonomous LLM cyberattacks.The motivation follows concerns about LLMs autonomously executing cyberattacks.
- Existing Cybersecurity Benchmarks are Insufficient: Existing CTF-based benchmarks contain many vulnerabilities but do not reflect real-world scenarios or severity-rated vulnerabilities.They focus on smaller databases and CTF tasks.
- Existing Cybersecurity Benchmarks are Insufficient: Prior benchmarks neglect severe attacks beyond CTF tasks, limiting their coverage of cybersecurity capabilities.The comparison is summarized in Table 1.
3. CVE-Bench
CVE-Bench is constructed from 40 severe web-related CVEs and packages each task with a vulnerable application, attack specification, reference exploit, and automatic evaluation. Its tasks cover eight standard attacks and simulate zero-day and one-day information settings.
- 3.1. Overview: CVE-Bench includes 40 web-related CVEs from the National Vulnerability Database, with CVSS 3.1 base scores of at least 9.0.The benchmark emphasizes content-management and AI applications among diverse web-application types.
- 3.1. Overview: Each task pairs a CVE with specifications, containers hosting the vulnerable application, and a reference exploit that reproduces the vulnerability.Agents receive an exploit goal, required information, and context for vulnerability-lifecycle stages.
- 3.2. Task Specification: Eight standard attacks make exploitation measurable, requiring agents to assess vulnerabilities, select feasible attack options, and execute them.The attacks include database modification, database access, unauthorized administrator login, privilege escalation, outbound service requests, denial of service, file access, and file creation.
- 3.2. Task Specification: File deletion is excluded as a standalone attack because deleting critical files often causes denial of service, creating overlap with the DoS target.This is an explicit attack-scope decision.
- 3.2. Task Specification: The benchmark prohibits attacks outside the target websites and bans password brute force, using randomly generated passwords to discourage it.Attacking the evaluator is explicitly prohibited.
- 3.2. Task Specification: Zero-day scenarios omit vulnerability information, while one-day scenarios provide a high-level description of the specific vulnerability.These settings model different stages of the vulnerability lifecycle.
4. Experiments
CVE-Bench evaluates three LLM agent frameworks across zero-day and one-day real-world vulnerability exploitation tasks, measuring success, exploit composition, costs, and failure modes. Performance varies substantially with agent design, attack strategy, and the information provided.
- Experimental Setup: The experiments evaluate three agent frameworks under zero-day and one-day settings, repeating each setting five times with a 30-iteration task limit.The evaluation uses gpt-4o-2024-11-20 as the default language model.
- Success Rates: Up to 10% of vulnerabilities were exploited under zero-day conditions, while one-day success reached 12.5%.One-day tasks provide high-level vulnerability descriptions, which generally improve success rates by reducing uncertainty.
- Exploit Composition: T-Agent’s successful exploits included database access in 68% of zero-day cases and 30% of one-day cases, whereas AutoGPT recorded 0% in both settings.T-Agent’s advantage was associated with using sqlmap for SQL-injection workflows.
- Costs: Running CVE-Bench costs less than $100 overall, but one-day evaluations cost more than zero-day evaluations despite providing vulnerability descriptions.Agents may compensate for reduced exploration by performing deeper iterations and more actions.
- Common Failure Modes: Insufficient exploration was the dominant bottleneck: agents often failed to locate vulnerable endpoints even when given high-level descriptions.Other recurring failures included incorrect focus, tool misuse, limited task understanding, and inadequate reasoning.
- Common Failure Modes: One-day descriptions reduced limited task understanding, incorrect focus, and insufficient exploration, but increased tool-misuse and inadequate-reasoning failures.The results indicate that additional vulnerability information changes the failure profile rather than eliminating failures.
5. Discussion
CVE-Bench is an initial real-world cybersecurity benchmark, but its evaluation is bounded by predefined attack types and a limited CVE sample. The authors report exploitation rates of up to 10% in zero-day and 13% in one-day settings.
- CVE-Bench cannot evaluate attacks beyond eight predefined standard attacks, which may produce false negatives.
- CVE-Bench currently covers only 40 web-related CVEs from a specific date range.
- The authors plan to extend CVE-Bench to more domains and vulnerabilities.
- 10% of vulnerabilities were exploitable under the zero-day setting, compared with 13% under the one-day setting.
Impact Statement
The authors expect CVE-Bench to help characterize AI agents’ cybersecurity capabilities and limitations and support more robust, secure AI systems.
- CVE-Bench is intended to help the community understand AI agents’ capabilities and limitations in cybersecurity.
- The authors encourage adding new vulnerabilities and attack methods and sharing findings with the community.
A. Data Collection and Curation
The benchmark curates reproducible, critical web-application CVEs using explicit selection criteria, manual review, and reconstructed or publicly documented exploits. The resulting dataset contains 40 reproduced CVEs spanning multiple application categories and attack types.
- CVEs were selected from the NVD if published between May 1, 2024 and June 14, 2024 and rated CRITICAL under CVSS Version 3.x.
- The curation criteria required web applications, open-source software, platform independence, and no sensitive information sent to external services.
- 60 initially selected CVEs were manually assessed for exploit reproducibility using public PoCs or reconstructions from NVD descriptions and vendor patches.
- CVEs were excluded when vulnerable versions were unobtainable, exploitation required chaining another vulnerability, or available information was insufficient for reproduction.
- 40 CVEs had successfully reproduced exploits, with details including identifiers, dates, CVSS scores, affected applications, and reproduced attack types.
- The reproduced applications span content management, AI or machine learning, business management, web infrastructure, libraries or packages, monitoring, e-commerce, computing management, and web portals.
B. Architecture of CVE-Bench
CVE-Bench organizes each vulnerability in a containerized setup and separates the vulnerable application, evaluation server, and exploit-reproduction pipeline. This architecture supports reproducible deployment and evaluation of benchmark cases.
- Each CVE setup contains metadata, an exploit-reproduction write-up, containerized exploit code, a composition file, and a vulnerable application container.
- The architecture comprises a containerized vulnerable web application, an evaluation server, and an exploit-reproduction pipeline.
B.1. Vulnerable Web Application
Each CVE is deployed as a containerized vulnerable web application with supporting services and standardized evaluation data. Curated templates and optional extensions accommodate application-specific infrastructure.
- Each vulnerable application uses a web-application container, a database-service container, and optional utility containers.The web application listens on port 9090 within the internal container network.
- The database is pre-populated with standardized evaluation data, including an attacker account and a secret used to verify unauthorized access.
- The target container is built from a curated WordPress template that installs the plugins associated with the challenge.Environment variables configure the attacker account and application name for evaluation servers.
- The database container initializes from a SQL file and includes a table with a secret for database-access attacks.Additional services are added through extended compose files and Dockerfiles when required by a CVE.
- Pre-built images for all containers are published through the CVE-Bench Docker repository.
B.2. Evaluation Server
CVE-Bench evaluates exploits through an evaluation server embedded in each web-application container. Its /done endpoint automatically checks standardized attack targets and returns success status with the successful attack type.
- The evaluation server listens on port 9091 and exposes /done for querying exploitation status.
- The /done endpoint returns a JSON status indicating whether the exploit succeeded and a message naming the successful attack type.The response uses status=true for success and false otherwise.
- Example responses distinguish an unsuccessful exploit from successful database access.
- At runtime, the evaluation server reads the application name and invokes the corresponding evaluation functions automatically.
- Each reproduced CVE exploit runs from a separate exploit container connected to the target container's Docker network.The exploit container automatically attacks the vulnerable application and attempts one standardized attack target.
- CVE-Bench integrates with inspect ai to run an agent on a selected vulnerability, model, and setting from a single command.
C. Agent Prompts and Configurations
The appendix specifies task prompts and agent configurations for zero-day and one-day vulnerability exploitation. Agents receive application-specific context, standardized attack goals, shared tools, and execution constraints.
- C.1. Prompt Template: The prompt template provides examples for zero-day and one-day tasks across Tutor, Spin, and Dtale vulnerabilities.
- C.1. Prompt Template: Zero-day prompts identify the vulnerable application and ask agents to find and exploit vulnerabilities without providing a vulnerability description.Spin receives additional usage information because it lacks a text-based interface.
- C.1. Prompt Template: One-day prompts provide a high-level NVD vulnerability description that may help agents determine an attack strategy.The Dtale example describes authentication bypass and remote code execution involving a hardcoded Flask SECRET_KEY and unrestricted filter queries.
- C.1. Prompt Template: Agents are instructed to achieve one of eight attack targets, including denial of service, file access, file creation, and database attacks.
- C.1. Prompt Template: Prompts prohibit attacking other websites or ports and prohibit brute-force password cracking.
- C.2. Configurations: All evaluated agents can use ZAP and sqlmap as security-testing tools.
- C.2. Configurations: T-Agent uses supervisors, a team manager, and specialized SQL, SSTI, XSS, general, and ZAP teams.Its SQL team was enabled to use sqlmap.
- C.2. Configurations: Cy-Agent is adapted from a Capture the Flag configuration by replacing secret-flag submission with exploit-success reporting, while AutoGPT uses its classic configuration and a cybersecurity role.AutoGPT runs with re-prompts skipped and continuous mode enabled; shared practices require health checks and completion through /done.
D. Additional Baselines
Additional baselines show that conventional automated scanning and T-Agent with Llama 3.1 did not exploit the evaluated CVEs, highlighting differences among agent configurations and models.
- T-Agent with Llama 3.1 successfully exploited 0 CVEs across five executions on CVE-Bench.The authors report a capability gap between Llama 3.1 and GPT-4o under the same prompt template.