How AI Finds Vulnerabilities: Fuzzing, Reasoning, and Validation

In October 2024, a Google agent called Big Sleep found an exploitable stack buffer underflow in SQLite: a negative-index write in the seriesBestIndex function. SQLite’s maintainers patched it the same day, before it shipped in an official release. Google Project Zero described it as the first public case of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software.

The important detail is easy to overstate. This was not proof that fuzzing had failed forever, or that every possible harness would have missed the bug. Project Zero showed something narrower and more useful: SQLite’s existing testing infrastructure, plus Project Zero’s own follow-up AFL run, did not find it. Big Sleep did because it started from a related fixed bug, formed a variant hypothesis, inspected the code around that hypothesis, and used debugger and sandbox evidence to confirm the crash.

That is the real shift. AI vulnerability discovery is not replacing fuzzers, static analyzers, symbolic execution, or human review. The systems that matter are hybrids. They use models to form hypotheses about intent, reachability, and security boundaries, then use old-fashioned tools to prove or discard those hypotheses.

The difference is operational, not philosophical. A model can now ask “where else does this invariant silently fail?” across a repository, while a fuzzer, sanitizer, debugger, or test harness decides whether the answer is real. That loop is what made Big Sleep useful, what OpenAI’s Aardvark and Codex Security productize, what Anthropic’s Mythos Preview demonstrates at the frontier, and what DARPA’s AI Cyber Challenge turned into a competition.

The old tools still matter

Three families of automated bug-finding dominated the last two decades. They still do real work. The mistake is treating them as if they were obsolete because LLMs can reason about code.

Coverage-guided fuzzing. AFL++, libFuzzer, and OSS-Fuzz mutate inputs, keep the ones that reach new coverage, and run the loop at scale. LLVM describes libFuzzer as an “in-process, coverage-guided, evolutionary fuzzing engine.” Google’s OSS-Fuzz has run continuous fuzzing for open-source projects since 2016, and its public overview says it has helped identify and fix more than 13,000 vulnerabilities and 50,000 bugs across more than 1,000 projects.

Fuzzing’s limit is not stupidity. It is the shape of the search. A parser behind a checksum, magic-byte gate, custom state machine, or narrow precondition can be hard for a generic mutational fuzzer to reach unless the harness, dictionary, mutator, or solver guidance points it in the right direction. Coverage feedback tells the fuzzer that one input reached a new edge. It does not, by itself, know that a field is supposed to be a valid CRC or that an apparently defensive check fails to protect the property the code relies on.

Static analysis. Semgrep is strongest when a bug can be expressed as a rule or taint pattern. CodeQL goes deeper by representing code as queryable data, including syntax, control flow, and data flow. Those systems catch huge classes of defects because many vulnerabilities really do look like source-to-sink problems: untrusted input reaches SQL, shell execution, file paths, deserialization, cryptographic parameters, or a dangerous API without enough constraint.

The weakness is context. Static tools approximate reachability and intent to stay tractable on large codebases. They can tell you that a path looks dangerous without knowing whether it can happen in the running system, whether a framework invariant rules it out, or whether the apparent guard actually enforces the security property. That gap is why SAST has a false-positive reputation even when the underlying analysis is technically sophisticated.

Symbolic execution. KLEE, angr, and related systems treat inputs as symbolic variables and solve path constraints. In principle, they can prove that a specific input reaches a vulnerable state. In practice, they run into path explosion: branches, loops, callbacks, environmental state, and library calls multiply the search space until a whole application becomes too large to explore cleanly.

The common thread is not that these tools are shallow. It is that each tool explores the program through a specific formal handle: coverage, rules, data flow, constraints. LLM agents add a different handle. They can read the code and ask whether the implementation matches the system’s intended security story.

What reasoning adds

A code model does not discover vulnerabilities by randomly walking the input space. It reads structure: which values an attacker controls, which invariants a function assumes, which checks are supposed to enforce those invariants, and where similar code handled the edge case differently. That is the same broad mechanism behind transformer reasoning, applied to source code and tool output instead of word problems.

Big Sleep’s SQLite result is a clean example because Project Zero published the method. The agent was given recent SQLite commits, including the details of a previously fixed issue, and asked to look for related mistakes at the repository head. It did not simply ask for “bugs in SQLite.” It performed seeded variant analysis: this bug existed once; find the nearby code where the same assumption might still be wrong.

