How AI Finds Zero-Days: Machine-Speed Vulnerability Research

A zero-day used to require a human expert who understood a codebase well enough to notice the one line of logic that didn't hold. That expert might spend weeks staring at a parser or a memory allocator before something clicked. AI systems now do a version of that same work in hours, running in parallel across thousands of code paths, and they don't get tired of reading the same function twenty times. The tools built to find these bugs before criminals do are now good enough that criminals are using them too.

That shift — from AI-assisted research as a defensive curiosity to AI-assisted research as an attacker capability — is the story of the last two years in vulnerability discovery. This post explains what's actually happening under the hood when AI finds zero-day vulnerabilities, why the balance of who benefits is changing, what it means for anyone who ships or defends software, and how to start running the same class of tooling against your own code before someone else does.

What "AI finding a zero-day" actually means

A zero-day is a vulnerability the vendor doesn't know about and hasn't patched. "AI finds a zero-day" doesn't mean a model reads source code and has a flash of insight — it means an AI system, usually a large language model wired into a set of tools, runs an investigative loop that used to require a human security researcher at the keyboard.

That loop generally involves the model doing some combination of:

• Reading and summarizing unfamiliar code to build a mental model of what a function is supposed to do
• Forming hypotheses about where that logic might diverge from the assumption ("this bounds check assumes the buffer was already validated upstream — is it?")
• Writing test harnesses, fuzzers, or proof-of-concept inputs to probe those hypotheses
• Running the code, reading the crash or the sanitizer output, and reasoning about whether it's exploitable
• Iterating — refining the hypothesis, writing a better harness, trying a different input — dozens or hundreds of times

None of these steps are individually new. Fuzzing has existed since the 1980s. Static analysis tools have flagged suspicious patterns for decades. What's new is that a language model can now drive that entire loop with minimal human steering, reading unfamiliar code with something closer to human comprehension rather than pattern-matching against known bug signatures.

The difference from traditional fuzzing

Traditional fuzzers are dumb in a specific, useful way: they throw huge volumes of mutated input at a program and wait for it to crash, with no understanding of what the code is trying to do. That works well for shallow bugs reachable from simple inputs, but it struggles with logic bugs that require a specific, structured sequence of operations to trigger — the kind that require actually understanding the program.

An LLM-guided approach adds a layer of reasoning on top of that brute force. The model reads the code, decides which functions look risky, writes a fuzz harness targeted at that function specifically, and — critically — can look at why a fuzzer failed to find anything and adjust its strategy. That's the part a coverage-guided fuzzer alone can't do.

How the pipeline actually works

Most of the credible systems in this space, from Google's Big Sleep project (built on the earlier Project Naptime work) to the entrants in DARPA's AI Cyber Challenge, follow a broadly similar architecture even though the implementation details differ.

1. Target selection. The system is pointed at a codebase, a specific commit diff, or a binary. Diffs are a common starting point because a code change is a concentrated source of new bugs — something worked yesterday and might not today.
2. Comprehension. The model builds a working understanding of the relevant code: what calls what, what invariants are assumed, where untrusted input enters the system, and where it flows.
3. Hypothesis generation. The model proposes specific, falsifiable theories about where a bug might live — an integer overflow in a size calculation, a use-after-free in an error path, a missing authorization check on a secondary route.
4. Tool-assisted verification. The model writes code — test cases, fuzz harnesses, symbolic execution constraints, or simple exploit attempts — and executes it in a sandboxed environment to check the hypothesis.
5. Triage and refinement. Crashes get inspected. Most crashes are not exploitable, so the system (or a human reviewer) has to work out whether a given crash reflects a real, weaponizable vulnerability or a benign fault.
6. Reporting or exploitation. In defensive use, this ends with a report and, ideally, a patch suggestion. In offensive use — whether by a red team or an attacker — it can end with a working exploit.

That last step is the entire ballgame. The same pipeline, pointed at the same target, produces either a bug bounty submission or a weapon, depending only on who's running it and what they do with the output.

Why this needs agentic tooling, not just a bigger model

A model that can only respond to a single prompt with a single answer can't do this work. Vulnerability research is inherently iterative: you try something, it doesn't work, you learn from the failure, you try something else. That requires an agent loop — a model that can call tools (a compiler, a debugger, a fuzzer, a shell), observe the results, and decide what to do next, repeated automatically across many cycles without a human approving each step.

