Google's pause on its open-source bug bounty is a warning about report volume, not about bugs

By Eli - Published: 7 October 2026

On 1 October, Google quietly stopped accepting product vulnerability reports through its open-source vulnerability reward programme. The Hacker News reports the cited reason: "a significant rise in automated submissions, the vast majority of which are not valid." Google did not say whether AI tooling is behind the flood, and we should not assume it for them, though the timing sits uncomfortably alongside everything else maintainers have been saying this year.

What exactly stopped

The pause covers the 26 flagship repositories, including Go, Angular, Flutter, Bazel and Protocol Buffers. The cash rewards for them, previously $500 to $7,500 for flagship projects and $101 to $3,133.70 for the "important" tier, are gone for now. Supply chain compromises of those projects, leaked credentials and reports filed before 1 October stay in scope. Google says it will give an update in the first quarter of 2027. Researchers are pointed to Cloud VRP for cloud products, the Patch Rewards Program (up to $15,000) and each project's own security channel. The Go project had already added guidance in early September against unfiltered machine-generated reports, and Google had tightened its proof requirements back in March.

Why a bounty buckles

A bounty programme is a triage queue with a price on the front door. Pay for valid reports and you also pay for people to try their luck. When producing a plausible-sounding report costs close to nothing, the maths turns: the cost of reading and rejecting each one stays with a small, usually unpaid, group of humans. Google is not the first project to feel this, only the largest. Worth noting is that real findings do get lost in the process, because a maintainer who has dismissed forty bad reports this week will read the forty-first with less patience.

What it means if you build on this code

• Do not read a quieter bounty as a quieter bug rate. Vulnerabilities in Go modules or Angular will still exist; the reward for reporting them privately has just dropped, and some researchers will go elsewhere with what they find.
• Subscribe to the security channels of the open-source projects you depend on directly, rather than waiting for a scanner to catch up with a CVE.
• If your own organisation runs a bounty or receives security mail, measure the share of reports that are valid and the hours spent on the rest. That number tells you when you are near the same cliff.
• Ask your suppliers how they will handle upstream fixes if disclosure slows. A software bill of materials only helps if somebody is watching the components on it.
• Consider funding upstream triage. A few days of an engineer's time spent reproducing reports for a project you rely on is cheaper than an incident caused by one that sat unread.

We help teams set up dependency monitoring and intake processes that survive a bad week. Email sales@halfteck.com to talk it through.