BugStone-E2E: Agentic Vulnerability Discovery from CVE Patch History

Summary

BugStone-E2E is a framework for agentic vulnerability discovery: it combines LLM agents, program analysis, and runtime validation to perform automated vulnerability discovery and automated patching on real software. Rather than asking a model to search a codebase for anything that looks wrong, BugStone-E2E first turns the public record of fixed vulnerabilities into executable detection rules, and then spends agent effort on the candidates those rules identify. Every finding it reports ends in runtime evidence and a scope-checked patch, not a confidence score.

From 19,325 high-severity CVEs disclosed between 2022 and 2026, BugStone-E2E identified 2,710 verified fixing commits and constructed 1,033 detection rules across 56 CWE families, packaged into 172 skills. Applied across 14 programs, it produced runtime evidence for 644 findings.

The work was done at IBM Research by Qiushi Wu, Kevin Eykholt, Youngja Park, Xiaokui Shu, Dhilung Kirat, Douglas Lee Schales, and Ian Molloy, and is described in arXiv:2609.05335. It is the latest and most capable version of a line of work that began with a 2024 patent filing and was published as BugStone at ICML 2026 — see lineage below.

The Idea: A Fix Is a Detector Nobody Executed

Public vulnerability databases record a great deal about known flaws — weakness type, affected component, and the commit that fixed it. A fixing commit is the most precise statement anyone ever writes about why a piece of code was unsafe: it shows the exact condition that had to be established, the check that was missing, the release that never happened. But that statement is written for a human reader. Nothing executes it again.

Meanwhile the same unsafe condition usually exists elsewhere. Code is copied, patterns are imitated, and an API that was misused once in a driver is misused the same way in twenty others that never received an advisory. The detection knowledge is already public; it is simply not in a form anything can run.

BugStone-E2E makes it runnable. It reads the patch history behind disclosed CVEs, extracts what each fix implies about correct use, and emits a rule that can be carried to any codebase. The name is the argument: the history is the detector.

Lineage: Three Versions of One Idea, 2024 to 2026

BugStone-E2E is the current and most capable version of a line of work that began as a patent filing in July 2024, a year before agentic vulnerability discovery became a crowded field. The three artifacts below describe the same core idea at increasing scope; BugStone-E2E is the one to cite for the system as it now stands.

The progression is from a mechanism, to a measured system, to an end-to-end one. What stayed fixed across all three is the premise: a fix is a specification that nobody has executed since, and the code that still violates it is findable.

The Funnel: Cheap Analysis First, Agents Where They Pay

Running an LLM agent over every call site in a large program is neither affordable nor accurate. BugStone-E2E is shaped as a funnel: early stages process a large pool of candidates with lightweight analysis, and later stages apply increasingly capable and expensive models to a shrinking set of targets.

Two properties of this shape matter more than any individual stage. The first is that the expensive component is never the first responder, so cost scales with the number of plausible candidates rather than with the size of the codebase. The second is that the last word belongs to execution rather than to a model: a report survives only if something ran.

Results

All figures below are from arXiv:2609.05335 (v1, September 2026).

What a Detection Rule Contains

A rule is what remains after a fixing commit has been read for its general content. Each one records three things:

• Scan anchors — the syntactic handles that locate candidate sites in unfamiliar code. These are what Tree-sitter matches, and they are why stage 2 costs nothing per candidate.
• Fix semantics — the unsafe condition the patch removed, stated so that an agent can decide whether a new site exhibits it. This is the part that generalizes; the original CVE is one instance of it.
• CVE provenance — the disclosed vulnerability and commit the rule was derived from. A maintainer receiving a report can read the original fix and judge the analogy for themselves.

Rules are organized by CWE and by language, and packaged into 172 skills. Provenance is the property that makes the output reviewable: a finding arrives with a prior vulnerability attached, so the question put to a maintainer is concrete — this code has the shape that CVE-X was filed for; here is a run where the condition held — rather than an assertion that a model considered the code suspicious.

Where This Sits Among Agentic Vulnerability Discovery Systems

Agentic vulnerability discovery became a crowded area in 2025 and 2026, and the systems in it differ mainly in where their knowledge comes from. A fuller map of that landscape is on the research index; the short version of how BugStone-E2E differs:

• Exploratory agents — Google's Big Sleep and OpenAI's Aardvark reason over a target codebase directly, looking for what is wrong in it. Their knowledge is whatever the model brings. BugStone-E2E brings an explicit, inspectable corpus of rules instead, and can say which disclosed vulnerability each of its findings is an echo of.
• Proof-of-vulnerability agents — FaultLine and DrillAgent start from a vulnerability that is already known in a program that is already known to have it, and work to trigger it. BugStone-E2E runs the other direction: it starts from vulnerabilities known elsewhere and looks for code that has never been reported.
• Cyber reasoning systems — the systems built for DARPA's AI Cyber Challenge find and patch within a challenge target, end to end. BugStone-E2E shares the end-to-end ambition, including patch generation, but its unit of reuse is a rule mined from history rather than a per-target analysis.

None of these approaches subsumes another. An exploratory agent can find a bug class nobody has ever disclosed, which a history-derived rule by construction cannot. What history-derived rules buy is scale with provenance: the knowledge is written down, it carries a citation, and applying it to a new program costs a scan rather than a re-derivation.

Descriptions of other systems are summarized from their own published material as of September 2026 and link to it; they are not evaluations, and no comparison of numbers across these systems is implied, since none of them measure the same quantity.

Paper and Citation

The History Is the Detector: Executing CVE Patch History, End-to-End.
Qiushi Wu, Kevin Eykholt, Youngja Park, Xiaokui Shu, Dhilung Kirat, Douglas Lee Schales, and Ian Molloy.
arXiv preprint arXiv:2609.05335, September 2026.  [arXiv] [PDF]

@article{wu2026bugstonee2e,
  title   = {The History Is the Detector: Executing CVE Patch History, End-to-End},
  author  = {Wu, Qiushi and Eykholt, Kevin and Park, Youngja and Shu, Xiaokui
             and Kirat, Dhilung and Schales, Douglas Lee and Molloy, Ian},
  journal = {arXiv preprint arXiv:2609.05335},
  year    = {2026},
  url     = {https://arxiv.org/abs/2609.05335}
}

Questions about the system, the rule corpus, or collaboration: qiushi@qiushiwu.com. For findings produced against third-party software, disclosure follows the practice described in the research ethics section of the homepage: validate, notify maintainers before public release, coordinate.