Google Stops Accepting Product Bug Reports for Its Open-Source Bounty, Citing Automated Submissions

Google has stopped accepting product vulnerability reports to its Open Source Software Vulnerability Reward Program (OSS VRP). The change took effect on October 1, 2026, and Google’s notice, posted on X and on the program’s rules page, gives one reason: “This pause is due to a significant rise in automated submissions, the vast majority of which are not valid.” Google says it will “commit to giving an update in Q1 2027.”

BleepingComputer, TechCrunch, ITPro, Help Net Security and Tom’s Hardware describe those submissions as AI-generated. Google’s notice says “automated submissions,” does not say they are AI-generated, and gives no count. Comparing the live rules page with an archived copy from September 25 also shows changes beyond the product vulnerability row: the Standard tier’s supply chain ceiling fell from $7,500 to $3,133.7, and its $100 reward for other security issues is gone.

What is paused, and what is not

The OSS VRP, announced in August 2022, pays for vulnerabilities in Google’s open source projects, which Help Net Security lists as including Go, Angular and Protocol Buffers. Under the change:

• Paused: new product vulnerability reports. The rules page says, “As of October 1, 2026, we are no longer accepting product vulnerabilities submitted to the OSS VRP.”
• Not affected: supply chain reports and “any outstanding reports,” according to the X post, and product vulnerabilities submitted before October 1, according to the rules page.
• Exception: for “some Google Cloud repos impacting Google Cloud products,” Google says it “may still accept” product vulnerability reports through the Cloud VRP. For projects closely tied to Google Cloud or AI products, it encourages reports to go to the Cloud VRP or the AI VRP.
• Alternatives: Google’s other VRPs, and the Patch Rewards Program, whose page says rewards “range from $100 to $15,000.”

What the rules page lost

The reward table shows the change most clearly. We compared an archived copy from September 25 with the live page, rendering both in a headless browser on October 5 because the page’s text is loaded by JavaScript. These are the table cells that changed. The page calls its amounts “typical rewards for the most common classes of bugs,” and they are copied here as printed:

The top of the scale did not move. The table still lists $3,133.7 to $31,337 for a supply chain compromise at a flagship project and $1,337 to $13,337 for the Important tier, so the most valuable category stays open. The product vulnerability row had topped out at $7,500. The text changed with the table: the rules now say that for OT2 and OT3 projects, product vulnerabilities and other security issues are “not eligible for monetary reward.”

None of the five reports we read mentions the two Standard-tier changes outside the product vulnerability row, and Google’s notice does not either. A sentence that pointed researchers to the OSS-Fuzz Rewards program, next to Patch Rewards, is also gone from the page without explanation. We cannot tell from public records when between September 25 and October 5 each edit was made, and the two copies were rendered separately, so we limited the comparison to the reward table and the rule text quoted here.

The gates were already there

The archived rules show that Google had added friction before the pause. Memory corruption bugs in the top two tiers needed either “exact OSS-Fuzz reproduction steps” or “an already merged patch in the target repository.” Every product vulnerability in the Standard and Low-priority tiers needed a merged patch. The one lane with no such requirement was non-memory-corruption bugs in the top two tiers, which, in the page’s words, “do not require a merged patch for submission.” The page also said “the existence of a patch is a prerequisite but not a guarantee of a reward,” and that the panel judges security impact at its own discretion.

Google’s notice does not say which lane the invalid reports used, so the public record does not show whether they came through that open lane or cleared the merged-patch bar anyway.

Other programs have pulled back, for different stated reasons

The reasons differ. curl and Google point to invalid volume. HackerOne’s statement is about something else: “The balance between findings and remediation capacity in open source has substantively shifted.” That would be a problem even if every report were valid. Intel has not said why, so we do not count it as an AI case. curl’s own policy page states the incentive argument bluntly: “A bug bounty gives people too strong incentives to find and make up ‘problems’ in bad faith that cause overload and abuse.”

How this fits what Google said in March

In March, Google was among the grantors, with Anthropic, AWS, GitHub, Google DeepMind, Microsoft and OpenAI, of a $12.5 million Linux Foundation fund managed by Alpha-Omega and OpenSSF. The press release says: “Maintainers are now facing an unprecedented influx of security findings, many of which are generated by automated systems, without the resources or tooling needed to triage and remediate them effectively.” Google’s own post said the money would help “move security beyond vulnerability discovery to actually deploying fixes” and “turn a flood of AI-generated findings into fast action.”

What still pays after the pause lines up with that emphasis. The supply chain section asks for a demonstrated bypass: “You must be able to demonstrate that the vulnerability is exploitable, bypassing the requirement that external contributors must first have PRs approved.” Patch Rewards pay for fixes, and through the end of 2026 the page offers a 2x multiplier for secure-by-design memory safety improvements to tier 1 projects and 3x for tier 1 projects scoped as “Core infrastructure data parsers.” That is our observation about where the money went, not a reason Google has stated.

Real findings are rising too, which is part of why this is hard to describe as spam alone. Microsoft wrote in May that “The pace and breadth of vulnerability discovery are increasing across the software industry” and that “AI is changing the scale and speed of vulnerability discovery.” We have covered both sides: Wordfence’s AI testing framework found a critical flaw in libheif, and arXiv took a different route to a volume problem by capping each submitter at two papers a month, which we analyzed here.

What to watch:

• The Q1 2027 update. Whether Google publishes submission counts and the share that were invalid, and what “reformat” means in practice.
• The remaining tiers. The Standard tier already changed in ways the notice did not mention; the Flagship and Important rows are the next to watch.
• Whether product vulnerabilities return with a new gate, such as a merged patch or a reproduction in every tier.
• Intel’s explanation. Until it says why, the Intigriti change stays out of the AI count.