Google stopped paying for open-source product bugs on 1 October; curl quit first and published the numbers
Google closed product-vulnerability reports to its open-source bounty programme on 1 October, saying automated submissions had overwhelmed it; here is what the earlier exits at curl, HackerOne, Node.js and Intel cost, which parts of the story the research supports, and what a product team should change.
The bounty programme that paid researchers for flaws in Google's open-source code stopped taking product vulnerabilities on 1 October. Reports filed before that date still stand, and supply-chain reports remain open. Everything else in that category is on hold until Google's promised update in the first quarter of 2027 1.
Google's explanation runs to one sentence: "This pause is due to a significant rise in automated submissions, the vast majority of which are not valid" 2. The post points researchers at the company's other reward programmes, or at its Patch Rewards scheme.
Two days later, System76's COSMIC desktop project tightened the other end of the same pipe. Its pull-request template now asks contributors to certify that a change contains no LLM-generated code, comments or descriptions, and that they understand it well enough to answer review feedback; a pull request without the completed checklist may be closed 34. In August, COSMIC asked contributors to disclose AI-written code. The new rule forbids it.
Both belong to a queue that has been forming since January, and the order of those exits is what a product team can use: the money left first, and the intake rules followed it.
Loading content card…
That video starts at the earlier case, walking through what a bug bounty pays a researcher for and what an unverified AI-written report looks like when it reaches a maintainer.
What Google turned off
Google's rules page now carries the change in two places. The product-vulnerability section opens with the pause, its date and the alternative routes: repositories tied to Google Cloud products can still be reported through the Cloud VRP, and the Patch Rewards programme stays open. The reward table further down the same page lists product vulnerabilities as a dash in all four project tiers 1.
Supply-chain rewards survived untouched, and their amounts are published: $3,133.70 to $31,337 for a compromise in a flagship repository, $1,337 to $13,337 in an important one, and $500 to $3,133.70 in a standard one 1.
That split deserves a second look, because it separates two kinds of claim. A supply-chain report names something specific that a team can test: whether a main branch accepts outside commits, whether a build pipeline hands out a signing key, whether a credential leaks. A product vulnerability report says how code behaves, and testing it means reconstructing an execution path that arrived in prose. Google kept paying for the first kind and stopped paying for the second.
What the earlier exits cost
curl ran its bug bounty from April 2019 until 31 January 2026, and Daniel Stenberg, its maintainer since 1996, published the accounting the day he ended it. The programme paid out more than $100,000 across 87 confirmed vulnerabilities. The share of submitted reports that turned out to be real had run above 15% for years, and from 2025 it fell below 5%. "Not even one in twenty was real," Stenberg wrote 5.
He also published the chart below, drawn from HackerOne's platform data. curl's inbound report volume rose from 16 in the first quarter of 2025 to 80 in the fourth, while the average for a cohort of public open-source bounty programmes on the same platform stayed between 22 and 29 all year 5. The flood arrived at one project, at a rate its neighbours never saw.
Stenberg's own reading of the incentive is worth carrying into any programme design: "We suspect the idea of getting money for it is a big part of the explanation. It brings in real reports, but makes it too easy to be annoying with little to no penalty to the user" 5.
Some of the exits that followed were forced. HackerOne paused new submissions to its Internet Bug Bounty programme on 27 March, describing a shift in "the balance between findings and remediation capacity in open source" 6. Node.js, funded through that programme since 2016, ended its own payouts because a volunteer project of its size has no budget to replace them 7. Intel's programme on the Intigriti platform shows as suspended, and the disclosure programme that replaced it pays nothing; Intel has said nothing publicly about what drove that decision 89.
A researcher watching the Google notice go up put the change in two lines: "manual disclosure era: android kernel pocs + black hat talk on attacking the prng / automated era: google stops accepting oss vrp product reports / we had a good run" 10. A security engineer drew the cost in one sentence: "Triage time is the real cost of AI bug hunting done badly, and honest researchers pay for it" 11.
What the research establishes
Four research items published this year separate the volume problem from the story told about it.
The first is a survey of AI slop in vulnerability assessment, posted in August. It defines the category as artifacts carrying high linguistic fluency and plausible structure while failing on meaning, and sorts them into three shapes: invented vulnerabilities, patches that compile while missing the cause, and earlier findings repackaged as new discoveries. It cites roughly 20% of reports through HackerOne's bug bounty programme being identified as low-quality AI slop by mid-2025, with valid reports down to around 5%, and describes the load on a triage team as a burden that "mirrors a denial-of-service attack" 12. Its prescription is to treat a generated finding as a hypothesis that something deterministic then has to confirm, and it argues against the remedies proposed first: detection and watermarking, in its account, establish where a report came from rather than whether it is correct 12.
The second measures what happened to the projects. One study covered 294 repositories and more than two million pull requests and issues, and found pull-request volume rising through 2025 while merge rates fell: for a contributor making a first contribution, the merge rate dropped 18.18% against a modelled counterfactual. Its authors call the effect "AI-DDoS" and describe a sustainability trap, in which communities protect short-term review capacity through measures that make openness harder to sustain; they drew 11 remediation strategies from practitioner interviews and tested them in a survey of 229 open-source practitioners 13. Those strategies sort into three orientations — preservative, adaptive and transformative — and the paper's warning is that the cheapest ones protect review capacity while making a project less open to the next newcomer 13.
The third study, of how developers discuss the problem across 1,154 Reddit and Hacker News posts, frames it as a tragedy of the commons: each contributor's productivity gain lands as a cost on whoever reviews the result 14.
The explanation most people reach for is that coding agents absorbed the easy beginner tasks and crowded newcomers out. The fourth study tested that directly, across 1,888 projects that adopted a coding agent compared with matched controls that did not. Newcomer inflow held, onboarding held, retention held — while the code itself grew harder to read, about 11% more complex on a cognitive metric for Python and 3% to 4% on a cyclomatic metric across languages 15.
What the numbers support is narrower and more useful than either the panic or the reassurance. Producing a submission became close to free. Checking one did not, and the difference lands on the people who review other people's work.
What projects do instead of paying
Kubernetes wrote its position down in June, and it is the most complete public example of the middle path. Contributors must state in the pull request that AI tools assisted. Listing AI as a co-author is banned, as are trailers such as "assisted-by" and "co-developed", and the project switched on its contributor-licence check for co-authors, a check that AI agents cannot satisfy. Reviewers expect to be talking to a person: "If you cannot personally explain changes that AI helped generate, your PR will be closed" 16.
Kubernetes also ran the remedy in the other direction, rolling AI review tools such as CodeRabbit into a few of its repositories so that a contributor gets a first pass without a maintainer, and a maintainer's attention starts on work that has already cleared a check 16.
COSMIC took the strict route. Jeremy Soller gave the reason as review load: more first-time contributors were sending LLM-written changes, and many of them were unplanned and rarely accepted 4. The template turns that judgement into a checkbox, which is why the screenshot below is worth reading as a document rather than a slogan: the certifying contributor also confirms they understand the change, can answer review comments, tested the work, and accept the project's developer certificate of origin 3.
Ladybird went furthest in June, closing public pull requests altogether and accepting changes from maintainers only. Andreas Kling's explanation is the clearest account of what AI did to contribution as a signal: "A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds" 17. He closed the queue that existed rather than let it stand, on the argument that an open queue keeps a contribution path open in practice.
curl sits in the opposite corner, and Stenberg's reason is the one worth copying. Pull requests never became a problem for curl because CI absorbs them: "We don't need to waste any human time on pull requests until the quality is good enough to get green check-marks from 200 CI jobs" 5. The submissions that killed its bounty were prose about behaviour, and no pipeline could check those.
The industry's own suggestion for what replaces the payout model arrived from Bugcrowd's chief strategy and trust officer in April: bonuses for researchers who bring fixes rather than findings, and shared pools that fund the maintainer team shipping the patch as well as the researcher who reported it 6.
Where your product sits
- You run a bug bounty or a vulnerability disclosure programme. Compare your intake against Google's split, between reports that name an artifact a machine can test and reports that describe behaviour. The second kind is where your triage hours go, and the three largest programmes in open source have each changed their rules rather than scale the queue 156.
- Your engineers point coding agents at repositories you do not own. Every project named here now has a written rule, and the rules disagree: Kubernetes wants disclosure, COSMIC closes the pull request, Ladybird takes maintainer code only 31617. Put the relevant rule into the agent's own instructions before it opens anything.
- You depend on open-source infrastructure. A drop of 18.18% in merge rate for first-time contributors changes how quickly fixes land in the projects that accept outside work 13. Maintainer attention is the resource being reallocated, and the dependency list is where you will feel it.
- You accept contributions to a repository of your own. Disclosure, accountability and verification are three separate controls, and Kubernetes implemented all three 16. Decide which one your review process currently leans on, and what a reviewer can actually check.
- You are building agents that produce findings or patches. The survey's recommendation is to score provable findings rather than fluent ones, and it proposes two instruments, CVE-Bench and Slop-Score, to do that 12. An agent that cannot reproduce its own result hands that work to whoever receives it.
A 90-day watching brief
- Count what your intake costs before you change it. Split last quarter's reports into claims with a reproducible artifact and claims without one, and put a number on the triage hours the second group took 12.
- Write down your contribution rule for agent-assisted work, and put it in the repository's pull request template rather than a wiki page. That is where it becomes a control instead of a preference 3.
- Decide how a reviewer reaches a human. Kubernetes allows AI assistance and requires the human to answer for it, which is a rule you can copy verbatim into your own guide 16.
- Check whether your bug bounty pays per report or per accepted finding. The first model made submissions free at the margin, which is what the curl numbers record 5.
- Ask which of your dependencies changed intake or bounty rules this year, and note who now reviews the changes you rely on 7.
- Diary the first quarter of 2027. Google committed to an update on the OSS VRP then, and that document will say whether the pause became a redesign or a permanent narrowing 1.
The decisions, with the clock on them
| Decision | What the sources provide | The constraint that decides it | Act when |
|---|---|---|---|
| Whether to keep paying for behaviour-style reports | Google's split between the claim kinds, and the withdrawal from one of them 1 | Triage hours against a fixed reviewer count 12 | At your next bounty or disclosure-policy review |
| Whether to require disclosure, certification, or maintainer-only intake | Three published rules that take three different positions 31617 | How much review your team can do, and how much of the contributor base you need | Before the next agent-assisted pull request arrives |
| Whether to gate agent output before it is submitted | curl's finding that CI absorbs code while prose defeats humans 5 | A reproduction step costs the sender minutes and the reviewer hours | At your next agent-tooling review |
| Whether to pay for findings or for fixes | Bugcrowd's proposal of bonuses for fixes and pooled funding for reviewers 6 | The incentive that made submissions free at the margin | When you next budget the programme |
| Whether the supply-chain channel needs a different owner | Google kept the door open that carries a checkable artifact 1 | Your build and signing infrastructure is what the reports are about | Before your next release signing review |
Google's own page is the source for the pause, its date, its scope and the reward table, and the company's word for the cause is "automated"; the AI reading of that sentence comes from the coverage around it. The curl figures, including the peer comparison, are the maintainer's own accounting, published with the platform data behind the chart. The HackerOne pause, its stated reason and the Node.js consequence come from reporting that quotes HackerOne's announcement, and the Intel suspension rests on trade reporting that also notes Intel gave no reason. The four research items were posted to arXiv, and they measure different things: 294 repositories in one, 1,888 adopting projects in another, 1,154 forum posts in a third, and a literature survey in a fourth. Their findings fit together — merge rates for first-time contributors fell while newcomer participation held — but each covers a slice of the ecosystem rather than the whole of it.
References
- 1Google Open Source Software Vulnerability Reward Program Rules
bughunters.google.com
- 2Google VRP on X
x.com
- 3cosmic-epoch pull request template
github.com
- 4
- 5The end of the curl bug-bounty
daniel.haxx.se
- 6
- 7
- 8Intel Ends Its $100,000 Bug Bounty Program
techpowerup.com
- 9
- 10Sagi Kedmi on X
x.com
- 11
- 12
- 13"AI Slop is DDoSing Open Source"
arxiv.org
- 14"An Endless Stream of AI Slop"
arxiv.org
- 15
- 16Open source maintainership in the age of AI
kubernetes.io
- 17Changing How We Develop Ladybird
ladybird.org
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.