The Erosion of Open Source Bug Bounties: Google Pauses Product Vulnerability Rewards
In a significant shift for the cybersecurity landscape, Google has officially announced a temporary halt to its Open Source Software Vulnerability Reward Program (OSS VRP) regarding "product-facing" vulnerability submissions. This decision marks a pivotal moment in the ongoing struggle between major technology corporations and the deluge of low-quality, AI-generated reports that have increasingly clogged security triage pipelines.
Since its inception in 2022, the OSS VRP has served as a cornerstone of Google’s commitment to open-source security. It provided a structured, financial incentive for independent researchers to hunt for flaws in high-profile projects like Flutter, Angular, Go, and Fuchsia. However, as of October 1, 2026, the intake of these specific reports has been suspended, leaving the community to grapple with the future of collaborative software auditing.
Chronology of a Declining Program
The deterioration of the OSS VRP did not happen overnight. It was the result of a long-standing tension between the scalability of automated reporting tools and the limited bandwidth of human security maintainers.
The Rise of AI-Generated "Slop"
By early 2026, Google engineers reported a massive influx of submissions that were either entirely hallucinated by generative AI or flagged as "vulnerabilities" that lacked any real-world exploitability or impact. This phenomenon, often referred to as "AI slop," became an unsustainable burden for the security teams tasked with verifying each report.
Initial Restrictions (March 2026)
In March 2026, Google attempted to stem the tide by raising the bar for entry. They mandated that memory corruption reports for top-tier projects must be accompanied by proof of reproduction through OSS-Fuzz or verified patches already accepted by project maintainers. This was a clear signal that the company could no longer afford to "verify" theoretical bugs that did not have a clear path to exploitation.
Further Contractions (April 2026)
By April 2026, the situation had not improved. Google updated its policy to eliminate rewards or credit for security issues found in standard and low-priority project tiers (OT2 and OT3). Simultaneously, they drastically reduced the payout for supply chain vulnerabilities in OT2 projects to $3,133.70, a move that sent shockwaves through the bug bounty community.
The October 2026 Suspension
The current suspension represents the most drastic measure yet. Effective October 1, 2026, all product-facing vulnerability submissions are rejected. While Google emphasizes that this is "temporary," the lack of a concrete timeline for reinstatement—beyond a vague promise to provide an update in the first quarter of 2027—has left the open-source community in a state of uncertainty.
Understanding the Scope: What Remains?
To navigate these changes, it is critical to distinguish between the types of reports Google still accepts versus those that are now prohibited.
What is Paused?
The suspension applies specifically to "product vulnerabilities." These are bugs inherent to the source code of the project itself. Examples include:
- Logical Flaws: Failures in security-critical components like HTML sanitizers or authentication modules.
- Memory Corruption: Traditional buffer overflows or heap issues within language runtimes or parsers.
- Documentation Errors: Insecure coding patterns suggested in official project documentation that could lead users into vulnerability traps.
What Remains Active?
It is important to note that the program has not been shuttered entirely. Two primary areas remain open for researchers:
- Supply Chain Security: Reports concerning how software is built, packaged, and distributed remain active. This includes issues such as exposed package manager credentials or compromised build artifacts. These remain vital to Google’s security posture and continue to carry substantial rewards, scaling up to $31,337 for flagship projects.
- Cloud VRP Exceptions: Some repositories under the Google Cloud umbrella may still be eligible for compensation, provided the report is funneled through the dedicated Google Cloud VRP. This reflects the high-stakes nature of cloud infrastructure, where the impact of a breach is significantly higher than in general open-source libraries.
Supporting Data: The Economics of Security
The economics of the OSS VRP have always been tied to the severity and impact of the bug. Prior to the recent changes, the reward ranges were structured to incentivize high-quality, high-impact findings.
The current state of play suggests that Google is pivoting away from "bounty hunting" as a general crowdsourced effort and toward a more curated, expert-driven model. The Patch Rewards Program is now the recommended alternative for researchers. This program pays between $100 and $15,000, but with a critical caveat: the patch must demonstrate long-term stability by remaining in the project codebase for at least one month without being reverted. This requirement effectively eliminates low-effort, "drive-by" bug reporting.
Furthermore, the discrepancy between the outdated OSS VRP website (which still lists rewards up to $7,500 for product vulnerabilities) and the updated rules page highlights a disorganized transition. This confusion serves as a deterrent to legitimate researchers who may fear that their time will be wasted on reports that are no longer eligible for compensation.
The Broader Implications for the Open Source Ecosystem
The decision by Google to limit its program mirrors a broader industry trend. As noted by the recent closure of the cURL bug bounty program, maintainers are reaching a breaking point. When the cost of managing the intake—triaging, filtering, and communicating with researchers—exceeds the value of the vulnerabilities discovered, the bounty program becomes a net negative for security.
The "AI Slop" Crisis
The central issue is the democratization of vulnerability scanning. While AI tools have made it easier for ethical hackers to find bugs, they have also made it effortless for malicious or low-skill actors to flood trackers with false positives. This "signal-to-noise" ratio collapse is a systemic threat to all open-source projects, not just those under Google’s umbrella.
Impact on Project Security
By removing the financial incentive for casual researchers to look at product-facing code, Google risks a temporary drop in external security audits. While the company maintains that its internal security teams and automated fuzzing efforts are sufficient, the "many eyes" theory of open-source security relies on a diverse, incentivized, and global community. If these individuals migrate to other platforms or simply stop looking, certain classes of bugs may persist longer than they otherwise would.
A Shift in Corporate Responsibility?
There is also a philosophical question at play: to what extent should a major corporation bear the burden of paying for the security of its open-source dependencies? While Google relies on these projects for its own products, the open-source community has long argued that corporations reaping billions from free software should invest more in its maintenance. By scaling back the OSS VRP, Google is arguably signaling that they prefer to focus their resources on the supply chain—the infrastructure they control—rather than the upstream code they simply consume.
Conclusion: The Road to 2027
As we look toward the first quarter of 2027, the future of the OSS VRP rests on how effectively Google can refine its reporting requirements to filter out AI-generated noise. The goal is likely to implement a verification system that requires more "skin in the game" from researchers before a report is even considered.
For now, the security researchers who have built their careers on reporting bugs in projects like Go and Flutter must adjust their focus. The era of easy rewards for low-level product vulnerabilities is effectively over. In its place, we are seeing the rise of a more stringent, high-barrier environment where only the most sophisticated, well-documented, and impactful findings will be deemed worthy of the effort—and the reward.
This development serves as a stark reminder to the software development community: as AI changes how code is written, it is fundamentally changing how that code is defended. Whether this leads to a more secure ecosystem or a more fragmented one remains the defining question of the next year in cybersecurity.
