Google Stopped Paying for Open-Source Bug Reports. A Reward Cannot Fix a Queue Where Submitting Is Free

On 1 October 2026, Google stopped accepting product-vulnerability reports through its Open Source Software Vulnerability Reward Program (OSS VRP). Its stated reason, posted on X and quoted by SecurityWeek, was a significant rise in automated submissions, the vast majority of which were not valid. Google did not publish how many reports arrived, how many were invalid, or how many people were reviewing them. What it did say is enough to see the mechanism at work: a reward programme prices a signal, and when producing a plausible-looking signal becomes nearly free, the price attracts noise faster than the programme can read it.

What Google paused and what it left open

The OSS VRP launched in 2022 to pay researchers who report vulnerabilities in Google's open-source projects; Help Net Security names Go, Angular and Protocol Buffers among them. The pause covers product vulnerabilities, meaning bugs in those projects' own code. Reports submitted before 1 October are unaffected, according to Google's programme page as quoted by SecurityWeek. Still open are supply-chain reports, pending reports, and some Google Cloud repositories that Google says may still accept product reports through its Cloud VRP. Researchers are pointed to Google's other reward programmes and to its Patch Rewards Program, which pays for improving open-source security rather than for reporting bugs. Google committed to an update in Q1 2027 and said it would continue to reformat the programme.

This is not the first such step. SecurityWeek notes that Google changed its Chrome and Android reward programmes in May in response to AI-driven vulnerability discovery, and that HackerOne's Internet Bug Bounty paused new submissions in March for similar reasons. Different programmes, a similar pattern: the first response to a flood is closure, not repricing.

Why a reward becomes a lottery with free tickets

Think of each submission as having two costs borne by two different parties. The submitter pays the cost of producing a report. The programme pays the cost of verifying it: reading the claim, reproducing the bug, deciding whether it is real and whether it matters. For most of the history of bug bounties, the first cost was high. Finding a genuine flaw took skill and hours, which acted as a filter. A language model collapses that cost. A tool can scan a repository, produce a confident description of a possible flaw, and file it, at a marginal cost close to zero.

Now apply simple expected-value logic. A submitter files if the chance of being paid, multiplied by the reward, exceeds the cost of filing. When the cost approaches zero, any non-zero chance justifies another ticket. Meanwhile the verification cost does not fall. Reproducing a claimed buffer overflow takes a human the same time whether the report was written by a veteran researcher or generated by a script. So the programme's cost scales with the number of submissions, while its benefit scales only with the number of valid ones.

An illustration, which is ours and not Google's data: if a reviewer spends one hour per report and one in 20 reports is valid, each real finding costs 20 reviewer-hours to surface. If the valid share drops to one in 200, the same finding costs 200 hours. Nothing about the valid findings changed. The denominator did. That is why a ratio, not a volume, is what breaks a queue, and why Google's statement about the share of invalid reports is more informative than any headline count would have been. It is also the number Google has not published.

Why raising the bar does not fix it

The intuitive remedies each fail the same test. Lowering the reward does not help much, because the submitter's cost is near zero and a small prize still beats nothing. Raising it makes the lottery more attractive. Asking submitters to be more careful depends on goodwill that a script does not have. A reward floor, a minimum severity or a stricter checklist all leave the verification cost on the programme, because they are checked after the report arrives.

What changes the arithmetic is moving cost back to the submitter before review begins. Options a programme can use include requiring a runnable proof of concept that an automated harness can execute, so the first filter costs machine time instead of human time; reputation tiers, where new accounts have a small daily quota and established reporters do not; or a refundable deposit that is forfeited on invalid reports. Each has a price: a proof-of-concept requirement excludes some genuine reports about hard-to-reproduce bugs, and a deposit would deter students and hobbyists, the people bug bounties have historically helped bring into security work. Google has not said which, if any, it will adopt; it has said only that it will reformat the programme and report back in Q1 2027.

What the pause costs, and the counter-argument

The case against a blanket pause is that AI-assisted reports are not all noise. DrafterDaily's piece on CVE-2026-61500 in Rejetto HFS describes a critical authentication bypass that the security firm Horizon3 says it found with Anthropic's Mythos model. That finding was valid, specific and reproducible, and it was verified by a human firm with a reputation to protect. A pause that treats every automated report the same delays findings of that kind, and pushes researchers toward other programmes or toward public disclosure, which is a worse outcome for the maintainers Google says it wants to protect.

There is a fair rejoinder: the blanket nature of the pause is the point. A programme cannot tell, at submission time, which automated reports are the good ones, and the cheapest way to stop the queue from drowning is to close it, then reopen it with filters. Closing for roughly two quarters and reconsidering in Q1 2027 is a bounded cost, whereas a queue that maintainers stop reading is not. Both views are reasonable, and the evidence available does not let us choose: Google has published no validity rate, no volume, and no description of how many valid AI-assisted reports it received during the same period.

Two other claims circulating in secondary coverage are not used here. Some outlets repeated that Intel suspended a bug bounty of up to $100,000 per flaw and that Linux maintainers feel overwhelmed by AI-generated CVEs. None of the primary or near-primary reports we read mentioned either, so we have left them out rather than repeat them without a source.

What to watch

Three things will show whether the pause was a repricing problem or a filtering problem. First, whether Google's Q1 2027 update arrives with numbers: a published valid-report rate would be the first real data point. Second, whether the reformatted programme adds an up-front cost to submitters, such as a proof-of-concept gate or a reputation tier, which would confirm that the fix is structural. Third, whether other open-source reward programmes follow with their own pauses, which would suggest the asymmetry is general. The same free-to-submit dynamic is visible in a different setting in DrafterDaily's coverage of arXiv capping submitters at two papers per month, where the mechanism is moderator workload per submitter rather than bounty economics.

For maintainers and security teams, the practical reading is narrow and useful: where your own intake is open and unpriced, the number to track is the valid share, not the submission count, and the first control to add is one that makes a submitter spend something before a human spends anything.