Google Pauses New OSS VRP Product Bug Submissions

Google stopped accepting new product-vulnerability submissions to its Open Source Software Vulnerability Reward Program (OSS VRP) on October 1, 2026, after what it called a “significant rise in automated submissions, the vast majority of which are not valid”. The cutoff applies to the product-vulnerability category of Google’s open-source bounty, rather than the whole program.

According to Tom’s Hardware’s account of the announcement, supply-chain submissions and product findings filed before the cutoff are unaffected, some flaws in Google Cloud repositories may qualify through the separate Cloud VRP if they affect Google Cloud products, and Google has promised a program update in the first quarter of 2027. The terms for restarting new OSS VRP product submissions remain unspecified.

The pause is defined by the finding

The stopped category covers a newly discovered vulnerability in the behavior or implementation of a Google open-source product. A flaw in code or logic remains a product finding even if it is serious, reproducible and found by a human researcher. An automated tool’s involvement does not change which category a finding belongs to. The program boundary follows the nature of the security impact, not the researcher’s method.

Supply-chain compromise concerns control over what a project builds or distributes: for example, exposed credentials that allow unauthorized changes to source code or a package release. That differs from a defect an attacker exploits in software after it has been installed. The distinction matters because the intake pause targets new product findings, while supply-chain submissions remain eligible for consideration under the OSS VRP’s existing rules.

Where each finding can go now

The available route depends on what the finding affects and whether it was already submitted. For researchers deciding where a case belongs, the categories work as a decision tree:

New product flaw in a Google open-source project: New OSS VRP product-vulnerability submissions are paused. A different Google reward program is an option only if that program covers the affected product and demonstrated impact.
Supply-chain compromise: OSS VRP still accepts this category. The security issue must concern the integrity of source code, the build or the project’s distribution, rather than only a defect in the finished product’s behavior.
Flaw in a Google Cloud repository: Some product findings may fit Cloud VRP when they have an impact on a Google Cloud product. Merely locating the defect in a Cloud-associated repository does not establish eligibility.
Product finding already filed: An existing submission remains under consideration because the cutoff governs new intake. Its filing status, rather than whether the researcher has since added evidence, is the relevant distinction.
Security improvement or patch: The separate Patch Rewards Program is a possible route for eligible proactive work that improves open-source security. A patch contribution serves a different purpose from filing a newly found product vulnerability.

The Cloud option is narrow: it rests on product impact, not repository branding. The patch option likewise applies to improvements that meet that program’s own rules. Choosing a different form does not by itself make a paused OSS VRP product submission eligible, and the continued handling of pending cases does not extend to newly filed ones.

Earlier rules had already demanded stronger proof

In its March 19, 2026 rule update, amended in April, Google described AI-generated claims with invented vulnerability triggers and coding errors with negligible impact or unreachable code paths; it required exact OSS-Fuzz reproduction steps using an existing target or a merged patch for memory-corruption findings in its OT0 and OT1 tiers, and later ended monetary rewards and credit for product vulnerabilities and other security issues in OT2 and OT3.

Those requirements show why automated discovery is only the beginning of vulnerability research. A scanner can identify a pattern that resembles a bug, but a usable finding must establish how the relevant code can be reached, what triggers the behavior and what security consequence follows. If the alleged trigger does not exist, the claim fails at reproduction. If the code is unreachable or the project’s security model limits the effect, a real coding defect may still have little security value.

The earlier changes sought more concrete proof and greater security impact from submissions that reached triage. The intake pause goes further: even a carefully validated new product vulnerability falls within the stopped category. Google’s public explanation identifies a surge of invalid automated submissions, but gives no count of rejected findings or threshold for resuming intake.

The next milestone for product findings

Researchers with a new product flaw must assess eligibility under another program’s scope before submitting it there. Supply-chain findings and eligible security improvements retain their distinct routes, while already filed cases continue through existing handling. Google’s promised update is the next point at which researchers may learn how new OSS VRP product-vulnerability submissions will be handled.