This is also why the recent jump in capability tracks the broader rise of agentic AI systems more than it tracks raw model scale. A more capable base model helps, but the bigger unlock has been giving models reliable tool access, longer effective context for holding a codebase's structure in mind, and enough autonomy to run for hundreds of steps unsupervised.

Why it matters right now

For most of this technology's life, the headline use cases were defensive. Google's Big Sleep team used an AI agent to find a real, previously unknown vulnerability in SQLite before it shipped — a textbook example of AI catching a bug earlier in the pipeline than traditional testing would have. Continuous fuzzing infrastructure like OSS-Fuzz started incorporating LLM-generated harnesses to reach code paths human-written fuzz targets never touched. The framing was consistently: this makes defenders faster than attackers, because defenders can run this at scale across their own codebase before release.

That framing changed when Google documented the first known criminal use of AI to discover and exploit a zero-day, in May 2026. The capability that had been demonstrated in a defensive research context — an AI agent autonomously finding and weaponizing a previously unknown vulnerability — showed up on the other side of the table, used by an actual criminal actor against a live target rather than a lab environment.

The significance isn't that AI-found exploits suddenly became possible; the SQLite discovery and similar defensive research had already proven the mechanics worked. The significance is that the barrier to using this capability offensively — cost, expertise, tooling maturity — dropped low enough for it to happen in the wild, outside a research team with a responsible disclosure process. That's the pattern with most dual-use offensive-security tooling: it gets built and refined for defense, and the same technique eventually gets pointed the other way once it's mature and accessible enough.

For security teams, this collapses the old assumption that AI-driven vulnerability research was mainly a "we should adopt this eventually" conversation. It's now also a "the other side already has it" conversation, and those run on different timelines.

Benefits of AI-Driven Vulnerability Discovery

For defenders who adopt it, the same pipeline that worries security teams in an attacker's hands becomes a substantial advantage. These are the gains that follow from running it against your own code continuously, rather than as an occasional audit.

Deep Code Review at a Scale Humans Cannot Match

Expert vulnerability researchers are scarce, and none of them can read every function in a large codebase. An agentic system can work through thousands of code paths in parallel, forming and testing hypotheses about each. That does not replace human expertise, but it extends deep, comprehension-based review to code that would otherwise never get a specialist's attention, including old modules nobody on the current team wrote.

Bugs Found Before Release

The SQLite example shows the defensive pattern: a vulnerability caught before the code shipped, at the point where fixing it is cheapest and nobody outside the team knows it exists. Running the pipeline against diffs in CI moves discovery to the pull request, rather than to an incident report or a researcher's disclosure months later.

Reaching Code Fuzzers Never Touched

Coverage-guided fuzzing only explores what its harnesses can reach. Writing those harnesses is skilled, tedious work, so many functions never get one. LLM-generated harnesses extend fuzzing into those untested corners, and the model can look at why a fuzzer found nothing and adjust its approach, which a fuzzer alone cannot do. Coverage grows without a matching growth in specialist hours.

Matching the Attacker's Speed

Once attackers can scan a public diff within hours, a defender relying on periodic manual audits is structurally behind. Running the same class of tooling continuously closes that gap. Defenders keep a built-in advantage, since they have source code, build systems, and test environments that outsiders lack, but only if they actually use those assets at machine speed.

Better Use of Scarce Security Staff

When automated discovery and first-pass triage handle the volume, human security engineers spend more time on the work that needs judgment: assessing exploitability, designing fixes, and reviewing authorization and business logic, the bug classes where automated tools are weakest. The tooling handles breadth; people handle depth.

AI Vulnerability Discovery Use Cases

The technique applies wherever code handles untrusted input or changes frequently. These are the most common places teams put it to work today, roughly ordered from the easiest to adopt to the most specialised.

Pull Request and Diff Review

Every code change is a concentrated source of possible new bugs, and attackers now scan public diffs quickly. Teams add an AI review step to each pull request with an explicit security brief covering input validation, authorization, memory handling, and error paths. Findings appear while the author still has context, and fixes land before the change ships. The main challenge is tuning the brief so reviewers are not buried in low-value comments.

Hardening Parsers and Protocol Handlers

