Hacker News
The popular data transfer tool Curl has announced it will cease its bug bounty program by the end of January 2026. The decision is attributed to an increase in AI-generated spam reports overwhelming the program.
AI 生成摘要
Curl，一款廣受歡迎的資料傳輸工具，宣布將於 2026 年 1 月底終止其漏洞賞金計畫。此決策歸因於 AI 生成的垃圾報告數量增加，對該計畫造成了過度負擔。
We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
#20312
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
#20312
commented Jan 14, 2026 •
edited Loading Uh oh! There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Remove mentions of the bounty and hackerone.
There will be more mentions, blog posts, timings etc in the coming weeks.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
commented Jan 15, 2026bbp curl/1.1 must die
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
commented Jan 15, 2026I mean if you think about it, the idea of bug bounties came to be in the context of businesses, because for businesses it is simply cheaper. For every 1 person that finds something, 9 (number chosen by fair dice roll) people have wasted large amounts of unpaid time on doing an audit of your codebase.
So, fundamentally, the tool was conceived for value extraction, but then suddenly, value was extracted back through bogus reports.
In the middle of all that, FOSS projects (like e.g. CURL) adapted it, because it was what everyone was doing and then you got caught in the crossfire of that counter-value-extraction.
Anyway, probably doesn't really belong here, but I thought that this perspective/take might provide some value. If not, feel free to delete or hide.
Thank you again Daniel for everything you do.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 15, 2026So luddites laugh at how bad vibecoding is, but when AI finds more bugs than code in a human project, they take down the bounty instead of fixing them.
Feel free to point out all the bugs you say we have not fixed.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 19, 2026That's a disgrace for the bug bounty industry. I'm sorry of the quality you received with your program, and I'm worried about the future of my industry, considering the platforms' behavior with low quality hunters.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 20, 2026Honestly I can't blame anyone on the curl team for this.
I've tried hunting for bugs on this as well, and I'm glad to report that I came up with zero hits. And yes, I used AI for code review assistance. I also submitted no reports on HackerOne because I didn't find any valid issues which crossed any meaningful security boundary.
Oh, AI tends to disagree of course. It found five different paths to "🚨CRITICAL RCE 🚨" in nearly one out of ten files it audited. Doesn't matter which LLM you ask. The difference is in HOW you use it and how much you depend on it. I can confidently say that building dependence on it will not end well.
In my own case, I use AI for a quick sweep of the attack surface. If it says there's a critical issue found or there's a high severity bug, I just note it down for later and look at it, understand why it said that and run some test data through it, while fully expecting it to be a false positive. And, almost all the time, it is. If there is something that actually does pique my interest, I run it through a 100 different test cases in different setups with extensive verification.
Versus all the reports which are a direct copy paste of ChatGPT without knowing a word of what it says and copy pasting the triagers' questions or dismissals and copy pasting the ChatGPT response back... 🤣
(Yes, I collect these reports. It's quite comedic)
All of which is to say, it's justified for curl to close the program given the volume of BS reports piped through AI. And researchers who currently do that definitely need to read the above.
@bagder Your patience and in general tolerance to those reports is admirable lol. Glad the program lasted as long as it did. If anything, it serves as an anti-checklist for genuine researchers.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 21, 2026As a security researcher, this is honestly painful to see, but also completely understandable.
The volume of low-effort, AI-generated reports has clearly shifted the cost from “pay for real findings” to “pay in maintainer time for noise,” which is unfair for a FOSS project like curl.
Programs like this only work when researchers take responsibility for understanding the code, reproducing issues, and proving real impact. Copy-pasted 🚨CRITICAL RCE claims without comprehension erode trust and waste the very time that keeps projects alive.
That said, but @bagder shutting down the program feels more like treating the symptom than the disease. The real problem is the breakdown in signal-to-noise and the lack of accountability for low-quality submissions. As long as that remains unsolved, more FOSS projects will likely reach the same conclusion.
Thank you for running the program as long as you did, and for everything you’ve built with curl. I hope this moment becomes a wake-up call for the community and platforms alike to value depth, verification, and respect for maintainers over volume and automation.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 22, 2026 •
edited Loading Uh oh! There was an error while loading. Please reload this page.There was an error while loading. Please reload this page.
shutting down the program feels more like treating the symptom than the disease
There's no attempt from us to deny that. It is also a risk that the move gets little to no effect and that the "flood" and horrors just follow us over.
We are just a small single open source project with a small number of active maintainers. It is not in our power to change how all these people and their slop machines work. We need to make moves to ensure our survival and intact mental health.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 22, 2026 •
edited Loading Uh oh! There was an error while loading. Please reload this page.There was an error while loading. Please reload this page.
On Monday January 26, 2026, I intend to merge this pull-request and post an explainer blog post detailing some further reasoning and details behind this move. The change, the end of the bounty, is officially set for January 31 but I am certain it will take some days to "take effect" and by merging the update a few days early I don't think we actually hurt anyone.
We will accept submissions until the closure date and then stop. If there are any submissions in progress at the cut-off moment, we allow them to continue the process and we will handle them as we always have using the standard procedure.
Starting February 1, 2026. We accept no new submission on Hackerone and instead ask people to submit security reports on GitHub.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 23, 2026 •
edited Loading Uh oh! There was an error while loading. Please reload this page.There was an error while loading. Please reload this page.
As a security researcher, this is honestly painful to see, but also completely understandable. The volume of low-effort, AI-generated reports has clearly shifted the cost from “pay for real findings” to “pay in maintainer time for noise,” which is unfair for a FOSS project like curl. Programs like this only work when researchers take responsibility for understanding the code, reproducing issues, and proving real impact. Copy-pasted 🚨CRITICAL RCE claims without comprehension erode trust and waste the very time that keeps projects alive. That said, but @bagder shutting down the program feels more like treating the symptom than the disease. The real problem is the breakdown in signal-to-noise and the lack of accountability for low-quality submissions. As long as that remains unsolved, more FOSS projects will likely reach the same conclusion. Thank you for running the program as long as you did, and for everything you’ve built with curl. I hope this moment becomes a wake-up call for the community and platforms alike to value depth, verification, and respect for maintainers over volume and automation.
Honest question, how can we do more than treat the symptoms? No single project or even group of FOSS projects have the power to "cure the disease" here, since the disease at its core is greed and sloth, two of the most pernicious failings of human kind throughout history? These LLMs just exacerbate the original problem the industry already had by making it all the easier to make an undeserved quick buck.
As I see it, the only way to come close to curing the problem (but still just a bandaid) is to completely reject all outside contributions, since it's impossible to not waste one's time on triaging PRs otherwise. Who's got the time to even read 100s of slop "contributions" a day to find the one or two genuine problems or contributions that may happen once or twice a week at best? Just throwing money at the problem isn't a viable solution when most of us are hobbiests and don't want to make our projects our job, not even the projects that have inadvertently ended up becoming pillars of modern software like libxml2, ntpd, etc.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 23, 2026shutting down the program feels more like treating the symptom than the disease
There isn't really any good way to treat the disease itself, alas.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 23, 2026Security disclosure program isn't going anywhere. It's just moving from hackerone to GitHub.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 23, 2026There isn't really any good way to treat the disease itself, alas.
I think that GitHub (or other git hosting sites)
implementing some form of karma system that lets real developers vet for each other & marks sloperators as untrustworthy would make it much harder for them to DDoS repos like this. Alas actually getting that is way beyond the scope of curl.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 23, 2026As a security researcher, this is honestly painful to see, but also completely understandable. The volume of low-effort, AI-generated reports has clearly shifted the cost from “pay for real findings” to “pay in maintainer time for noise,” which is unfair for a FOSS project like curl. Programs like this only work when researchers take responsibility for understanding the code, reproducing issues, and proving real impact. Copy-pasted 🚨CRITICAL RCE claims without comprehension erode trust and waste the very time that keeps projects alive. That said, but @bagder shutting down the program feels more like treating the symptom than the disease. The real problem is the breakdown in signal-to-noise and the lack of accountability for low-quality submissions. As long as that remains unsolved, more FOSS projects will likely reach the same conclusion. Thank you for running the program as long as you did, and for everything you’ve built with curl. I hope this moment becomes a wake-up call for the community and platforms alike to value depth, verification, and respect for maintainers over volume and automation.
Honest question, how can we do more than treat the symptoms? No single project or even group of FOSS projects have the power to "cure the disease" here, since the disease at its core is greed and sloth, two of the most pernicious failings of human kind throughout history? These LLMs just exacerbate the original problem the industry already had by making it all the easier to make an undeserved quick buck.
As I see it, the only way to come close to curing the problem (but still just a bandaid) is to completely reject all outside contributions, since it's impossible to not waste one's time on triaging PRs otherwise. Who's got the time to even read 100s of slop "contributions" a day to find the one or two genuine problems or contributions that may happen once or twice a week at best? Just throwing money at the problem isn't a viable solution when most of us are hobbiests and don't want to make our projects our job, not even the projects that have inadvertently ended up becoming pillars of modern software like libxml2, ntpd, etc.
How about demanding something in the range of a 10-100 EUR deposit from anyone who wants to be eligible for a bug bounty?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 23, 2026How about demanding something in the range of a 10-100 EUR deposit
If this move (shutting down the bounty) does not have the desired effect, creating the "curl security report club" with an entrance fee might very well be the next step.
However, I think it would be an unfortunate step as it limits who can and will find and report vulnerabilities on a dimension that isn't related to their ability to submit a real report.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
commented Jan 23, 2026 •
edited Loading Uh oh! There was an error while loading. Please reload this page.There was an error while loading. Please reload this page.
I think Derpalus is suggesting to gate only the bounty program behind the deposit. Bug reports without a deposit will still be accepted, but ineligible for bounties and otherwise subject to the new rules.
Gating off the entire bug submission process may be a reasonable next step, but I expect and hope that gating off the bounties is enough to keep the slop amounts tolerable.
It's unfortunate that we even need to consider such stuff, but... what choice do we have?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
MultisampledNight
MultisampledNight left review comments
stepo2
stepo2 left review comments
thijs-reijgersberg
thijs-reijgersberg left review comments
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.
