Google Stops Taking Product Vulnerabilities in Its Open Source Reward Program - Effective October 1, With an Update Promised for Q1 2027

Google's OSS VRP rules now state that product vulnerabilities are not accepted from October 1, 2026. Payouts for supply chain compromises remain in the table, so only the product vulnerability category stopped. Reporting cites a rise in automated submissions as the reason.

Google security open-source bug-bounty vulnerability AI-agents

The rules for Google’s Open Source Software Vulnerability Rewards Program (OSS VRP) now carry a line saying that product vulnerabilities are not accepted on or after October 1, 2026¹. Google says it will carry on reworking this part of the program, and has promised to say more at some point in Q1 2027.

What stopped is a reporting category, not the program. In the rules’ reward table, the figures for supply chain compromises (3,133.7 to 31,337 dollars in the top tier) and for other security issues are still there; it is the product vulnerability row that reads as a dash across all four tiers¹.

What stopped and what stayed

The OSS VRP pays for vulnerabilities in open source projects Google publishes, and the program describes Google’s position as the maintainer of projects including Golang, Angular and Fuchsia². Reports fall into three broad categories, and one of them has closed.

Category	OT0 (Flagship)	OT1 (Important)	OT2 (Standard)	OT3 (Low-priority)
Supply chain compromises	$3,133.7 - $31,337	$1,337 - $13,337	$500 - $3,133.7	-
Product vulnerabilities	-	-	-	-
Other security issues	$1,000	$500	-	-

On supply chain compromises, the rules say such reports — those touching source or build integrity — are the ones Google welcomes first and foremost¹. The examples given include being able to put code onto a repository’s main branch, weaknesses in the GitHub Actions configuration of Google’s open source projects, and compromise of the signing keys used for published artifacts. Routes that reach a tampered artifact by way of the build pipeline therefore remain in scope.

Where to send reports instead is also in the rules. For some Google Cloud repositories that affect Google Cloud products, Google says it may still take product vulnerability reports through the Cloud VRP. Otherwise it suggests finding impact under one of its other VRP programs and submitting there, or going through the Patch Rewards Program¹. Anything in that category filed ahead of that date is explicitly left alone.

The reason being given

The rules page itself gives no reason for the stop. TechCrunch reports that Google gave its reason in a post on X and on the program’s own site: submissions produced by automation had climbed sharply, and most of what arrived was invalid³. The publication adds that a year earlier it had covered warnings from security experts about what AI slop — empty, machine-written reports — would do to programs that pay for bugs.

Worth separating out: the wording in the Google statement the report quotes is about automated submissions, while “AI” is the vocabulary of TechCrunch’s headline and framing. Neither the rules nor the reporting puts a number on how many automated submissions arrived, or which projects suffered most.

A report containing hallucinations only reveals itself as worthless once someone on the receiving end has read it through. Because the effort of judging scales with the volume submitted, it plausibly fed straight into the decision about whether to keep the category open.

The acceptance bar is already narrow

The rules spell out acceptance conditions for product vulnerabilities, tier by tier. For repositories in the OT0 and OT1 tiers, a memory corruption finding has to arrive with precise steps to reproduce it under OSS-Fuzz, or with a patch already merged into the target repository. The same rules state that findings in those tiers which are not memory corruption need no merged patch to be submitted. For the Standard (OT2) and Low-priority (OT3) tiers, the rules state that product vulnerabilities are not eligible for a monetary reward¹.

The same rules state the thinking behind that. Google says it aims to wire its OT0 and OT1 projects into OSS-Fuzz where that applies, on the grounds that the approach holds up better and scales further than working through memory corruption reports one at a time¹. Leaning on continuous fuzzing rather than clearing submissions by hand points in the same direction as this pause, it seems reasonable to say.

The rules also carry a clause describing this as an experimental, discretionary rewards program rather than a competition, one that can be cancelled at any time¹.

What a reporter should check now

For a product vulnerability found in one of Google’s open source projects, the route to a reward closed on October 1. In practice that means first deciding whether the flaw stands up as a supply chain compromise — whether it reaches source or build integrity — or sits in a repository affecting Google Cloud products. If either holds, the category and destination change. If neither does, what is left is the Patch Rewards Program, which pays for the patch rather than for the report. Its rules put rewards for a qualifying submission in a range from 100 to 15,000 dollars⁴.

One thing to watch is that Google’s guidance is not consistent in one place. As of October 5, 2026, the program overview page still carries reward ranges for product vulnerabilities — 500 to 7,500 dollars for Flagship, 101 to 3,133.7 dollars for Standard². The rules page table shows a dash for the same category, and neither page says which is current. Checking the rules page before reporting is the safer course.

An asymmetry between finding and receiving

The stories tracked on this site over recent months have clustered on the side that finds vulnerabilities. Wiz published Snowflake findings on a hole in a Copilot-reviewed PR that an AI found and exploited in five days, and Hacktron disclosed an attack that started from a libheif flaw and reached OpenAI’s internal repository. Cursor shipped a Security Review bot in September that reports exploitable bugs on each pull request.

What has stopped here is the opposite side: the path that receives reports and judges them. Output on the finding side can rise through machines while the judging stays with people. That asymmetry could plausibly show up the same way outside reward programs, in open source issue trackers and review queues. For anyone accepting outside reports or contributions on their own project, narrowing the intake requirement to reproduction steps or an already-merged patch is the same idea Google applies to memory corruption findings in its two highest tiers.

What the update promised for the first quarter of 2027 will contain is not yet known. Whether reopening comes with changed acceptance criteria, or whether the category itself gets rebuilt, is not stated either.