File parsers, image and document processors, and network protocol handlers take untrusted input and are often written in memory-unsafe languages. They are the classic home of exploitable crashes. Pointing LLM-guided fuzzing at these components, with harnesses generated for each entry point, is one of the most proven applications, because crashes give the system a clear signal to verify.

Open-Source Dependency Security

Much of any product's code comes from open-source libraries. Projects in OSS-Fuzz already benefit from continuous fuzzing, and LLM-generated harnesses have extended its reach. Companies that maintain or depend heavily on a library can contribute harnesses or run their own pipelines against critical dependencies, finding issues upstream rather than waiting for a public advisory.

Legacy Code Audits

Old, poorly documented systems were partly protected by researcher disinterest, and that protection is eroding. An agentic system will read old C code as patiently as new code. Running a focused audit on legacy components that still handle external input surfaces bugs before an attacker's tooling does, and often produces documentation of how the code actually behaves along the way.

Red Team and Competition Work

Red teams use agentic pipelines to probe their own organization's software as an attacker would, and competitions such as DARPA's AI Cyber Challenge test systems that both find and patch vulnerabilities autonomously. These settings push the technology forward and show which parts of the pipeline are mature enough for routine use.

Common AI Vulnerability Discovery Mistakes

Teams adopting these tools tend to repeat a handful of avoidable errors. Most come from treating AI findings as finished answers rather than as leads that still need a person to confirm them.

Adding AI on Top of a Neglected Baseline

If dependency scanning, secret scanning, and basic static analysis are missing or ignored, AI tooling mostly generates more noise on top of known problems. Fix the cheap, conventional layer first; it catches a large share of issues at little cost and makes the AI findings easier to interpret.

Trusting the Model's Exploitability Verdict

A model can explain convincingly why a crash is exploitable when it is not, or wave away a real bug. Acting on that verdict without reproducing the behaviour leads to wasted fixes on one side and missed vulnerabilities on the other. Verification by a person or a separate, specialised triage step is part of the pipeline, not an optional extra.

Letting the Agent Run Outside a Sandbox

An agent that compiles and executes code needs an isolated environment. Running it with production credentials or network access to internal systems turns a security tool into a risk of its own, especially when it is probing code designed to crash.

Scaling Findings Before Building Triage

Turning the tool on across every repository at once produces a queue nobody can work through. Findings pile up, developers stop reading them, and real issues get lost. Start with one high-risk component, establish who triages and how severity is assigned, then expand.

Measuring Findings Instead of Fixes

A dashboard counting discovered issues looks like progress. What reduces risk is the time from confirmed finding to deployed fix. Teams that track only discovery can end up knowing about more vulnerabilities without being any safer, which is arguably worse than not knowing.

Practical implications for businesses and builders

The immediate question for most organizations isn't "should we build an AI vulnerability research team" — it's "what does this change about our exposure and our defenses starting now."

A few concrete shifts worth planning around:

Some practical takeaways follow directly from this:

• Patch velocity now matters more than patch frequency. If AI-assisted scanning can find bugs in a diff within hours of it becoming public (via a GitHub push, a changelog, or a compiled release), the gap between "vulnerability exists" and "vulnerability is being probed" shrinks. Slow patch cycles are riskier than they used to be.
• Diffs are now a bigger liability surface than they look. A small, seemingly low-risk code change can be exactly the kind of concentrated, comprehensible target these systems are best at analyzing. Treat security review of diffs, not just full codebases, as a priority.
• Legacy code isn't hiding anymore. Old, poorly documented, or unfashionable software used to be safer partly because few humans wanted to research it. That obscurity discount is eroding — an agentic system doesn't get bored reading old C code.
• Defensive adoption is no longer optional to consider. Running the same class of tooling against your own codebase before release — as part of CI, not as an occasional audit — is the most direct way to close the gap between what an attacker's tooling can find and what you already know about.
• Triage capacity becomes the bottleneck. AI-driven scanning, offensive or defensive, produces a lot of candidate findings. Most crash reports are not exploitable. The organizations that benefit most are the ones that can rapidly separate signal from noise — which, again, increasingly means AI-assisted triage on the defensive side too.

None of this requires every company to build a custom agentic security pipeline. It does mean evaluating whether your existing SAST/DAST and fuzzing investment is keeping pace with what's now feasible against you, and whether your patch and disclosure processes assume a slower attacker than the one that now exists.

AI Vulnerability Discovery Best Practices

