bbp curl/1.1 must die

I 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.

So 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.

That'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.

Honestly 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.

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.

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.

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.

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.

shutting 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.

Security disclosure program isn't going anywhere. It's just moving from hackerone to GitHub.

There 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.

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.

How about demanding something in the range of a 10-100 EUR deposit from anyone who wants to be eligible for a bug bounty?

• If they found something the deposit is paid back + rewards
• If it ultimately isn't an issue but still was a reasonable find the deposit is paid back without rewards
• If it's AI slop you keep the deposit as punishment

How 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.

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?

Why not fight fire with fire? If low-effort AI is the problem, put a well instructed AI triage bot at the gate. Give it all the context about curl's defensive patterns that the junk reports are missing - dynbuf bounds enforcement, NTLM_BUFSIZE validation, cookie input limits, etc.

Junk AI submits "buffer overflow in dynbuf" → your bot knows that's a documented safe pattern → auto-reject before it wastes human time.

Came across the following comment about having a submission fee on a YT video on this topic. Could this be considered?

A bug bounty submitting fee? Could stop most of the shitty ai generated garbage.

Fr you get the bounty and a refund if its real

I remember upwork implementing a small fee to prevent people from spamming on freelance postings. It did the job for them. A small fee is often enough to discourage a lot of spam posters.

very sad to hear

@bagder Github now allows disabling/restricting PR creation to tackle AI Slop Pull Requests.
Maybe this is something for curl/curl too?

https://github.blog/changelog/2026-02-13-new-repository-settings-for-configuring-pull-request-access/

Greetings, Steve