There's a GitHub notification you're going to hate.
A new issue, well-written. It cites precise line numbers in your code, describes a security vulnerability with convincing technical vocabulary, structures the argument in 3 clean points. The kind of report that looks serious on first read.
Built entirely by an LLM. Submitted by someone hunting a bug bounty or a few PRs on their GitHub profile before the next job interview.
Daniel Stenberg has maintained curl since 1998. Installed on billions of devices, your machine included. In January 2026, he shut down his HackerOne bug bounty after receiving 7 fake security reports in 16 hours. 20 submissions in 21 days, none identifying a real vulnerability. He estimates each report at $150 in volunteer time to triage. He called it "terror reporting" and killed the program.
The asymmetry at the core of this: submitting costs a few cents in AI tokens. Triaging costs $150 in human time. That asymmetry doesn't care about the size of your project. It cares about 1 thing: whether your issues are open.
The Issue That Looked Real
What these reports look like in practice is worth describing, because the first 1 you receive will probably fool you for about 30 seconds. Those 30 seconds are the whole mechanic.
The pattern is consistent across maintainer threads from the past several months. The issue arrives with clean structure: it names a specific version of your library, references file paths that exist in your repo, and describes an attack vector using the right vocabulary. Something like "improper input validation in the handler could allow an attacker to bypass..." followed by 3 plausible-sounding steps. Sometimes a proof-of-concept snippet. Perfect grammar, professional tone.
Then you go look at the code.
The vulnerability doesn't exist. The line numbers don't map to anything relevant. The attack vector only works if your library does something it doesn't do. The whole thing is a hallucination with the formatting of a legitimate security report, submitted by someone who pointed a scanner at your repo, spent a few cents of API tokens, and waited 3 minutes.
You cannot safely skip these. Every ignored security report that turns out to be real is a disaster. So you triage all of them. It's basically a DEFCON 1 alert on your Minecraft server: the risk is zero, but the response is still mandatory. (I know. Deeply unfair.)
Stenberg described the experience as "terror reporting." The word is exact. Not because the reports are dangerous. Because each 1 demands immediate attention that turns out to be entirely wasted.
1 Maintainer. 18 Months. $150 per Report.
Before 2025, Stenberg received roughly 1 security report per week. About 1 in 6 was real. He had a documented triage process, a team of 7 volunteers, and the kind of reputation that attracted serious researchers.
Then the ratios changed.
Late 2025: 1 in 20 to 30 reports was real. Volume had multiplied by 5. January 2026: 7 submissions in 16 hours. 20 in 21 days, none identifying a real vulnerability. Stenberg shut down the HackerOne program and updated curl's security.txt to make the consequences of bad-faith submissions explicit and public.
He estimated the cost: $150 per report in volunteer triage time. On 20 reports in 21 days, that's $3,000 in volunteer hours with 0 security value returned.
I've been following Stenberg's FOSDEM talks for a few years. curl always read like the platonic ideal of open source sustainability: a single maintainer, decades of commitment, a project running on billions of devices. The slopageddon chapter feels like an especially cruel plot twist for someone who built the internet's plumbing by hand.
1 caveat worth keeping, because Stenberg keeps it: some AI-assisted research is legitimate. Joshua Rogers found around 50 real vulnerabilities in curl using ZeroPath, combining the tool with his own expertise to filter signal from noise. Stenberg described him as "a clever person using a powerful tool." In 6 years of tracking AI-generated security submissions, 0 vulnerabilities were found by AI alone, without a human in the loop.
Stenberg reopened the bounty in March 2026. Not because the flood stopped, but because the quality had improved enough that some reports were now technically coherent, just massively duplicated. Multiple researchers independently pointed the same scanner at the same repo, got the same output, and submitted the same non-finding. "It was literally like 2 people finding needles in the same haystack," he said. "And that's never happened." As of June 2026: 1 report every 18 hours.
What Happened to curl Is Happening Everywhere
2 distinct populations are generating this noise, and they have different incentives. Understanding the difference matters because the fix for 1 doesn't address the other.
Bounty hunters are the automated scanner crowd. They target projects with active monetary rewards. curl was a prime target specifically because of the HackerOne bounty. Remove the financial incentive and you largely disappear from their queue. Jazzband, a Python collective, shut down entirely after being overwhelmed by this group. The solo builder without a monetary bounty has 1 structural advantage: bounty hunters mostly move on.
Resume padders don't care about the bounty. A GitHub profile showing 50 contributions, PRs submitted and issues opened, even all rejected, reads better to a recruiter than a blank profile. AI dropped the cost of generating a plausible-looking PR to roughly 0. So this population targets any project with open issues and indexable visibility. 200 stars or 2 million, the difference in attractiveness is smaller than most builders assume.
I wrote about the cost of going closed-source in 2026 when Cal.com made that call. This article is the other side: staying open isn't staying passive.
Remi Verschelde, who maintains Godot, described triage work as "draining and demoralizing." Mitchell Hashimoto, who built Vagrant and Terraform and now maintains Ghostty, wrote in January: "It's a f--king war zone out here man. Maintainer morale at an all time low." He banned unattributed AI contributions outright. tldraw auto-closes all external PRs. GitHub is actively building emergency moderation controls for pull requests. When a platform ships emergency controls, it's a signal, not a niche complaint.
1 in 10 AI-generated PRs meets the quality standard required to open it, according to a June 2026 GitHub community discussion. The other 9 land in someone's triage queue.
Kate Holterhoff named it "AI Slopageddon" in early 2025. The portmanteau spread immediately. When a label gets adopted that fast, the underlying experience was already widespread and just needed a name.
You Shipped a Side Project. You Just Became a Maintainer
Here's the part that doesn't come with any documentation.
When you pushed your project, activated issues (the default setting, most people leave it on), and started accumulating stars, you also agreed to something with no onboarding doc: maintainership. With it comes a responsibility nobody formally assigns, 1 that still consumes your actual time: triaging whatever lands in the issues tab.
Stenberg had 6 years to build his moderation infrastructure. He had 7 volunteer triagers, a documented triage policy with stated consequences for bad-faith submissions, a public reputation that functions as a deterrent, and a security.txt file that explicitly warns bad actors about what happens to them. He built all of this deliberately, over years, in response to a pre-AI volume of noise that was already significant and growing. And this is for curl, a project running on billions of devices worldwide. The scale of the target, the size of the infrastructure, and the years of deliberate construction are proportional to each other in a way that doesn't transfer to a side project pushed on a Thursday afternoon.
You have a README.
The gap between those 2 situations is worth naming without catastrophizing. Shipping fast with AI gets a demo running, a prototype working, something that earns GitHub stars. That's the first loop Vibe Coding, For Real covers for builders who've hit the demo-to-production wall. But shipping fast doesn't ship the moderation layer. The moderation layer is the DLC that didn't come bundled, and it becomes mandatory once the project is visible.
I think the visibility threshold matters more than the star count, actually. A project with 150 stars and open issues is indexable by the same automated scanners as 1 with 15,000. Maybe I'm wrong, but the practical implication seems the same either way: once you're findable, you're a potential target.
The supply chain attack surface and the AI slop attack surface share the same logic: both are passive, both grow with visibility, and the cost lands entirely on you. I ran into the former directly and documented it in my LiteLLM supply chain analysis. Both attacks don't need a vulnerability in your code. They need you to not have a policy.
The cost of contribution just hit zero. The cost of moderation didn't.
5 Things to Do Before the Bots Find You
None of these are complicated. All of them are easier to set up before the noise starts than after.
1. Don't run a monetary bug bounty unless you can actually defend it
A monetary bounty is the primary targeting signal for the bounty hunter population. HackerOne, Bugcrowd, any structured reward program: having one is roughly equivalent to posting "pay-per-report accepted" in the open source directory. Without one, automated scanners mostly prioritize other targets. This isn't an argument against bug bounties as a concept. It's an argument against adding one as a "looks serious" checkbox without the triage infrastructure to support it. Stenberg had 6 years of infrastructure before the flood hit. Running a bounty without that infrastructure is paying to be targeted.
2. Write a CONTRIBUTING.md with an explicit AI rule and stated consequences
The rule needs to say what happens, not just what's expected. Something like: "AI-generated issues or PRs submitted without verified reproduction steps will be closed immediately. Repeated violations will result in a block." The consequences need to be there because the rule exists not to persuade, it exists to make closures publicly defensible. When you close a submission and someone pushes back, you point to the rule. Without it, every closure becomes a judgment call you have to relitigate from scratch.
3. Add an issue template with a mandatory human-verification field
This is the technical layer for what the CONTRIBUTING.md covers in policy. A required field that reads "Steps you personally reproduced on your machine, in sequence:" creates friction that automated submissions generally can't fill coherently. The template creates a paper trail that makes bad-faith submissions easier to identify and close cleanly.
4. Deploy a stale bot at 14 days
Any issue without activity for 14 days gets auto-closed with a standard message. Think of it as the git gc of issue management: it runs quietly and reclaims space you didn't realize you'd allocated. The passive backlog that accumulates even with active triage disappears without manual intervention. Without a stale bot, the issues tab fills with unresolved reports that create cognitive overhead every time you look at the repo.
5. Disable issues entirely if you're not in active maintenance mode
This option gets skipped because open issues feel like a maturity signal. But a project where issues have been open and untriaged for 6 months sends a worse signal than a project currently on pause. And from a targeting standpoint, issues disabled means not indexable by the automated scanners looking for contribution targets. If you're between feature cycles, if you shipped something and moved on, turning off the issues tab is a valid choice. The repo stays public, forkable, useful. It just goes quiet.
The Same Tool. 2 Directions
The same AI tooling generates the security reports for bounty hunters and the PRs for resume padders. Same underlying capability, different incentive, different defense.
Bounty hunters mostly self-select out when there's no financial reward. The solo builder without a monetary bounty is, structurally, a less attractive target for that population. That's about the only structurally good news here.
Resume padders don't respond to the absence of a bounty. The effort cost is 0. The benefit to their profile is real. The cost lands entirely on the maintainer. AI-generated PRs for resume padding "look fine. Tests pass. The code might even work," as Continue Blog put it in January 2026. "The problem is there is nobody home." That's the population the measures above are designed to filter, because there's no structural incentive that stops them the way removing a bounty stops the hunters.
AI compressed build time. It did not compress maintenance time. The friction that filtered bad contributions, the effort to understand a codebase, reproduce a bug, write something coherent, disappeared on the submission side. Not on the triage side. Stenberg spent 6 years building his defense with 7 volunteer triagers.
He still gets 1 report every 18 hours. C'est la vie 🤷♂️
Sources
- Bleeping Computer. "Curl ending bug bounty program after flood of AI slop reports." https://www.bleepingcomputer.com/news/security/curl-ending-bug-bounty-program-after-flood-of-ai-slop-reports/
- The Register. "Curl shutters bug bounty program to stop AI slop." https://www.theregister.com/2026/01/21/curl_ends_bug_bounty/
- The New Stack. "cURL's Daniel Stenberg: AI is DDoSing open source." https://thenewstack.io/curls-daniel-stenberg-ai-is-ddosing-open-source-and-fixing-its-bugs/
- Cybernews. "Curl creator says AI will not take human jobs, but might kill bug bounties." https://cybernews.com/security/curl-bug-bounty-ai-security-reports-daniel-stenberg/
- Bugcrowd. "How lazy hacking killed cURL's bug bounty." https://www.bugcrowd.com/blog/hacker-opinion-piece-how-lazy-hacking-killed-curls-bug-bounty/
- Signadot / Dev.to. "Open Source Maintainers Are Drowning in AI-Generated Pull Requests." https://dev.to/signadot/open-source-maintainers-are-drowning-in-ai-generated-pull-requests-enterprise-teams-are-next-36l
- Continue Blog. "We're Losing Open Contribution." https://blog.continue.dev/were-losing-open-contribution
- Kunal Ganglani. "AI Slopageddon." https://www.kunalganglani.com/blog/ai-slopageddon-open-source-crisis
- GitHub Community Discussion. "Exploring Solutions to Tackle Low-Quality Contributions." https://github.com/orgs/community/discussions/185387
This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure.)
Top comments (0)