You don't need a research lab to start benefiting from these techniques. A staged rollout that most engineering teams can manage:

1. Get the basics automated first. Dependency scanning, secret scanning, and a conventional static analyzer in CI catch a large share of known issues cheaply. AI tooling built on top of a noisy, unmaintained baseline mostly produces more noise.
2. Pick a high-value target. Start with code that parses untrusted input, handles authentication, or was written in a memory-unsafe language: file parsers, protocol handlers, API gateways, and image or document processing.
3. Add fuzzing with AI-generated harnesses. Coverage-guided fuzzing remains the workhorse. Using an LLM to write and refine fuzz harnesses for functions nobody has targeted yet is one of the most proven, lowest-risk applications. Open-source projects can apply to OSS-Fuzz for free continuous fuzzing.
4. Run diff-focused review on every pull request. Point an AI review step at the changed code with an explicit security brief: input validation, authorization checks, memory handling, and error paths. Our guide to AI code review in the enterprise covers how to set this up without drowning reviewers.
5. Sandbox anything that executes code. If an agent is allowed to compile, run, and probe software, it should do so in an isolated environment with no production credentials or network access to internal systems.
6. Build a triage path before you scale. Decide who reviews findings, how severity is assigned, and how fixes are tracked. Measure the false-positive rate early so you know whether the tooling is saving time or consuming it.
7. Close the loop with patch velocity. Track the time from confirmed finding to deployed fix. That number matters more than the number of findings.
8. Verify the model's reasoning independently. Before treating a finding as confirmed or dismissing it, reproduce the crash or behaviour yourself and check the exploitability argument. A confident explanation from the model is a hypothesis, not evidence, and the same applies to its claim that something is harmless.

Limitations and open questions

It's worth being precise about what this technology can and can't reliably do today, because the discourse tends to swing between "AI will end software security as we know it" and "this is overhyped and doesn't really work."

False positive rates remain a real cost. Agentic systems generate a lot of candidate crashes and suspicious patterns. Distinguishing an exploitable memory-safety bug from a benign fault, or a genuine logic flaw from a false hypothesis, still requires either a skilled human reviewer or a second AI system trained specifically for triage — and that second layer has its own error rate.

Coverage is uneven across languages and bug classes. Memory-safety bugs in C/C++ — buffer overflows, use-after-free, integer overflows — are relatively well-suited to this approach because the failure mode (a crash) is a clear, machine-checkable signal. Subtle logic bugs, authorization flaws, and business-logic vulnerabilities in higher-level languages are harder, because there's often no crash to detect — the program runs "successfully" while doing the wrong thing.

Compute cost is nontrivial. Running an agentic loop across a large codebase, with many iterations of hypothesis-and-test, consumes real inference budget. That cost is dropping, but it's not yet free enough that "just run it on everything, constantly" is the default for most organizations.

Verification of the AI's own reasoning is still a weak point. A model can produce a plausible-sounding explanation for why a crash is exploitable that turns out to be wrong, or miss the actual exploitability path while fixating on an irrelevant one. Trusting the system's self-reported confidence without independent verification is a known failure mode.

The arms race framing cuts both ways, and nobody has a clean lead. Defensive teams have a structural advantage — they know their own code, have access to source and build systems, and can run continuously in CI. Attackers have the advantage of only needing to find one exploitable bug rather than closing all of them. AI tooling doesn't change that fundamental asymmetry; it just makes both sides faster at their respective jobs.

What to watch next

A few developments will tell you where this is heading faster than any single research paper:

1. Results from adversarial evaluations like DARPA's AI Cyber Challenge, where AI systems compete to both find and patch vulnerabilities autonomously under controlled conditions — a useful proxy for how mature the automated patch-generation side of the pipeline is, not just the discovery side.
2. Whether "find and patch" becomes a single automated pipeline. Discovery has moved faster than remediation. An agent that can propose a validated, minimal patch alongside a vulnerability report — not just a bug report — closes the loop and removes a major bottleneck.
3. Regulatory and disclosure norms catching up. Coordinated disclosure timelines, CVE processes, and vendor SLAs were built around a human research cadence. Whether those processes adapt to machine-speed discovery, on both the reporting and patching sides, is still an open institutional question.
4. How widely offensive use spreads beyond well-resourced actors. The May 2026 case documented by Google involved a single actor; the more important question is how quickly the same capability becomes accessible to less sophisticated criminal groups, the way commodity exploit kits did after novel techniques were first demonstrated by advanced actors.
5. Whether AI-assisted defense becomes standard in CI, not just at big tech companies. The organizations running Big Sleep-style tooling today are mostly well-resourced. Whether this becomes accessible enough for mid-sized engineering teams to run routinely will shape how uneven the defensive landscape stays.

