Back to Blog

AI Slop vs. Open Source: Why cURL Had to Kill Its Bug Bounty Program

K
Karan Goyal
--5 min read

The cURL project has ended its bug bounty program due to a flood of low-quality 'AI slop' reports. Here's why this matters for the future of open source and AI development.

AI Slop vs. Open Source: Why cURL Had to Kill Its Bug Bounty Program

cURL killed its bug bounty, and I don't blame Daniel one bit

Daniel Stenberg has maintained cURL for over 25 years. The thing runs in your car, your TV, your phone, half the servers you've ever touched. And in 2025 he stood up and said the bug bounty program was being shut down because he was drowning in AI-generated garbage. Not because the code got less secure. Because grown adults started pasting ChatGPT output into HackerOne and calling it a vulnerability report.

That's the part that gets me. The attack surface didn't change. The volunteers did. A handful of maintainers spent their evenings reading confident, well-formatted reports that described bugs which did not exist, written by people who never read the code they were "auditing."

What the slop actually looks like

I've seen these reports. They have a texture. The English is clean. The structure is professional. There's a CVSS score, a "proof of concept," a suggested patch. Everything signals competence except the one thing that matters: whether the bug is real.

What's happening under the hood is simple. Someone prompts a model with "find a security vulnerability in this C function," the model obliges because models always oblige, and out comes a "heap buffer overflow" in a line that's been bounds-checked three functions up the call stack. The submitter doesn't know C. They can't tell. So they hit submit and wait for the payout.

Now Daniel has to read it. He has to figure out that the report is wrong, which is harder than figuring out that a report is right, because you're proving a negative. A real finding announces itself with a crash. A fake one makes you walk the whole code path to confirm nothing's there. The model spends two seconds generating it. The maintainer spends an hour disproving it. That asymmetry is the entire problem.

This isn't a curl problem, it's an incentive problem

Bug bounties pay money. The moment you can mass-produce plausible-looking reports for free, you've built a machine that converts maintainer attention into lottery tickets. Most people aren't malicious about it. They genuinely think the AI found something. That's almost worse, because you can't ban good intentions.

And the targets are the worst-resourced people in software. Open-source maintainers are mostly unpaid or barely paid, holding up infrastructure that trillion-dollar companies ship on top of for free. When you 1000x the noise hitting their inbox, you're not testing their security posture. You're attacking their patience. Daniel said the call was partly about protecting the maintainers' sanity, and people treated that like a soft reason. It's the hardest reason there is. If he quits, cURL is the vulnerability.

I write a lot about pointing AI at real engineering work, and I keep coming back to the same line: the tool is fine, the operator is the variable. I went into this more in my practical guide to automating workflows with AI, and nothing about the cURL situation contradicts it. The model didn't do anything wrong. It did exactly what it was asked. The failure is a human submitting output they never verified.

The human-in-the-loop isn't optional, it's the whole job

Here's my actual take. Using an AI to generate a security report and submitting it unread isn't laziness. It's negligence, and it should carry a reputation cost.

If you run an agent over a codebase and it flags something, that's the beginning of your work, not the end. You go reproduce it. You write the script that crashes the binary. You confirm the input that triggers it. If you can't make the bug fire, you don't have a bug, you have a sentence a model generated. The judgment is the value you add. Prompting is not a skill. Knowing which output to throw away is.

This is why I think the next useful wave of AI tooling is agents that verify themselves before they ever ping a human. An agent that claims a buffer overflow should be made to produce the crashing input first. No repro, no report. A lot of the agent patterns people are experimenting with right now point in that direction, and there's a solid tour of the landscape in this rundown of LLM apps, AI agents, and RAG if you want to see where the self-checking ideas are coming from. The technology to gate output on a passing test already exists. We just don't bother, because it's easier to ship the confident paragraph.

What the platforms should do

HackerOne and the rest could fix a chunk of this tomorrow with reputation gating that actually bites. Submit three false-positive AI reports, lose your ability to submit. Make a maintainer's time the scarce resource it is, instead of treating their inbox as free compute for people gambling on a payout. cURL ended up flagging suspected AI submissions and demanding the submitter prove the bug is real before a human engages. That should be the default everywhere, not a thing one exhausted maintainer had to invent under fire.

I don't read cURL's decision as anti-AI. Daniel uses these tools. The decision is anti-slop, which is a different thing entirely. The loss is real though: a legitimate channel for security research got shut down because the floor of honest signal dropped below the noise. That's not the model's fault and it's not Daniel's. It's the fault of everyone who confused generating a report with finding a bug.

The same gap shows up everywhere AI touches real work, not just security. I build tools that try to stay on the right side of it, like Ask Shopify, where the answer has to actually map to how the platform behaves or it's worse than useless. Plausible and correct are not the same word. cURL just paid the tuition to remind everyone.

FAQ

Why did cURL shut down its bug bounty program?

Maintainers, led by Daniel Stenberg, were spending too much time triaging AI-generated reports that described vulnerabilities which didn't exist. The reports looked professional but were technically wrong, and disproving each one cost real human hours. The program's noise outgrew its value.

What is "AI slop" in a security context?

Low-effort, AI-generated bug reports submitted without any human verification. They tend to hallucinate vulnerabilities, explain them with confident but flawed reasoning, and get sprayed across many projects at once because they cost nothing to produce.

Does this mean AI is bad at finding security bugs?

No. AI can be a genuinely useful starting point for an investigation. The problem is people submitting raw model output as a finished finding. If you can't reproduce the bug, you don't have a report worth sending.

Top Rated Plus ยท 100% Job Success

Want this built for you instead of DIY?

I'm Karan โ€” a Top Rated Plus Shopify Expert ($300K+ earned, 100% Job Success). If you'd rather hand this to someone who's done it hundreds of times, let's talk.

Get a Free Quote

Tags

#AI Development#Open Source#Cybersecurity#cURL#Tech News

Share this article

๐Ÿ“ฌ Get notified about new tools & tutorials

No spam. Unsubscribe anytime.

Comments (0)

Leave a Comment

0/2000

No comments yet. Be the first to share your thoughts!