Google pauses open-source bug bounty as automated reports swamp triage

Google halts intake on its open-source bug bounty

Google stopped accepting product-vulnerability reports to its Open Source Software Vulnerability Rewards Program (OSS VRP) on 1 October 2026. According to a write-up on dev.to, the company announced the change on X and on the programme's own rules page, and attributed the pause to a significant rise in automated submissions, with most of them turning out not to be valid.

The pause is narrower than the headline suggests. Submissions filed before 1 October are still being processed, supply-chain reports remain in scope, and product vulnerabilities affecting certain Google Cloud repositories may still qualify through the Cloud VRP. Until the programme returns — Google has promised an update in the first quarter of 2027 — researchers are being directed to its other reward programmes and to the Patch Rewards Program.

curl shut its bounty down first

The curl project ran a bug bounty from April 2019 until 31 January 2026 and closed it after the economics of the queue inverted. In a January post, founder Daniel Stenberg reported that the programme had confirmed 87 vulnerabilities and paid out more than 100,000 US dollars over its lifetime, but that the share of submissions turning out to be real vulnerabilities fell from above 15 percent in earlier years to below 5 percent starting in 2025 — fewer than one in twenty.

Figures that HackerOne shared with the project, cited in the dev.to piece, show curl's inbound report volume climbing sharply over four quarters while comparable open-source programmes such as Ruby, Node and Rails stayed flat or declined. Stenberg's reading is that reward money attracts both genuine and nuisance reports, and that the platform's reputation system was not enough to filter out the second kind.

What got cheap and what stayed expensive

A language model pointed at a repository can produce something that looks like a disclosure: a CVE-style title, a plausible root cause, a proof-of-concept block, a severity rating. What it frequently fails to produce is a bug that exists. Tom's Hardware reported that Google engineers and maintainers were being overwhelmed by thousands of invalid or unexploitable "hallucinated" reports, and that time spent validating them came directly out of time for fixing real defects. Stenberg described the same workload from the maintainer side, writing that dealing with the junk submissions drains maintainers and can take considerable effort to disprove.

That asymmetry is the story. Writing a report now costs minutes of prompting and no domain knowledge; confirming one still costs an engineer who knows the codebase, can build and run a reproducer, and can be trusted to reach a sound negative result.

Several programmes, one wall

Google had already been adjusting before the pause. In May 2026 it reduced standard Chrome payouts and began favouring concise reports that concretely prove a bug exists, while raising the top Android reward for a zero-click Pixel Titan M exploit with persistence from 1 million to 1.5 million dollars — a category harder for automated tools to reach. 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: the Linux kernel ended support for older network drivers after a rise in false AI-generated bug reports.

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

Why it matters

The binding constraint in open-source security has shifted. Reward budgets were always assumed to be the scarce resource; the events of 2026 suggest reviewer capacity is. Any open intake queue — a funded bounty programme or a plain security contact address — can now be flooded faster than humans can read it, and money does not solve that.

The dev.to write-up proposes intake rules that keep a queue workable: require a reproducible proof of concept carrying the exact version, configuration, input and observed output; first check whether the bug exists in a supported release, since the version check removes most of a queue; time-box every report and close it with a written reason; give the queue one named owner rather than a shared inbox; and track the confirmed-report rate internally, because it is the only number that shows whether intake is filtering rather than simply absorbing. For maintainers and security teams alike, those rules — not bigger payouts — are what decide whether a programme survives contact with automated reporting.