Google Paused the OSS Bug Bounty: Triage Is the Scarce Skill

TL;DR

• A bug bounty is a programme that pays outside researchers who report security flaws, and an open-source bug bounty runs the same process for a project whose code anyone can read and reuse. Triage is the part where a team reads each report, reproduces it and confirms whether a real defect exists. That confirmation work is a skill and a cost, and it is what a programme is organised around.
• Google stopped accepting product-vulnerability reports to its Open Source Software Vulnerability Rewards Program on 1 October 2026, and gave the reason in one line: a significant rise in automated submissions, most of them invalid.
• Supply-chain reports, reports already filed, and some Google Cloud repositories stay in scope. The programme comes back with an update promised in the first quarter of 2027.
• curl reached the same wall in January 2026, at a confirmed-report rate that fell from more than 15% to below 5% and stayed there.
• Producing a report that reads like a disclosure costs almost nothing now. Reading one carefully still costs an engineer an hour.
• Paying for proof of reproduction is the intake rule that survives a flood.

What Google paused on 1 October

The Open Source Software Vulnerability Rewards Program takes reports about code defects, logic flaws and design bugs in Google's public repositories, and pays for them. Since 1 October 2026 it no longer accepts product-vulnerability submissions. Google announced the change on X and on the programme's own page, and stated the cause plainly: "This pause is due to a significant rise in automated submissions, the vast majority of which are not valid."

Read the scope carefully, because the pause is narrower than the headline and wider than one programme. Reports already submitted before 1 October are unaffected, supply-chain reports continue to be accepted, and Google's note says that reports covering product vulnerabilities in some Google Cloud repositories may still be accepted through the Cloud VRP. Researchers are pointed at the other reward programmes and at the Patch Rewards Program in the meantime, with the reformatting promised to arrive with an update in Q1 2027.

The queue that broke first belonged to curl

The curl project ran a bug bounty from April 2019 to 31 January 2026, and its founder published the arithmetic on the way out. Over the programme's life curl confirmed 87 vulnerabilities and paid more than 100,000 US dollars in rewards, which is a good return for a library that sits under a large share of the world's HTTP traffic. The rate that mattered was the confirmed-report rate, and Daniel Stenberg described it in his January post: "Previous years we have had a rate of somewhere north of 15% of the submissions ending up confirmed vulnerabilities. Starting 2025, the confirmed-rate plummeted to below 5%. Not even one in twenty was real."

There is a second data point in the same post that is easy to miss and worth keeping. HackerOne gave curl volume figures for its programme against a cohort of other open-source bounties, and curl's inbound report volume rose sharply over four quarters while programmes such as Ruby, Node and Rails stayed flat or declined. Stenberg's reading is that money attracts both kinds of report and makes it easy to be a nuisance at no cost, and that the platform's reputation system was not enough to keep the sand out of the machine.

What became cheap, and what stayed expensive

A language model given a repository and the instruction to find a vulnerability produces something that looks the part: a CVE-style title, a plausible root cause, a proof-of-concept block, a severity rating. What it often does not produce is a bug that exists. Tom's Hardware reported that Google engineers and maintainers were being overwhelmed by thousands of reports that were invalid or unexploitable hallucinations, and that validating them consumed time that belonged to fixing real defects. Stenberg described the workload in the same terms: the slop submissions "take a serious mental toll to manage and sometimes also a long time to debunk."

That is the whole asymmetry in one sentence, and it is worth pricing. Generating a report costs a few minutes of prompting and no domain knowledge. Confirming one costs an engineer who knows the codebase, a build, a reproducer, and enough patience to trust the negative result.

Four other programmes met the same wall in 2026

Google had already been adjusting. In May 2026 it reduced standard Chrome payouts and began favouring concise reports that provide concrete proof a bug exists, and for Android it moved the top reward for a zero-click Pixel Titan M exploit with persistence from 1 million to 1.5 million dollars, steering money toward the categories that are harder for automated tools to find. In March 2026, HackerOne's Internet Bug Bounty paused new submissions, saying the speed and volume of AI-assisted discovery had outpaced the community's ability to ship fixes. Tom's Hardware also records a maintenance consequence rather than a bounty one: the Linux kernel ended support for older network drivers after a rise in false AI-generated bug reports.

Put those four together and the pattern stops looking like a Google problem. When discovery gets cheaper than remediation, the constraint moves to the people who read, reproduce and fix.

The intake rules that keep a queue readable

For a team that publishes a security contact and receives reports from strangers, the rules that keep the queue workable are short and mostly about what arrives at the door.

• A report earns a developer's time when it carries a reproducible proof of concept: the exact version, the configuration, the input and the observed output.
• The first question in triage is whether the bug exists in a supported release. Google's own programme pages put product scope at the centre, and curl's experience says the version check removes most of the queue.
• Every submission gets a time box. Thirty minutes to reproduce or dismiss, then it leaves the queue with a written reason, which is also the only fair way to treat a reporter who turns out to be right.
• One named owner holds the queue. A shared inbox with no owner is how a week of analyst time disappears.
• Publish the confirmed-report rate internally. It is the only number that shows whether the intake process is filtering or simply absorbing.

