Google Pauses OSS Product Bug Bounty Rewards After Surge in Invalid Automated Reports
Google temporarily stopped accepting product vulnerability reports through its Open Source Software Vulnerability Reward Program, or OSS VRP. The pause began October 1 and covers security flaws in Google’s open-source code. Reports submitted before that date are unaffected. The change matters because researchers can no longer use this main route to seek rewards for many serious bugs. The paused reports concern design or implementation flaws that substantially threaten the confidentiality or integrity of user data. Examples include memory corruption in file parsers and path traversal. The program’s flagship projects include Go, Angular, Flutter, Bazel, and Protocol Buffers. Their previously listed product-vulnerability rewards have been removed. Google blamed a significant rise in automated submissions, most of which were invalid. It called the pause temporary and promised an update in the first quarter of 2027. The notice gives no restart date and does not clarify whether unpaid product reports will still be accepted.
What exactly did Google pause in its open-source software bug bounty program?
Google temporarily stopped accepting product vulnerability reports through its Open Source Software Vulnerability Reward Program, or OSS VRP. The pause began October 1 and covers security flaws in Google’s open-source code. Reports submitted before that date are unaffected. The change matters because researchers can no longer use this main route to seek rewards for many serious bugs.
The paused reports concern design or implementation flaws that substantially threaten the confidentiality or integrity of user data. Examples include memory corruption in file parsers and path traversal. The program’s flagship projects include Go, Angular, Flutter, Bazel, and Protocol Buffers. Their previously listed product-vulnerability rewards have been removed.
Google blamed a significant rise in automated submissions, most of which were invalid. It called the pause temporary and promised an update in the first quarter of 2027. The notice gives no restart date and does not clarify whether unpaid product reports will still be accepted.
What is the Open Source Software Vulnerability Reward Program, and what kinds of flaws was it designed to reward?
The Open Source Software Vulnerability Reward Program is Google’s bug bounty program for security problems in its open-source projects. Researchers could report eligible flaws and receive money when those flaws met the program’s rules. The program divided projects into four sensitivity tiers, although only flagship and important projects listed rewards for product vulnerabilities.
A qualifying product vulnerability is a design or implementation flaw in Google’s open-source software. It must substantially affect the confidentiality or integrity of user data in software built with that code. Google’s examples include memory corruption in file format parsers and path traversal. These bugs can let attackers read, alter, or misuse information.
The OSS VRP also covered other security concerns, including supply chain compromises and leaked credentials with write access. Google has paused ordinary product-vulnerability submissions, but supply chain reports and some other eligible reports retain their listed rewards. The program’s rules now promise a future update while Google reworks this area.
How much could researchers previously earn for valid product vulnerabilities in Google's flagship and important open-source projects?
Before the pause, Google listed different rewards according to project sensitivity. For valid product vulnerabilities in flagship repositories, the published range was $500 to $7,500. For important repositories, it was $101 to $3,133.70. These were bounty amounts, not automatic payments for every submitted report.
The flagship tier included major projects such as Go, Angular, Flutter, Bazel, and Protocol Buffers. Google’s repository list named 26 flagship repositories and 47 important ones. A report still needed to describe an eligible design or implementation flaw and show that it substantially affected user-data confidentiality or integrity.
The reward amounts disappeared from the rules in the same change that added the suspension notice. That update appeared on Google’s public GitHub copy of the rules on September 30, one day before the public announcement. Supply chain compromises and other eligible issues kept their listed rewards.
Why did Google say that automated submissions were overwhelming the program, and what made most of them invalid?
Google said the OSS VRP received a significant rise in automated submissions. According to its October 1 post, the vast majority were not valid. That volume made the ordinary review process harder to manage and prompted a temporary pause in product-vulnerability reports. Google did not publish submission figures.
The article does not identify exactly why each automated report was invalid. However, an earlier program change required stronger proof for some tiers, including evidence such as a patch already merged into the project. The goal was to filter out low-quality reports. The article also notes that some AI-generated submissions had included invented details about triggering supposed vulnerabilities.
Google did not say whether the new submissions were made with AI tools. The Go project separately warns researchers to review and filter LLM output because these systems can find real bugs and report nonexistent ones. Large amounts of unfiltered output may receive no credit.
What can researchers do now if they find a security flaw in a Google open-source project?
Researchers who find a flaw should first determine what the flaw affects and which program covers it. Some Google Cloud repositories may still accept product-vulnerability reports through the Cloud VRP when the issue affects a Google Cloud product. The notice does not identify those repositories, and Cloud VRP rules may cap the rating.
Researchers can also submit a security patch through Google’s Patch Rewards Program. It pays $100 to $15,000 for accepted patches, not vulnerability reports. Maintainers must accept the patch, and it must remain in place for one month. A patch fixing only one vulnerability receives case-by-case review.
Google also directs researchers to other reward programs, including the Cloud VRP and AI VRP when relevant. Project policies may provide separate channels. Go accepts email reports, while Google’s organization policy lists g.co/vulnz. Angular currently directs reporters to Google’s Bug Hunters site. The notice does not say whether unpaid OSS reports remain accepted.
Why are supply chain compromises and leaked credentials still eligible for rewards when ordinary product vulnerability reports are paused?
A supply chain compromise threatens the software distribution process itself. It can allow someone to tamper with a project’s source code or with packages that users download. Leaked credentials with write access create a similar danger because attackers may gain the ability to change project assets. These risks can spread to many downstream users.
Ordinary product vulnerabilities are different in the program’s classification. They are design or implementation flaws that affect software built with Google’s open-source code. Examples include memory corruption in a file-format parser or path traversal. Google paused reports in this category after receiving many automated submissions, but it did not suspend every security-report category.
The article does not explicitly state Google’s policy rationale for keeping these rewards. The practical distinction is clear from the rules: supply chain compromises and write-access credentials remain listed as eligible, while product-vulnerability reward amounts were removed. Researchers should therefore submit those issues through the applicable continuing program route.
What is a software vulnerability, and how can a flaw in open-source code threaten the confidentiality or integrity of user data?
A software vulnerability is a weakness in a program’s design or implementation that can produce an unintended security result. In Google’s OSS VRP, a product vulnerability qualifies when it substantially affects the confidentiality or integrity of user data. Confidentiality means keeping information secret. Integrity means preventing unauthorized changes.
For example, memory corruption in a file-format parser may let malicious input alter how software uses memory. Path traversal may let an attacker escape an intended folder and access files elsewhere. If such code is reused in applications, the flaw can appear across many products. The actual impact depends on how each application uses the component.
Open-source code is publicly available and often shared widely, so one serious weakness can affect many downstream users. That does not mean every bug is a vulnerability or every vulnerability receives a bounty. Google’s rules focus on substantial data-security impact, and the current OSS VRP pause means ordinary product reports are temporarily not accepted there.
This brief was written by AI from the original reporting and checked by other models. Names, figures and quotes come from the source; read it for full context.
Read more in the JupiteX app
Pulse is free. New stories every 4 hours, each one broken into the questions that explain it.
Or read more news on the web