How are AI agents finding zero-days at scale?

In March and April 2026, maintainers of the Linux kernel and curl described the same change: far more of the security reports that people made with AI tools now pointed to real bugs. Willy Tarreau wrote on LWN that the kernel security list received 2 or 3 reports a week about two years earlier, and 5 to 10 a day since the start of 2026, most of them correct. Security researcher Thomas Ptacek explains why: "You can't design a better problem for an LLM agent than exploitation research."

What changed in early 2026?

From the second half of 2024, open-source projects received a growing stream of "AI slop": reports written with AI tools about bugs that did not exist. curl ended its bug bounty, which paid people for reporting vulnerabilities, on 31 January 2026. Its lead developer Daniel Stenberg wrote that in earlier years more than 15% of submissions turned out to be real vulnerabilities, and that in 2025 the rate fell below 5%. Besides weaker reports from humans, he blamed "an explosion in AI slop reports".

Weeks later the picture had changed. Linux kernel maintainer Greg Kroah-Hartman told The Register on 26 March 2026: "Something happened a month ago, and the world switched. Now we have real reports." In his words, all open-source security teams see the same shift, and nobody knows the cause: "Either a lot more tools got a lot better, or people started going, 'Hey, let's start looking at this.'"

On 2 April, Stenberg wrote on Mastodon that the "AI slop tsunami" had turned into "more of a ... plain security report tsunami", with "many of them really good".

Why are AI agents so good at finding vulnerabilities?

Ptacek, who spent 15 years finding and exploiting vulnerabilities for a living, set out his argument on 30 March 2026 in "Vulnerability Research Is Cooked". He expects much of the high-impact work to happen by pointing an AI agent at a source tree and asking it to find zero-days: flaws the maintainers do not know about yet, so they have had zero days to fix them.

His reasons start with what a large language model already knows. Before it sees a single token of your code, it holds correlations across vast amounts of source code: it knows whether the Linux KVM hypervisor is connected to the hrtimer subsystem, workqueue or perf_event. Its weights also contain the documented bug classes that exploit development builds on, such as stale pointers, integer mishandling, type confusion and allocator grooming.

Finding vulnerabilities, Ptacek writes, comes down to "pattern-matching bug classes and constraint-solving for reachability and exploitability": does a known kind of bug occur here, and can an attacker reach it and abuse it? Whether an exploit works is a plain success-or-failure test. And "an agent never gets bored and will search forever if you tell it to."

Software has so far been protected partly by a scarcity of elite attention, in his view. Skilled researchers aim at valuable targets such as browsers, while many unglamorous targets "have never even seen a fuzzer", a tool that bombards a program with random input. Agents make that attention cheap.

How simple can the method be?

Ptacek describes the approach of Nicholas Carlini of Anthropic's Frontier Red Team. Carlini runs a short script that gives Claude Code the same prompt for every source file in a repository: find an exploitable vulnerability, start with this file, write a report. He then feeds each report back to Claude Code and asks it to verify that the bug is exploitable. According to Ptacek, the success rate of that pipeline is "almost 100%". Aimed at the content management system Ghost, it found a broadly exploitable SQL injection.

Anthropic's Frontier Red Team reported on 5 February 2026 that Claude Opus 4.6 had found and validated more than 500 high-severity vulnerabilities in open-source software. The model worked in a virtual machine with standard tools such as debuggers and fuzzers, without special instructions and without a custom harness, the extra software that would have given it specialist knowledge. To avoid adding to the slop, Anthropic's own security researchers, and later outside researchers, validated every bug before it was reported.

What does this mean for maintainers?

On the kernel list, according to Tarreau, the team had to bring in more maintainers. He also saw something daily that had never happened before: duplicate reports, the same bug found by two people using slightly different tools. Stenberg wrote that he was spending "hours per day" on reports. Kroah-Hartman said the kernel, with its large and distributed team, could handle the increase, and that all open-source projects needed help with it. He described the bugs as "tiny things, they're not major things".

The kernel also uses AI on the receiving end. According to Kroah-Hartman, Sashiko, a review tool that Google built and donated to the Linux Foundation, was running on almost all kernel patches in March 2026. He added that it does not catch everything, and that some of its remarks are wrong.

Ptacek sees the larger risk outside the well-funded projects. When finding bugs costs almost nothing, attackers no longer need to choose their targets: operating systems, databases, routers and printers all become worth a look. Such systems run "in every regional bank and hospital chain in North America", and patching them can mean that someone has to drive there and push a physical button.

Is this a lasting change?

Ptacek thinks the outcome is "locked in" and expects agents to generate full-chain exploits: several bugs chained into one complete attack. None of the veteran researchers he consulted disputed the direction. A friend at a big vendor doubted it would be that easy, because layered defenses such as hardened allocators, sandboxes, user/kernel barriers and virtualization keep exploits hard to build, even once agents make vulnerabilities easy to find. Another researcher points out that models reproduce documented technique, and that a lot of technique was never written down.

Tarreau did not know how long the pace would last. He suspected that bugs were being reported faster than they were written, so the flood might partly be a long backlog being cleared. Kroah-Hartman said the increase was "not slowing down".

What should maintainers and developers do?

• Scan your own code before someone else does. Ptacek reports that some researchers already run simple agent loops over old targets and find high-severity bugs they had missed.
• Give reporters a clear private channel. Since the end of its bug bounty, curl takes security reports through GitHub's private vulnerability reporting and pays no rewards for them.
• Use AI to review what comes in, as the kernel does with Sashiko, and have a person check what it flags.
• Update more often. Tarreau expects embargoes, the agreed delay before a bug is made public, to disappear, and calls periodic updates "the only sane way to stay safe".
• Plan for maintenance. In Tarreau's view, software that is released and then left alone will have to change, because every piece of software becomes a target.