Take a concrete case. Imagine a twenty-five-person software company in Lyon that publishes a security contact address and, until now, has treated the inbox as a shared courtesy. Two of the reports it receives in a month turn out to be real. Reading the rest far enough to know costs about an hour of developer time each. The change that helps here is a rule set: what a report must carry to enter the queue, who decides, and how long the decision is allowed to take. Tone and tooling come after that.

The same ownership question applies to the alert queue once a bug is being exploited: infrastructure monitoring with plain-language alerts is worth exactly what the person receiving the alert can act on, which is why naming the owner comes before adding another feed.

What a public programme tells a private one

Two decisions in Stenberg's post are worth copying for reasons other than cost. The first is dropping the reward entirely instead of narrowing it: he wrote that he considered charging researchers a fee to submit and rejected it, on the grounds that international payments add friction, chargebacks add work, and a fee would filter out people who find real bugs as well as the noise. The second is keeping the reports, only cheaper to receive: curl still wants to hear about security problems, and moved intake to GitHub's private vulnerability reporting so the change of rules stayed visible.

The honest limit of all this is worth stating, because it is the reason our earlier analysis of vulnerability remediation keeps coming back. Intake discipline decides how fast a real report reaches a maintainer. It does nothing about how fast the fix ships, which depends on test coverage, release cadence and whether anyone can reproduce the environment the reporter used. A programme that measures only reports received will feel busy and learn nothing.

Sources

Source: Google Open Source Software Vulnerability Reward Program rules — bughunters.google.com/about/rules/open-source/google-open-source-software-vulnerability-reward-program-rules, captured 2026-10-05 (programme scope: code defects, logic flaws and design bugs in Google's public repositories, with guidance to route Google Cloud and AI repository reports to the Cloud VRP or AI VRP). Source: Google Bug Hunters rules and rewards — bughunters.google.com/about/rules, captured 2026-10-05 (the family of reward programmes and their published structure). Source: Google Narrows Open Source Bug Bounty Amid Wave of Invalid Automated Reports — securityweek.com, published 2026-10-05 (pause announced on X on 1 October; Google's statement that "This pause is due to a significant rise in automated submissions, the vast majority of which are not valid"; product vulnerabilities only, with supply-chain reports and pending reports unaffected; "This change does not affect product vulnerabilities submitted before October 1, 2026"; some Google Cloud repositories still reportable through the Cloud VRP; "We will continue to reformat and work on this aspect of the OSS VRP and commit to giving an update in Q1 2027"; programme introduced in 2022; May 2026 Chrome payout reductions favouring concise reports that provide concrete proof; Android priority on vulnerability types AI tools find less easily, with the top zero-click Pixel Titan M reward moving from 1 million to 1.5 million dollars; HackerOne's Internet Bug Bounty pausing new submissions in March 2026). Source: Google freezes open-source bug bounty program amid flood of invalid AI slop submissions — tomshardware.com, retrieved 2026-10-05 (thousands of invalid or unexploitable hallucinated reports; maintainer time spent validating code instead of fixing defects; the Linux kernel ending support for older network drivers over false AI-generated bug reports). Source: Google froze its open source bug bounty program due to a 'significant rise' in AI submissions — techcrunch.com, retrieved 2026-10-05 (pause as of 1 October, update promised in Q1 2027). Source: The end of the curl bug-bounty — daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/, published 26 January 2026, retrieved 2026-10-05 (programme from April 2019 to 31 January 2026; 87 confirmed vulnerabilities and over 100,000 US dollars paid; confirmed rate above 15% falling below 5% from 2025; the slop taking "a serious mental toll to manage and sometimes also a long time to debunk"; curl's inbound volume rising while the Ruby, Node and Rails cohort stayed flat or declined; the rejected idea of charging researchers; the move to GitHub private vulnerability reporting with no monetary reward). Source: curl pull request 20312, "BUG-BOUNTY.md: we stop the bug-bounty end of Jan 2026" — github.com/curl/curl, retrieved 2026-10-05. Source: Privately reporting a security vulnerability — docs.github.com, captured 2026-10-05 (the private reporting channel curl adopted). Internal linkage: Vulnerability Remediation Needs Production Context. More on Netics' work at infrastructure monitoring with plain-language alerts.

Source: Google Bug Hunters programme pages — bughunters.google.com, captured 2026-10-05; SecurityWeek, Tom's Hardware and TechCrunch reporting — retrieved 2026-10-05; Daniel Stenberg's curl bug-bounty post — daniel.haxx.se, 26 January 2026; curl pull request 20312 — github.com/curl/curl; GitHub documentation — docs.github.com. Figures: screenshots of the official Google Bug Hunters rules page and GitHub's private vulnerability reporting documentation, captured 2026-10-05.