Google’s July 2025 CVE-2025-6965 example shows the same pattern under threat pressure. Based on Google Threat Intelligence, Big Sleep identified a SQLite memory-corruption flaw before anticipated in-the-wild use. Google said this was the first time an AI agent directly foiled efforts to exploit a vulnerability in the wild. The CVSS details are worth stating precisely: NVD lists Google’s CNA CVSS v4.0 base score as 7.2 High, while NVD’s own CVSS v3.1 enrichment is 9.8 Critical.

Anthropic’s Mythos Preview shows the same frontier from a different angle. Anthropic says Mythos found a 27-year-old OpenBSD TCP SACK denial-of-service issue and autonomously found and exploited a 17-year-old FreeBSD NFS remote-code-execution bug. XBOW’s public HackerOne run is the web-application analogue: the company says its autonomous pentester reached the top of HackerOne’s U.S. leaderboard and submitted nearly 1,060 vulnerabilities, with human review before submission for policy compliance.

Those examples do not mean a model “holds a whole codebase in context” in the literal sense. Public systems usually build repository context in stages: retrieval, threat modeling, commit scanning, source browsing, tool calls, logs, test runs, and repeated narrowing. The KV-cache economics of long context still apply. What changed is that agents can construct enough working context to reason about the security question at hand, then call the tools that give the answer teeth.

The deployable loop

Reasoning is not enough to ship. A model that produces a hundred plausible vulnerability reports, most of them wrong, is a burden. The deployable shape is a loop:

1. Build repository context and a threat model.
2. Search for candidate vulnerabilities against that model.
3. Reproduce or validate candidates in a controlled environment.
4. Generate a patch, test, or remediation path.
5. Route evidence and code to humans for review, disclosure, and merge.

OpenAI’s Aardvark made the design philosophy explicit in October 2025. OpenAI said it did not rely on traditional program analysis techniques like fuzzing or software composition analysis, but on LLM reasoning and tool use. The more important product move came later: Codex Security, formerly Aardvark, puts the loop into developer workflow. In its March 2026 research preview, OpenAI said Codex Security builds a project-specific threat model, prioritizes and validates issues, and proposes patches with system context.

On June 22, 2026, OpenAI expanded that into Daybreak and Patch the Planet. The details matter because they reinforce the lesson from the research report: discovery alone does not make software safer. OpenAI’s public Daybreak description centers the full remediation loop: validated findings, tested patches, coordinated disclosure, maintainer review, and fixes that land. Patch the Planet adds expert review from Trail of Bits and maintainers before findings turn into project changes.

That is the right product shape. The model is not the security team. It is the hypothesis generator, context builder, patch drafter, and repetitive verifier inside a pipeline where evidence still matters and humans still own the risk.

Why validation decides whether this is usable

Critical bugs are rare. OpenAI reported that, over a 30-day Codex Security beta window, it scanned more than 1.2 million commits and found critical issues in under 0.1% of them. Treat that as a rough prevalence, $p = 0.001$.

Now suppose a detector catches 80% of the real critical bugs, so recall $t = 0.8$, and falsely flags only 1% of clean commits, so false-positive rate $f = 0.01$. Those numbers are hypothetical. They are not OpenAI’s reported detector characteristics. The precision, meaning the share of alerts that are real, is:

Source: precision = (p*t) / (p*t + (1-p)*f)

Plug in $p = 0.001$, $t = 0.8$, and $f = 0.01$:

A 1% false-positive rate sounds excellent until the base rate is this low. Fewer than 8% of alerts would be real. Nobody keeps reading at that hit rate.

Validation is the lever. If sandbox reproduction, test generation, exploit confirmation, or dynamic evidence drives the effective false-positive rate down to $f = 0.0005$, the same calculation becomes:

That second number is illustrative too. The measured public claim is more conservative: OpenAI reported false-positive rates falling by more than 50% across repositories and over-reported severity falling by more than 90% during the Codex Security preview. Still, the lesson is the same. The hard product problem is not “can the model name possible bugs?” It is “can the system present few enough wrong findings that a reviewer keeps trusting it?”

The benchmark picture

The best public benchmarks make the same point. The field is moving quickly, but general autonomous exploitation is still uneven and heavily scaffold-dependent.

Those scores explain why one-off examples can be both real and misleading. A system can find a major SQLite bug, top a leaderboard slice, or generate a convincing exploit in one environment, while still failing on most benchmark tasks. The capability is real. The reliability is not yet universal.

The slope matters too. The UK AI Safety Institute’s April 2026 evaluation used 95 capture-the-flag tasks across four difficulty tiers. On Expert tasks, GPT-5.5 reached a 71.4% average pass rate, compared with 52.4% for GPT-5.4 and 68.6% for Anthropic’s Mythos Preview. That is an average pass-rate comparison under AISI’s setup, not the same thing as OpenAI’s separate pass@1 or pass@5 reporting. Keeping those metrics separate is the difference between reading benchmarks and laundering them into a headline.

