Google Pauses OSS VRP Product-Bug Rewards Over AI Slop

Introduction

Google has stopped accepting product-vulnerability reports through its Open Source Software Vulnerability Reward Program (OSS VRP). The program's rules page states: "As of October 1, 2026, we are no longer accepting product vulnerabilities submitted to the OSS VRP." According to TechCrunch, Google attributed the pause to "a significant rise in automated submissions, the vast majority of which are not valid." Tom's Hardware, which published on October 3, ties the move to a flood of invalid, AI-generated reports and notes that Google announced it in an X post on October 1.

Headlines have called this a frozen bug bounty program. The wording is broader than the rules page supports. Only one reward category is paused. Supply-chain compromise reports remain open with published reward ranges, and the table still lists payouts for "other security issues." This review sets out exactly what is paused, what is not, and what the change says about bug bounty economics in the era of cheap automated bug hunting.

Feature Overview

1. What is paused. The product-vulnerabilities section of the OSS VRP rules now opens with the October 1 notice. In the reward table, the "Product vulnerabilities" row shows "-" in all four project tiers (OT0 flagship through OT3 low-priority). Google says it will "continue to reformat and work on this aspect of the OSS VRP" and commits to an update in Q1 2027.

2. What continues. The same table still lists supply-chain compromise rewards of $3,133.7 to $31,337 for OT0 repositories, $1,337 to $13,337 for OT1, and $500 to $3,133.7 for OT2. "Other security issues" pay $1,000 for OT0 and $500 for OT1. Tom's Hardware confirms the suspension "does not affect OSS VRP supply chain reports."

3. Where product bugs can go instead. Google says some Google Cloud repositories that affect Google Cloud products may still be handled through the Cloud VRP. The rules page also advises that vulnerabilities in open source projects closely tied to Google Cloud or AI products be reported to the Cloud VRP or the AI VRP. Researchers are pointed to Google's other VRP programs and to the Patch Rewards Program, which pays for security improvements to Google's open source projects.

4. Transition rule. The change does not affect product vulnerabilities submitted before October 1, 2026, so reports already in the queue stay eligible.

5. Filters that already existed. The rules page also documents that the program required exact OSS-Fuzz reproduction steps or an already merged patch for memory corruption reports on OT0 and OT1 repositories. Supply-chain reports must demonstrate exploitability that bypasses the requirement that external contributors have their pull requests approved first. Both are proof-of-exploit requirements, yet the product-vulnerability category is the one Google chose to pause.

Usability Analysis

For independent researchers, the practical effect is a rerouting problem. A bug in a flagship Google open source library that is not tied to Google Cloud has no paid path through the OSS VRP right now. The remaining options are the Patch Rewards Program, which rewards a fix rather than a finding, and the Cloud VRP or AI VRP when the project is closely tied to those products. Researchers who work mostly on supply-chain integrity, such as GitHub Actions configuration, build environments, package credentials, or signing keys, see no change.

For Google's security staff and maintainers, the pause closes the category tied to the invalid and hallucinated reports Tom's Hardware describes. Tom's Hardware reports that engineers and maintainers were "reportedly overwhelmed by thousands of sloppy reports" that turned out to be invalid or hallucinated. That count is Tom's Hardware's characterization, and Google's rules page and the quote carried by TechCrunch give no figure. Neither source provides a share of reports that were valid beyond Google's phrase "the vast majority."

Pros and Cons

Pros: the scope is narrow and clearly written, with a dated effective date and a transition rule. Supply-chain rewards, which protect users who install Google's artifacts, remain open. Google names alternatives and a date for its next update.

Cons: researchers with genuine, manually verified product bugs lose a payout path, because a pause on volume also removes the incentive for careful reports. Researchers must wait for the Q1 2027 update to learn what the reformatted program looks like. Google has not published the volume of reports or the validity rate behind its decision.

Analysis: AI Slop and Bounty Economics

A bounty program works only if the cost of reviewing a claim stays below the value of the real findings it surfaces. Language models and automated scanners lower the cost of writing a plausible report to nearly zero, while the cost of verifying it stays with the maintainer. Tom's Hardware describes exactly this shift, saying that automated tools "nearly eliminated the cost and effort" that the task once required. TechCrunch notes that it reported in 2025 that security experts were warning AI slop posed a serious risk to bug bounty programs.

Why supply-chain rewards survive is something Google has not explained, so the following is our reading rather than a Google statement. Supply-chain reports are judged against a concrete, testable bar: the researcher must show the attack works despite the pull-request approval requirement. A report either demonstrates compromise of source or build artifacts or it does not, which may make invalid claims easier to reject quickly. Product-vulnerability reports cover a wider range of code defects, where a convincing but wrong write-up takes more engineering time to disprove.

Outlook

Google says it will reformat this aspect of the program. Possible directions include stricter reproduction requirements or different intake, but Google has announced none, and the Q1 2027 update is the next confirmed checkpoint. Elsewhere, Tom's Hardware reports that Intel suspended its bug bounty program that paid up to $100,000 per flaw, adding that Intel did not officially confirm AI-generated reports as the reason. Tom's Hardware also cites Linux kernel maintainers saying they were "completely overwhelmed" by CVE findings from AI-powered bug hunters. Together these suggest report-handling capacity, not only reward budgets, is becoming the constraint.

Conclusion

This is a scoped pause, not a shutdown. Product-vulnerability submissions to the OSS VRP ended on October 1, 2026, while supply-chain and other reward lines remain published. Security researchers, open source maintainers, and teams that run their own bounty programs should read the rules page directly, since the news headlines describe a wider freeze than Google's own text. The next real data point is Google's Q1 2027 update.

Editor's Verdict

Google Pauses OSS VRP Product-Bug Rewards Over AI Slop earns a solid recommendation within the IT news space.

The strongest case for paying attention: scope is narrow and dated, with a clear transition rule for reports filed before October 1. That alone raises the bar for what readers should expect in this space. Reinforcing that, supply-chain rewards of up to $31,337 for flagship repositories remain available — practical value rather than just headline appeal. The broader signal worth registering is straightforward: headlines saying the whole program is frozen overstate the change, because only the product-vulnerability category is paused on Google's own rules page. On the other side of the ledger, one constraint is real rather than a marketing footnote: researchers with genuine product-vulnerability findings lose a paid path in the OSS VRP until at least Google's Q1 2027 update. It should factor into any serious decision. Layered on top of that, report volumes and the validity rate are unpublished, so the decision cannot be independently assessed — which narrows the set of teams for whom this is an obvious yes.

For AI industry watchers, strategy teams, and decision-makers tracking platform shifts, this is a serious evaluation candidate, not just a curiosity to bookmark. For everyone else, the safer posture is to monitor coverage and revisit once the use cases that matter to your team are demonstrated in the wild.