curl shut down its bug bounty in January 2026. The reason is boring and it applies to every intake channel you run: the payment was buying volume the security team could not absorb.
The commit is small and worth reading: BUG-BOUNTY.md: we stop the bug-bounty end of Jan 2026 touches 11 files and removes 82 lines from the bounty doc. What is left is 16 lines, and the load-bearing paragraph says a bug bounty "gives people too strong incentives to find and make up 'problems' in bad faith that cause overload and abuse." Same commit, less noticed: the issue template's security link moved from hackerone.com/curl to the project's own security advisories page.
seven reports in sixteen hours, zero vulnerabilities
Daniel Stenberg's weekly post from January 16, 2026 is the receipt (mailing list). Seven HackerOne issues inside sixteen hours. Some were real bugs. None described a vulnerability. Twenty submissions for 2026 already, by mid-January. His stated goal for killing the program: "remove the incentive for people to submit crap and non-well researched reports to us. AI generated or not." And the line that tells you what it cost: "The current torrent of submissions put a high load on the curl security team and this is an attempt to reduce the noise."
The Register covered it under the headline that the program was shut to remove the incentive for submitting AI slop. What I find more useful than the framing is the mechanism. Nothing about the reports changed in kind. What changed is the cost of producing a plausible one, and the program's payout was still sized for an era when producing one cost a researcher an afternoon.
a payout is a price, and the price sets the false-positive rate
A bounty is a price on a submission. Set the price high enough and you attract attempts up to its expected value. When generation gets cheap, the expected value of an attempt goes up even though the quality of the average attempt goes down, and the marginal submitter becomes someone with an agent, a plausible story, and no reproduction.
You cannot filter your way out of a mispriced channel, because filtering is labor and labor is the thing you were trying to protect. Removing the payout does not improve report quality. It removes the reason to file a low-effort one. curl still takes reports, just without a check at the end.
So the question I would ask about any intake channel: who pays for a false positive? If the sender pays nothing and you pay the reading time, volume rises until the channel stops working, and then someone posts a sad note about mental health and closes the program.
the same flood shows up with no payout at all
Worth being precise here, because the payout story is only half of it. Postgres has never offered a bounty (their security page says so in as many words), and it got flooded anyway.
I counted commit trailers on the master branch for April 8 to September 25 in both 2025 and 2026, paging the commits API and counting trailer lines. Reported-by: lines went from 309 to 563. Distinct reporter names went from 182 to 249. 202 of the 2026 names never appear in the 2025 window at all. In 2025, zero of those strings named a model vendor, an agent product, or a security automation shop. In 2026 the field contains "Xint Code", "Claude Code (via Noah Misch)", "OpenAI Codex Security", "Anthropic OSS program", plus entries attributed to Aisle and DepthFirst. Commits carrying a Security: CVE-... trailer went from 5 to 58.
That is two different problems wearing the same coat. curl had an incentive problem, where the payout set the noise floor. Postgres had a capacity problem, where the noise arrives whether or not anyone is paying. Most teams running a review or triage queue have both, and the fix for one does nothing for the other. I wrote the full set of numbers and the query on the aicodereview.io blog.
what to measure before you change your intake
Four numbers, all cheap, all from data you already have:
- Acceptance rate per week. Reports closed as fixed divided by reports opened. If it is falling while volume grows, the channel is mispriced or understaffed, and you need to know which before you touch anything.
- Median time to first human response. Growing means triage is the bottleneck, and adding a scanner upstream will make it worse.
- Share of reports that arrive with a reproduction you can run. This is the number that separates noise from work, and it is the one almost nobody tracks.
- Cost per confirmed report. Hours spent reading divided by reports fixed, quarter over quarter.
Then the decision splits cleanly. Acceptance falling with growing volume and a low reproduction share: gate on reproduction, meaning no runnable repro and observed output means no queue entry and no payment. Acceptance flat with growing volume: you have a capacity problem, and the fix is people, not tooling.
one more thing about text filters
Scoring incoming reports with a classifier is the wrong first move, and not because the models are bad. A report that reads well and does not reproduce passes every readability filter you can build, which is exactly the class of report that is eating your week. Reproduction is the only check that stays cheap as volume grows, and a reproduction you can run is a stronger signal than any amount of fluent prose.
The free version of this: if your issue template does not ask for the exact command that triggers the bug and the observed output, add those two fields today. curl's new template points people at the advisory form instead of a bounty form, and the fields are the reason.
If you want to know whether your intake is actually the problem, pull your last 20 submissions and count how many came with a reproduction. If that number is low, change the intake before you change anything about the reviewer.
Top comments (1)
That distinction is important: a rate limiter changes how fast abuse happens, while a filter defines which requests are unacceptable. Treating one as the other can create a false sense of coverage. I would test the system with low-and-slow variants as well as bursts, then measure both what is blocked and what reaches the downstream service.