Security teams evaluating where AI-driven testing fits into their own release pipeline can get hands-on help from Woyce Technologies.

FAQ

Can AI actually discover vulnerabilities that humans have missed?

Yes — Google's Big Sleep project, for example, used an AI agent to find a previously unknown vulnerability in SQLite that had gone undetected through conventional testing. This isn't hypothetical; it's a documented, reproducible category of result, though it's strongest for memory-safety bugs rather than complex business-logic flaws. That's because a crash gives the system an unambiguous signal to verify against.

Is AI-driven vulnerability discovery the same thing as fuzzing?

No, though they're related. Traditional fuzzing mutates inputs blindly based on code coverage feedback, with no understanding of what the program does. AI-driven approaches add a reasoning layer that reads the code, forms hypotheses about where bugs are likely to live, and then often uses fuzzing or targeted testing as one tool among several to verify those hypotheses.

How did criminals get access to this capability?

The underlying techniques — agentic tool use, code comprehension, automated hypothesis testing — are largely the same ones published and demonstrated in defensive security research. Google's May 2026 disclosure documented the first known instance of that same class of capability being used by a criminal actor to find and exploit a real zero-day, rather than by a research team following responsible disclosure.

Does this mean traditional security testing is obsolete?

No. AI-driven discovery is best understood as an addition to the existing toolkit — static analysis, code review, penetration testing, coverage-guided fuzzing — not a replacement for it. It's particularly strong at scaling the kind of deep code comprehension that used to require a scarce human specialist, but it still benefits from human oversight for triage and verification.

What can a smaller company realistically do about this?

Prioritize patch velocity for known vulnerabilities, treat code diffs (not just full releases) as a security review surface, and evaluate whether existing fuzzing or static analysis tooling has AI-assisted options that fit within CI. You don't need to build a custom agentic research pipeline to benefit from the same underlying shift toward faster, more automated testing.

Is this only relevant to memory-safety languages like C and C++?

Most of the clearest public results are in memory-safety bug classes because a crash is an unambiguous, machine-verifiable signal that something went wrong. Logic and authorization bugs in higher-level languages are an active area of research but are harder for these systems to verify automatically, since there's often no crash to point to.

Will patching also become AI-driven, not just discovery?

That's the direction most serious efforts, including DARPA's AI Cyber Challenge, are pushing toward — pairing automated discovery with automated, verifiable patch generation. It's less mature than discovery today, largely because a bad automated patch can break functionality in ways that are harder to catch than a bad bug report.

How much does AI-driven vulnerability scanning cost?

Costs vary with scope. Open-source fuzzing frameworks are free, and commercial code-scanning products with AI features are typically priced per developer or per repository. Running your own agentic pipeline means paying for model inference, which scales with codebase size and the number of iterations per target, plus compute for sandboxed execution. The largest hidden cost is usually human triage time, so a tool with a lower false-positive rate can be cheaper overall even if its license costs more.

Conclusion

Finding a zero-day used to depend on scarce human expertise and weeks of patient reading. Agentic AI systems that read code, form hypotheses, write harnesses, and test them in a loop have compressed that work dramatically, and the first documented criminal use in 2026 confirmed that the capability is no longer limited to defensive research teams.

The important shifts are practical. Code diffs become a concentrated attack surface the moment they're public. Obscure legacy code no longer benefits from human disinterest. Patch velocity matters more than ever, and triage capacity, not discovery, becomes the bottleneck for defenders.

The technology still has clear limits. It's strongest on memory-safety bugs where a crash gives a clean signal and weaker on business-logic and authorization flaws. False positives cost real time, and a model's confident explanation of exploitability can be wrong. Defenders keep a structural advantage in source access and continuous CI, but only if they use it.

The sensible next step is to pick one high-risk component, add AI-assisted fuzzing or diff review to its CI pipeline, and measure findings, false positives, and time to fix. If you'd like help designing that pipeline and the sandboxing around it, our DevOps engineering team can help.