Before the CVE: Mining Open-Source Commits for Negative Day Vulnerabilities

[ Abstract ]

Once a security fix becomes public, the diff becomes a roadmap to the vulnerability. An attacker can reconstruct the missing invariant and start building a trigger before a CVE or advisory tells defenders that the affected package is at risk. Industry calls this interval between public fix and public disclosure the Negative Day.

We built an AI-driven pipeline that starts from a package and version, resolves it to an upstream repository and tag, and scans the commits that landed afterward. Each commit is given to a bounded analysis agent with its diff, message, and pull-request context. The agent must reconstruct the pre-patch flaw, identify an attacker-controlled path, and produce a concrete trigger. If it cannot do all three, the commit is rejected as ordinary hardening or bug fixing. Positive candidates are later linked to OSV, CVE, and GHSA records so we can measure whether the agent identified the issue before conventional feeds caught up.

The interesting AI problems appear after the first prompt. Which parts of a large diff belong in context? Does PR text help, or leak the answer? How do we keep a malicious commit from prompt-injecting the detector reviewing it? How do we separate a plausible generated PoC from one executed against both vulnerable and fixed revisions? How do we evaluate the system without giving it the advisory or gold patch?

The current evaluation corpus replays 39 real security-fix windows from projects including axios, React Router, Authlib, aiohttp, Django, React, and cryptography. We will show the operational architecture, representative agent decisions, false-positive controls, benchmark design, and the remaining gap between an exploit hypothesis and independently verified vulnerability evidence.