The Verification Bottleneck: Why AI Found 12 OpenSSL Zero-Days While Curl Killed Its Bug Bounty

In a single week in early 2026, two things happened in the open source security world that, taken together, tell you almost everything you need to know about where this is headed.

On January 26, curl maintainer Daniel Stenberg announced he was ending the curl bug bounty program. After seven years and more than ninety thousand dollars paid out for eighty-one verified vulnerabilities, the program had been overwhelmed by the cost of triaging AI-generated noise. That same week, the AI security research firm AISLE published results showing their AI vulnerability discovery system had identified 12 of 12 CVEs in a single recent curl release, plus a string of additional verified zero-days across OpenSSL.

Same general technology — AI systems scanning codebases for vulnerability patterns. Same project ecosystem. Two completely opposite outcomes. The difference between them is the entire story of where open source security is going in the AI era, and the bottleneck that's going to define what gets fixed and what doesn't.

That bottleneck is verification.

‍

The two ends of the AI vulnerability discovery curve

To understand what's happening, you have to hold both stories in your head at once.

The good end: AI-assisted vulnerability research, when run by an operator who knows what they're doing and invests in verification, is producing real, exploitable, previously-undiscovered CVEs at a rate that human researchers alone could not match. AISLE's work on curl and OpenSSL is one example. There are others — major cloud providers and security vendors are using AI tooling internally for vulnerability discovery and getting real results.

The bad end: The exact same capability, in less careful hands, is producing high volumes of plausible-looking reports that don't hold up under scrutiny. Stenberg's public accounting of the curl program put AI slop at roughly 20% of submissions in 2025, with only 5% of total submissions turning out to be genuine. The cost of triaging the noise eventually exceeded the value of the program.

Both of these things are now true at once. The pipeline that delivers verified zero-days to a maintainer's inbox is the same pipeline delivering hallucinated vulnerability reports to it. From the maintainer's seat, every inbound submission is unknown until verified.

That verification step is the new bottleneck in open source security.

‍

Why verification is the bottleneck (and not patching)

This is the part that most enterprise security strategies haven't caught up to.

The traditional model of open source vulnerability response assumes the work scales roughly linearly: more vulnerabilities means more patches, which means more engineering time. The implicit assumption is that finding the vulnerability and fixing it are roughly comparable in difficulty.

AI vulnerability discovery breaks that assumption. Finding has been radically accelerated. Fixing has not — verification, root-cause analysis, patch development, regression testing, and release coordination still happen at human pace. The result is a queue that grows faster than it can be drained.

A few specific consequences:

Maintainers become triage-bound. The work they did before — patching, releasing, supporting users — gets crowded out by the work of evaluating inbound reports. The most overworked maintainers are the ones running the most popular projects, which is to say, the ones in your stack.

Programs that paid for volume now pay for verification. Bug bounty programs were designed for an era when submitting a report cost the submitter real time and effort. That economic premise is breaking down. Expect to see more programs follow curl's lead — either shutting down, requiring working proof-of-concept code, or radically restructuring incentives.

Quality of the CVE record degrades. When the rate of disclosures outpaces the rate of enrichment, you get more CVEs with no severity score, no affected version range, and no context. Sonatype's 2026 State of the Software Supply Chain report found the unscored CVE count has grown 37x in five years while the total CVE count has only doubled. Scanners and SCA tools depend on that enrichment data. As it gets thinner, the tools get noisier.

‍

What this means for security teams

The strategic picture is uncomfortable but clear.

If your model for managing open source risk is wait for the SCA scanner to alert me, then triage and patch, you are downstream of two compounding problems: a CVE feed that's getting noisier and slower, and a maintainer ecosystem that's getting more stretched. That model produces longer windows of exposure, more false positives chewing up your team's time, and less reliable signal about which vulnerabilities actually matter.

A few questions worth asking your team:

• For each of our top-twenty open source dependencies, do we know who's responsible for verifying and patching vulnerabilities, and what their actual capacity looks like right now?
• When we get an alert from our SCA tool, what's our current ratio of false positives to genuine actionable findings? Is it getting worse?
• Are we tracking which of our dependencies are still actively maintained — meaning a real human is verifying real reports — versus which have gone quiet?
• For the libraries that are critical to our business, are we relying on volunteer triage capacity, and is that an acceptable risk position?

Those questions don't have universal answers, but they're the right questions to be asking right now.

‍

What replaces volunteer verification at scale

There's no clean answer that doesn't involve money changing hands somewhere. The verification work has to be done by someone, and the AI-CVE surge has pushed that work past the point where volunteer capacity can absorb it.

A few of the directions this is going:

Commercial backstops for critical libraries. This is the model HeroDevs operates: we partner with maintainers to provide ongoing verification, backporting, and patching for end-of-life and high-risk open source libraries. The maintainer keeps doing what they want to do; the verification load gets absorbed by paid professionals. Enterprises consuming the library get an SLA.

Foundation-funded triage capacity. Apache, the OpenJS Foundation, and others are increasingly funding maintainer time directly. The Linux Foundation's recent open source security funding initiatives are a piece of this. The dollar figures are still small relative to the scope of the problem, but the direction is right.

AI-assisted maintainer tooling. As LLM-based triage tools get better, some of the verification work itself can be automated. This is early. Expect a long tail of false starts before this materially shifts maintainer capacity.

The honest answer is that none of these alone is enough. The AI-CVE surge is a structural shift in the economics of open source security, and the response will need to be structural too.

‍

In short

The verification bottleneck is the defining constraint of open source security in the AI era. AI vulnerability discovery has collapsed the cost of finding bugs without doing anything to reduce the cost of verifying or fixing them. The same capability that delivered 12 of 12 OpenSSL zero-days to security teams that wanted them is also the capability that killed the curl bug bounty program. Both stories are true at once, and the gap between them is going to define which projects survive the next eighteen months and which don't.

Our CEO Aaron Mitchell talked through this and the broader strategic picture on Techstrong TV — full interview here. And if you want our weekly read on what's actually moving in open source security, subscribe to the OSS Security Brief.