The curl project paid out more than US$100,000 across 87 confirmed vulnerabilities before founder Daniel Stenberg shut its bug bounty down, and he named the cause in plain terms: AI slop. In his post announcing the end of the curl bug-bounty, Stenberg wrote that the share of submissions that turned out to be confirmed vulnerabilities had for years run north of 15 percent, then in 2025 plummeted to below 5 percent as AI generated vulnerability reports flooded in. The program launched in April 2019 and closed on 31 January 2026. Pull request #20312, titled "BUG-BOUNTY.md: we stop the bug-bounty end of Jan 2026," removed every mention of the bounty and HackerOne from the project.
Why did curl shut down its bug bounty, and how should teams handle AI-generated vulnerability reports? curl closed the program because the flood of AI-generated submissions drowned the real findings and reviewing the noise took a serious toll on maintainers, per Stenberg. The right response for a defender is not to ban AI, because genuinely real AI-found vulnerabilities exist. It is to gate every inbound report on a reproducible proof of concept plus human validation, weight each report by demonstrated exploitability rather than volume or confidence, and protect analyst time by triaging on evidence. This post walks the curl numbers, sets them against a real AI-found CVE, and gives you a triage playbook you can run on Monday.
TL;DR: the curl numbers and the contrast
Confirmed-vulnerability rate before 2024: north of 15 percent of submissions (Daniel Stenberg, 2026).
Confirmed-vulnerability rate in 2025: below 5 percent, as AI slop reports surged (Daniel Stenberg, 2026).
Lifetime confirmed vulnerabilities via the program: 87 (Daniel Stenberg, 2026).
Lifetime rewards paid: over US$100,000 (Daniel Stenberg, 2026).
Program lifespan: launched April 2019, ended 31 January 2026 (curl PR #20312).
Stenberg on 2025 quality: "not even one in twenty was real" (Daniel Stenberg, 2026).
The counter-example: Theori's autonomous Xint Code found CVE-2026-23479, a critical use-after-free RCE in Redis unnoticed for over two years, NVD CVSS 8.8 (The Hacker News, June 2026).
The discriminator: Stenberg's standard is that you should never report a vulnerability unless you understand it and can reproduce it (The Register, January 2026).
Key takeaways
AI-found vulnerabilities are real, so the curl story is signal versus slop, not AI versus humans. An autonomous system found a two-year-old critical RCE in Redis that human review had missed (The Hacker News, June 2026). The problem curl hit was volume of unvalidated noise, not the existence of machine-assisted research.
The collapse was in signal ratio, not report count. curl did not drown in more bugs. It drowned in a confirmed rate that fell from north of 15 percent to below 5 percent while the raw volume of AI-generated reports climbed (Daniel Stenberg, 2026).
Reproducibility is the single cheapest triage filter. Stenberg's rule, never report a vulnerability you cannot reproduce, would have removed most of the slop before a human ever read it (The Register, January 2026).
The real cost of slop is analyst time, not the payout. Stenberg described the slop as taking "a serious mental toll to manage and sometimes also a long time to debunk" (LWN, 2026). A false report that takes an hour to disprove is more expensive than the bounty it was chasing.
A validation gate turns AI output into an asset instead of a liability. The Redis finding arrived with a working, reproducible exploit and a precise code location. That is the shape of a report worth reading, and it is a bar you can require of every inbound submission.
Methodology
The figures in this post trace to named primary sources fetched during the research pass with a July 2026 cutoff. Curl's program statistics, the confirmed-rate figures, the 87 lifetime confirmed vulnerabilities, and the "over US$100,000" in rewards come from Daniel Stenberg's own announcement post and the merged curl pull request #20312. Corroborating quotes on report quality and maintainer burden come from The Register and LWN. The contrasting AI-found vulnerability, CVE-2026-23479 in Redis, is drawn from the official Redis security advisory and reporting by The Hacker News, with the CVSS scores as listed by NVD and Redis. Where a source gives a range or an approximate ("north of," "below," "over"), this post keeps the source's own qualifier rather than inventing a precise number. Every figure links back to its primary publisher so any claim can be audited inline.
What actually happened to the curl bug bounty
curl ran a HackerOne bug bounty from April 2019. For most of that run it was a healthy program: paid researchers submitted real reports, and something north of 15 percent of submissions turned into confirmed vulnerabilities, adding up to 87 confirmed issues and more than US$100,000 paid out over the life of the program (Daniel Stenberg, 2026). A confirmed rate above 15 percent is a strong signal-to-noise ratio for a public bounty on a codebase as scrutinized as curl.
Then the ratio broke. Stenberg dates an explosion in AI slop reports to the second half of 2024, accelerating through 2025, until the confirmed rate fell below 5 percent. In his words, by 2025 "not even one in twenty" submissions was real. The reports were not just wrong; they were confidently, verbosely wrong in a way that cost time. Stenberg described the slop to LWN as taking "a serious mental toll to manage and sometimes also a long time to debunk" (LWN, 2026). In the final week before shutdown the project received seven submissions; some identified bugs, but none described a vulnerability, and confirming that "took a good while" (The Register, January 2026).
The decision was not to pause or restructure. It was to end the program. As Stenberg put it, "There is no longer a curl bug-bounty program." Security reports now go to GitHub rather than HackerOne. His stated goal was to "remove the incentive for people to submit crap and non-well researched reports to us. AI generated or not" (The Register, January 2026). That last clause matters. curl did not blame AI as a category. It removed a reward structure that paid off volume over rigor.
Signal exists: a real vulnerability an AI found
The lazy reading of curl is that AI security research is all noise. That reading is wrong, and it is important that a defender does not build a triage process on it.
In June 2026, Theori's autonomous system Xint Code found CVE-2026-23479, a critical use-after-free in Redis that leads to remote code execution. The bug had been introduced in Redis 7.2.0 and sat undiscovered in every stable branch for over two years. NVD rates it 8.8 under CVSS 3.1; Redis lists it at 7.7 under CVSS 4.0 (The Hacker News, June 2026). This was not a hallucinated finding. It was a real, high-severity vulnerability that a machine surfaced in code that had been read by many humans.
The Redis report did not arrive as a vague claim that "there may be a memory safety issue." It came with a precise location in the source, an explanation of the two individually harmless commits that combined to create the flaw, and a working, reproducible exploit that demonstrated impact. That completeness is the entire difference between the Redis finding and a curl slop report. One tells a maintainer exactly what to fix and proves it matters. The other asks a maintainer to go prove a stranger's guess.
So the story is signal versus slop. AI can generate both. Your triage job is to keep the signal and discard the slop as cheaply as possible, and the good news is that the two look very different on arrival.
What separates a real AI finding from slop
You can sort most inbound AI-generated vulnerability reports in minutes if you look for a small number of concrete attributes. Real findings have them. Slop does not.
Attribute | Real finding | AI slop |
|---|---|---|
Reproduction | Includes a working, re-runnable proof of concept | "Should be exploitable," no steps that run |
Location | Names the exact file, function, or endpoint | Vague area or a whole component |
Impact | Demonstrated, with observed effect | Asserted, often inflated to critical |
Understanding | Explains the root cause and why it triggers | Restates the tool output in confident prose |
Version | Ties the flaw to specific affected versions | Silent on versions, or wrong |
Prior art | Distinct from known issues and duplicates | Rehashes a public CVE or a non-issue |
The through-line is Stenberg's own standard, stated to The Register: "you should NEVER report a bug or a vulnerability unless you actually understand it, and can reproduce it" (The Register, January 2026). Reproducibility is not a nice-to-have. It is the property that lets a defender spend one minute instead of one hour deciding whether a report is real. A report that cannot be reproduced is a hypothesis, and hypotheses belong in a researcher's notebook, not in your triage queue.
This is the same failure mode that makes generic automated scanners noisy on the classes that matter most. The flaws that most often get asserted without proof are the ones with no clean signature: broken authorization, business logic, and IDOR, which is exactly why API scanners miss BOLA and IDOR unless the tool actually reasons about access control and proves the cross-tenant read.
The triage playbook: handling inbound AI-generated vulnerability reports
Here is a repeatable process for any team that receives security reports, whether through a bounty program, a disclosure inbox, or an internal AI tool. The goal is to protect analyst time and weight every report by proof, so real findings surface fast and slop dies before it reaches a senior engineer.
Require a reproducible PoC at intake. Make a working proof of concept a submission requirement, not a follow-up request. State plainly that reports without steps that a triager can re-run will be closed. This one rule filters most slop before a human reads a word of prose, and it costs a genuine researcher nothing because they already have the PoC.
Run a fast reproducibility gate first. Before reading the narrative, try to reproduce the claim. If it reproduces, it is worth a human's full attention. If it does not reproduce in a bounded time box, move it to a "needs proof" state and stop. Do not let a confident write-up pull you into disproving a hypothesis; that is precisely the trap that cost curl "a long time to debunk" each report (LWN, 2026).
Weight by demonstrated exploitability, not stated severity. AI-written reports routinely self-assign "critical." Ignore the label and score on what was actually demonstrated. A proven medium beats an asserted critical every time. Reserve senior reviewer time for reports that already cleared the reproducibility gate.
Deduplicate against known issues and prior CVEs. A large share of slop is a reworded public advisory or a re-report of a closed non-issue. A quick check against your known-issues list and the relevant CVE feed retires these without deep analysis.
Protect analyst time with a hard time box. Give each unreproduced report a fixed budget, for example fifteen minutes, before it is parked. Alert fatigue is the real damage here: a team that burns its week debunking confident nonsense misses the one report that was real. curl's confirmed rate falling below 5 percent is what that fatigue looks like at scale (Daniel Stenberg, 2026).
Route validated findings straight into the developer workflow. Once a finding is reproduced and confirmed, it should land as an actionable ticket with the PoC attached, not a PDF that sits in an inbox. Getting proof-backed findings into the backlog is a solved problem when you integrate pentest findings into the developer workflow rather than treating triage output as a separate document.
Measure your own signal ratio over time. Track the confirmed rate the way curl did. If it trends down, tighten intake before the program becomes unmanageable. A visible signal ratio is an early warning system, and it is the number that told Stenberg the program was no longer worth running.
The same logic applies to a vendor's AI tooling, not just an open disclosure inbox. Our questions to ask an AI pentest vendor and the AI pentest pilot bake-off scorecard both center on the same discriminator: does every finding arrive with proof, and what is the delivered false-positive rate after validation?
What this means for defenders
curl's decision is a warning about incentive design, not about AI. Any process that rewards volume over reproducible proof will fill with slop the moment generating plausible-looking reports becomes free. The fix is to make proof the price of admission and to keep a human in the loop where judgment is needed.
Buy validated findings, not raw output. A pile of unproven AI claims is triage work you are paying to do yourself. Insist that every finding is reproduced and proven exploitable before it reaches your engineers, and measure the delivered false-positive rate on the reports you actually receive.
Keep the human where judgment lives. Reproducibility gates and deduplication can be automated. Deciding whether a demonstrated flaw is a real business risk still benefits from an experienced tester, which is why a human-plus-AI hybrid consistently outperforms either alone.
Design your reward and intake rules around proof. Whether it is a bounty, a disclosure policy, or an internal tool, require a re-runnable PoC and score on demonstrated impact. The incentive shapes the input.
This is the model Stingrai is built on. Our AI agent, Snipe, is an autonomous web application testing agent purpose-built to hunt the high-impact classes that generic tools assert without proving: IDOR, business logic flaws, and broken authorization. Snipe verifies exploitability before a finding is written, backs each web-app finding with a reproducible proof, opens AutoFix pull requests for the issues it finds, and can run as a PR-gating check that blocks vulnerable code from merging. Senior human testers at Stingrai, a CREST-accredited penetration testing firm based in Canada, own final sign-off on every high-severity finding. The output is the opposite of an AI report dump: validated, reproducible findings, which is also exactly the kind of evidence your SOC 2 or ISO 27001 program can use, and the difference matters when you ask whether an auditor will accept an AI pentest. You can see the hybrid model on our PTaaS page or across our services.
Frequently Asked Questions
Why did curl shut down its bug bounty, and how should teams handle AI-generated vulnerability reports?
curl shut down its bug bounty on 31 January 2026 because AI generated vulnerability reports flooded the program and the confirmed-vulnerability rate fell from north of 15 percent to below 5 percent, while debunking the noise took a serious toll on maintainers (Daniel Stenberg, 2026). Teams should not ban AI, because real AI-found vulnerabilities exist. They should require a reproducible proof of concept at intake, gate every report on human validation, weight reports by demonstrated exploitability rather than stated severity, and protect analyst time with a strict triage time box.
What is "AI slop" in the context of vulnerability reports?
AI slop is a confidently written but unverified vulnerability report generated with an AI tool that does not actually demonstrate a bug. It typically asserts high severity, restates tool output in fluent prose, names no exact location, and includes no proof of concept that a triager can re-run. Daniel Stenberg attributed curl's collapse in report quality to an explosion of exactly this kind of submission (Daniel Stenberg, 2026).
Are all AI-generated vulnerability reports fake?
No. Theori's autonomous system Xint Code found CVE-2026-23479, a critical use-after-free remote code execution flaw in Redis that had gone unnoticed in every stable branch for more than two years (The Hacker News, June 2026). The curl problem was the volume of unvalidated noise, not the fact that AI was involved. The story is signal versus slop.
How do you tell a real AI security finding from noise?
Look for reproducibility first. A real finding includes a working proof of concept, names the exact file or endpoint, demonstrates impact rather than asserting it, explains the root cause, and ties the flaw to specific versions. Slop does none of these. Daniel Stenberg's rule captures it: never report a vulnerability unless you understand it and can reproduce it (The Register, January 2026).
Did curl ban AI-generated reports?
No. curl ended the bounty to remove the incentive to submit low-effort reports, "AI generated or not," per Stenberg (The Register, January 2026). Security reports still flow to the project through GitHub. The change targeted the reward structure that paid off volume, not the use of AI itself.
What figures did Daniel Stenberg give for curl's bug bounty?
Stenberg reported that the confirmed-vulnerability rate had run north of 15 percent for years and fell below 5 percent in 2025, that the program confirmed 87 vulnerabilities over its lifetime, and that it paid out more than US$100,000 in rewards (Daniel Stenberg, 2026). The program ran from April 2019 to 31 January 2026 (curl PR #20312).
How should a security team triage inbound AI-generated vulnerability reports?
Require a reproducible proof of concept at intake, run a fast reproducibility gate before reading the narrative, weight reports by demonstrated exploitability rather than the severity they claim, deduplicate against known issues and prior CVEs, and enforce a hard time box so unproven reports do not consume analyst hours. Validated findings should then route straight into the developer workflow as actionable tickets with the proof attached.
How does Stingrai deliver validated findings instead of AI slop?
Stingrai pairs its autonomous web application agent, Snipe, with senior human testers. Snipe verifies exploitability before a finding is written and backs each web-app finding with a reproducible proof, opens AutoFix pull requests, and can gate pull requests to block vulnerable code from merging. Human testers at Stingrai, a CREST-accredited firm, sign off on every high-severity finding, so what you receive is validated and reproducible rather than an unverified report dump. You can see the model on the Stingrai PTaaS page.
References
Stenberg, Daniel. The end of the curl bug-bounty. 26 January 2026. https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/. Primary source for the confirmed-rate figures, 87 lifetime confirmed vulnerabilities, over US$100,000 paid, and the slop timeline.
curl project. BUG-BOUNTY.md: we stop the bug-bounty end of Jan 2026 (PR #20312). Merged 26 January 2026. https://github.com/curl/curl/pull/20312. Removes the bounty and HackerOne references; confirms the closure date.
The Register. Curl calls it quits on bug bounty. 21 January 2026. https://www.theregister.com/2026/01/21/curl_ends_bug_bounty/. Source for Stenberg's reproducibility standard and the final-week submission detail.
LWN.net. The end of the curl bug bounty. 2026. https://lwn.net/Articles/1055996/. Source for the maintainer-burden quotes on the mental toll of slop.
Redis. Security advisory: CVE-2026-23479 and related issues. 2026. https://redis.io/blog/security-advisory-cve202623479-cve202625243-cve-2026-25588-cve202625589-cve-2026-23631/. Official advisory for the Redis use-after-free RCE found by Theori's Xint Code.
The Hacker News. Autonomous AI Tool Finds 2-Year-Old RCE Flaw in Redis (CVE-2026-23479). June 2026. https://thehackernews.com/2026/06/autonomous-ai-tool-finds-2-year-old-rce.html. Corroborates the discovery, CVSS scores, and the two-year exposure window.
Read next: our questions to ask an AI pentest vendor, the AI pentest pilot bake-off scorecard, and why API scanners miss BOLA and IDOR. To pressure-test your app with a proof on every finding and senior human sign-off, see Stingrai PTaaS or explore our services.
