As reported by BleepingComputer, the curl project's decision to end its paid bug bounty program in January 2026 — driven by a drop in confirmed vulnerability rates from above 15% to below 5% — has become a defining case study in how AI-assisted reporting is reshaping the security research landscape. The follow-up is equally notable: by April, submission quality had rebounded to ~15-16%, with researchers using AI extensively but producing verifiable findings.
What This Actually Tells Us
The curl episode is not a story about AI replacing human researchers or making bug bounties obsolete. It is a story about triage capacity as the new bottleneck. When submission volume surges but triage resources remain fixed, even legitimate reports get buried. The programs that pulled back — curl and Google's supply chain track — share a common trait: small teams handling disproportionate inbound volume.
The programs most vulnerable to AI-driven report flooding are those with the least triage automation and the smallest security teams. The problem isn't AI; it's the asymmetry between submission volume and verification capacity.
For organizations running or considering bounty programs, this shifts the calculus. The question is no longer just "what vulnerabilities exist in our product?" but "can our team absorb and verify the volume of reports modern tooling generates?"
Who Is Affected
The Broader Implication: Verification Is the Skill
The article's most important insight is buried in the curl recovery: researchers who used AI but took responsibility for verifying their findings produced high-quality reports at historical rates. The differentiator was not whether AI was used, but whether the researcher could establish that a vulnerability was real before submitting.
This has implications for how organizations should think about inbound vulnerability reports more broadly. The same dynamic applies to internal bug reports, partner disclosures, and even automated scanner output: the value is in the verification, not the volume.
Shield53 Recommendations
For Organizations Running Bounty or Disclosure Programs
- Implement automated triage gating — require PoC artifacts, reproduction steps with expected vs. actual behavior, and environment details before a report enters human review. This filters AI-generated noise without rejecting quality submissions.
- Tier your response SLAs by report quality, not severity alone — a well-documented low-severity finding deserves faster triage than a poorly-documented critical claim.
- Set explicit submission standards — publish templates that require verification evidence. curl's experience shows researchers adapt to clear expectations.
- Budget for triage tooling, not just payouts — if your program can't scale verification, higher bounties will only increase the problem.
For Security Teams Evaluating Inbound Reports
- Treat every vulnerability claim — whether from a bounty hunter, automated scanner, or internal team — as an unverified hypothesis until reproduced.
- Build or adopt a lightweight verification pipeline that can handle bulk submissions without burning senior analyst cycles on initial filtering.
- Track your own confirmed-vulnerability rate. A dropping rate is an early indicator of triage strain, not necessarily declining product security.
The curl program's recovery to 15-16% confirmation rates is the key data point that deserves more attention than the initial collapse. It demonstrates that the ecosystem self-corrects when expectations are clear and researchers invest in verification. Organizations that build triage capacity and set quality gates will weather the AI volume surge. Those that rely on manual triage alone will find themselves making the same difficult decisions curl and Google faced.
