curl Killed Its Bug Bounty Because AI Made Security Reports Worthless
Daniel Stenberg has read more fake vulnerability reports than almost anyone alive, and by January 2026 he'd had enough. curl — the command-line tool and library that quietly moves data for a meaningful share of the internet's infrastructure, from your phone's app updates to spacecraft telemetry — shut down its paid bug bounty program. Not because the software got safer. Because the reports got worthless, and telling the difference between a worthless one and a real one had started costing more than the bounty itself.
The story everyone tells about AI and security is either "AI finds vulnerabilities humans miss" or "AI writes vulnerable code." Both are true and both miss what actually happened to curl. This is a third failure mode, and it's uglier than either: AI made it free to generate something that looks like a real report, and volunteer-run infrastructure has no defense against unlimited plausible noise.
The Vulnerability Report Pipeline Wasn't Built for Infinite Fake Signal
curl's bug bounty ran through HackerOne for years, paying out real money for real, confirmed CVEs. It worked because submitting a report cost something — time, expertise, the effort of actually reading source code and constructing a proof of concept. That cost was the filter. Most people who bothered to submit a curl vulnerability report had done real work first.
Large language models deleted that cost. Point a model at curl's source, ask it to "find a security vulnerability and write it up like a HackerOne report," and it will produce something structurally perfect — CVE-style formatting, a plausible-sounding CWE classification, a confident description of an exploit path — that is completely fictional. It reads like the real thing to a bounty reviewer skimming a queue, and only falls apart when someone tries to actually reproduce it.
Stenberg documented the collapse in a January 26, 2026 post: the share of submissions that turned out to be real, confirmed vulnerabilities had fallen from roughly 15% before the AI-slop wave to under 5%. That's not a modest dip in quality. That's a queue where the average submission went from "probably worth investigating" to "probably not," which inverts the entire economics of triage. LWN and The Register both picked up the story within days, and the framing across the coverage converged on the same phrase: AI slop, not AI attacks.
Why "Just Use AI to Filter It" Doesn't Work Here
The obvious rebuttal is: fine, use another AI to pre-screen the reports before a human sees them. This is where the problem gets structurally worse instead of better, and it's worth sitting with why.
A fabricated report generated by an LLM is optimized, whether intentionally or not, to look like the thing a screening classifier is trained to recognize as legitimate. It has the right shape. Detecting "this report was AI-generated" is a much harder and more adversarial problem than detecting "this report describes a real bug," because the first is a stylistic arms race and the second is a question with a ground-truth answer you can only get by actually running the exploit. You end up needing the exact same expensive human verification step you were trying to avoid — except now you're running it on a queue where the ratio of noise to signal is three times worse than it used to be.
By July and August 2026, curl had stopped accepting security reports altogether for stretches at a time — Stenberg logged twenty submissions across three weeks in that window, almost none of them credible, and at one point the project went days without a single valid report landing. This is a maintainer-hours problem wearing a security-policy costume. curl didn't get less secure. It got more expensive to keep secure, and the person paying that cost was one unpaid volunteer.
This isn't the first time an open-source security program has buckled under maintainer strain rather than technical failure — the xz backdoor happened for adjacent reasons: a burned-out maintainer, a supply chain nobody was watching closely enough. Different mechanism, same underlying fracture line.
The Attack Surface Isn't the Code Anymore — It's the Triage Queue
Here's the reframe worth sitting with: for thirty years, "attack surface" meant the code itself — the parsers, the buffer boundaries, the places an attacker could get unintended behavior out of a program. curl's response to that kind of attack surface is excellent; it's one of the most audited C codebases in existence, with a security process that predates most companies' security teams.
What nobody built a defense for is an attack on the triage process itself — flooding the human verification layer until it can no longer function economically, without ever touching a line of curl's code. You don't need a zero-day to hurt curl's security posture anymore. You need a text generator and the willingness to hit submit twenty times. The vulnerability isn't in the software. It's in the fact that verifying a claim about software requires human judgment, and human judgment doesn't scale the way LLM-generated claims do.
This generalizes past curl. Every project running a bug bounty, every company with a public disclosure inbox, every open-source maintainer accepting pull requests is sitting on the same unguarded surface: a process that assumes submissions cost something to produce. That assumption held for twenty years. It stopped holding sometime in 2025, and most projects haven't noticed yet because they haven't been targeted — intentionally or not — at curl's scale.
What a Rational Response Actually Looks Like
curl's answer was blunt: stop paying for something that no longer functions as a market. Suspending the bounty removes the financial incentive that made mass-generating fake reports even marginally worth someone's time, and it's a defensible triage decision for a project run by volunteers who have other jobs. But it's also a retreat, not a fix — it trades "expensive fake signal" for "no signal," and a project curl's size can't run indefinitely on GitHub issues and personal vetting alone.
The harder, more interesting question is what a triage system built for this era would actually look like. Not "AI to catch AI" — we've established that's circular. More likely: a return to reputation-gated submission, where new or unverified submitters face friction (a refundable stake, a sponsor, a track record) before a report reaches a human queue at all — the same mechanism spam email eventually forced on unauthenticated senders. It's a worse experience for legitimate first-time researchers, which is the actual cost nobody wants to pay, and probably the reason curl hasn't done it yet either.
The Real Lesson Isn't About curl
curl is a bellwether, not an outlier. It has one of the most professional, best-resourced security processes in open source, run by someone who has been doing this specific job for over two decades. If Stenberg's process buckled under AI-generated submission volume, the calculus is much worse for the median open-source project maintained by two people in their spare time with no bounty program, no HackerOne integration, and no public post explaining what happened when they simply stopped answering their security inbox.
The infrastructure the internet runs on was built on an assumption that reporting a bug costs more than filing one falsely. That assumption is now false, and the bill is coming due one maintainer at a time.
Cover photo by Tima Miroshnichenko via Pexels.