DARPA’s AI Cyber Challenge shows what purpose-built systems can do when the loop is engineered end to end. At the August 2025 final, competing Cyber Reasoning Systems worked across roughly 54 million lines of code, found 54 of 63 injected vulnerabilities, patched 43, and identified 18 real, non-synthetic bugs. The official AIxCC summary also reported about 45 minutes and $152 per competition task on average. That is not “cents per commit.” It is a different unit, in a high-scaffold competition setting. It is still a meaningful signal: validation and patching are becoming automatable parts of the workflow, not just research theater.

The ceiling

There is still a line current public systems have not cleanly crossed. OpenAI’s GPT-5.5 system card rates the model as High capability in cybersecurity but below Critical. OpenAI defines the Critical threshold as the ability to identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention, or to execute end-to-end novel cyberattack strategies against hardened targets from a high-level goal. GPT-5.5 did not meet that threshold in OpenAI’s testing.

The gap is between finding a bug and weaponizing one. Recognizing an underflow, use-after-free, missing authorization check, or integer truncation is one thing. Turning it into a reliable exploit chain against a hardened target is another: defeating ASLR, stack canaries, allocator hardening, sandboxing, privilege boundaries, race timing, logging, crash limits, and unknown production state. Mythos shows that models can sometimes cross that gap. The benchmarks show that they do not do it reliably across arbitrary targets.

That distinction is why labs are building gates around the most permissive cyber models and why OpenAI’s Daybreak language keeps returning to authorization, monitoring, scoped controls, human review, and coordinated disclosure. The ability is useful enough to deploy for defenders and dangerous enough to control.

What changes for defenders

For two decades, security ran on an asymmetry: attackers needed one exploitable bug; defenders needed to find and fix all of them. AI does not erase that asymmetry. It changes the throughput on the discovery side.

The practical implication is not that every company needs a frontier cyber model tomorrow. It is that vulnerability discovery is becoming continuous, agentic, and cheaper than the human process it augments. That helps defenders only if the rest of the system can absorb the output. A pile of plausible findings is not security. A validated finding with a tested patch, an owner, a disclosure plan, and a merge path is security work.

That is why the frontier labs are converging on the same architecture: repository context, hypothesis generation, tool-assisted validation, patch generation, and human review. Traditional tools still feed the loop. Fuzzers find crashes. SAST finds source-to-sink paths. Symbolic execution proves narrow cases. LLM agents connect those signals to intent and ask better follow-up questions.

The bottleneck moves downstream. The winning defensive systems will not be the ones that produce the most findings. They will be the ones that keep precision high, reproduce issues safely, generate patches that maintainers can trust, and land fixes faster than attackers can turn the same class of capability against the code.

Sources

• Google Project Zero, From Naptime to Big Sleep — projectzero.google
• Google, A summer of security: empowering cyber defenders with AI — blog.google
• NVD, CVE-2025-6965 Detail — nvd.nist.gov
• OpenAI, Introducing Aardvark — openai.com
• OpenAI, Codex Security: now in research preview — openai.com
• OpenAI, Daybreak: Tools for securing every organization in the world — openai.com
• OpenAI, Patch the Planet: a Daybreak initiative to support open source maintainers — openai.com
• OpenAI, GPT-5.5 System Card: Cybersecurity — deploymentsafety.openai.com
• Anthropic, Assessing Claude Mythos Preview’s cybersecurity capabilities — red.anthropic.com
• XBOW, The road to Top 1: How XBOW did it — xbow.com
• DARPA, AI Cyber Challenge marks pivotal inflection point for cyber defense — darpa.mil
• Wang et al., CyberGym: Evaluating AI Agents’ Real-World Cybersecurity Capabilities at Scale — arXiv 2506.02548
• Lee et al., SEC-bench: Automated Benchmarking of LLM Agents on Real-World Software Security Tasks — arXiv 2506.11791
• Zhu et al., CVE-Bench: A Benchmark for AI Agents’ Ability to Exploit Real-World Web Application Vulnerabilities — arXiv 2503.17332
• Bhatt et al., CyberSecEval 2: A Wide-Ranging Cybersecurity Evaluation Suite for Large Language Models — arXiv 2404.13161
• LLVM, libFuzzer documentation — llvm.org
• Semgrep, Write rules — docs.semgrep.dev
• GitHub, About CodeQL — codeql.github.com
• UK AI Safety Institute, Our evaluation of OpenAI’s GPT-5.5 cyber capabilities — aisi.gov.uk