Google has paused new product vulnerability submissions to its Open Source Software Vulnerability Reward Program (OSS VRP), a decision that took effect on October 1. The company says the move follows a significant rise in automated submissions, the vast majority of which were not valid. Supply chain reports and existing cases remain open while Google reworks that part of the program and plans to provide an update in the first quarter of 2027.

The OSS VRP was launched in 2022 to reward researchers who privately report flaws in Google’s open-source software, including projects such as Go, Angular, and Protocol Buffers. The program was designed to encourage responsible disclosure and to help maintainers fix real security issues before attackers can exploit them. Instead, Google’s pause reflects a growing problem across the vulnerability disclosure ecosystem: AI-assisted tools can generate reports faster than humans can verify them.

What changed on October 1

As of October 1, Google is no longer accepting new product vulnerability submissions through OSS VRP. The pause does not shut down every part of the program. Supply chain reports are still accepted, and product reports submitted before the cutoff are still being processed. Some vulnerabilities in Google Cloud repositories may qualify through the Cloud VRP, and the Patch Rewards Program remains available for security improvements.

Google’s rules for the program make clear that the pause is targeted at one specific intake area rather than a blanket shutdown of all open-source security rewards. Researchers who believe they have a legitimate finding should check the scope of Google’s remaining programs before submitting. That step is more important than ever because misdirected reports can waste time for both the reporter and the maintainers.

Key facts at a glance

Why Google paused the program

Google says the pause followed a “significant rise in automated submissions,” adding that the vast majority were invalid. That language is careful but pointed. Automated tools—especially those powered by large language models—can scan code, infer possible weaknesses, and draft a vulnerability report in seconds. The problem is that a plausible-sounding report is not the same as a real, exploitable vulnerability.

Reports indicate that Google engineers and open-source maintainers had been overwhelmed by thousands of poorly written submissions that claimed to identify bugs but turned out to be invalid or unexploitable. Some reports contained hallucinated findings, meaning the tools invented code paths, misread context, or described vulnerabilities that did not exist. Reviewers then had to spend time validating code instead of working on legitimate vulnerabilities.

AI bug hunting is turning triage into the bottleneck

The OSS VRP pause is not an isolated event. Complaints about low-quality, AI-assisted vulnerability reports have been building across open-source projects and bug bounty programs for months. The pattern is consistent: automated tools can produce reports quickly, but maintainers still have to check whether each finding is real and exploitable. That validation work is human, time-consuming, and difficult to automate safely.

For companies running their own disclosure or bounty programs, Google’s pause shows how quickly AI-generated reports can create extra work for security teams. Reviewers must separate real vulnerabilities from false positives before engineers can act. If the ratio of noise to signal becomes too high, the program’s economic model breaks down. Researchers spend time on reports that do not pay out, maintainers spend time on reports that do not lead to fixes, and real vulnerabilities can get lost in the queue.

Linux maintainers have also said they were “completely overwhelmed” by vulnerability reports as AI-powered bug hunting increased submission volume. The issue is not that AI tools are useless. The issue is that their output is often treated as a finished finding when it is closer to a rough hypothesis. A hypothesis still needs testing, reproduction, and context. Without that work, it is not a vulnerability report; it is a lead that may or may not be worth pursuing.

The cost of false positives

Bug bounty programs are supposed to uncover vulnerabilities, not bury maintainers in bad reports. Every invalid submission has a cost. It consumes reviewer attention, delays legitimate disclosures, and can contribute to maintainer burnout. In open-source projects, many maintainers are volunteers or small teams with limited time. They cannot absorb an endless stream of AI-generated reports without dropping other work.

There is also a security risk in volume alone. When a program receives a flood of reports, its triage process becomes a bottleneck. Attackers do not need to submit reports to benefit from that bottleneck. They can simply wait while defenders are distracted. A vulnerability that would have been fixed quickly in a low-volume environment may sit longer because the queue is clogged with false positives.

Google’s decision suggests that the company would rather pause one intake channel than let the program’s quality collapse. That is a notable choice. Bug bounty programs depend on trust: researchers trust that valid reports will be rewarded, and maintainers trust that reports are worth their time. When that trust erodes, participation can fall. Pausing submissions to rethink the process may be preferable to letting the program become a source of noise.

What remains open for researchers

Researchers still have several paths for reporting security issues to Google. Supply chain reports remain open under OSS VRP. Outstanding product reports submitted before October 1 are still being processed. Some Google Cloud-related vulnerabilities may qualify through the Cloud VRP. The Patch Rewards Program also remains available for security improvements, which is a different kind of incentive: it rewards work that hardens code rather than only finding specific bugs.

Google has not said what changes it will make to the paused part of the program. The company plans to provide an update in Q1 2027. Until then, researchers should be precise about scope. A report sent to the wrong program may be closed without review, and a low-quality report may damage the reporter’s reputation. In bug bounty communities, reputation matters. Maintainers remember who sends reproducible, well-researched findings and who sends automated noise.

What this means for enterprise security teams

For enterprise security teams evaluating AI bug-hunting tools, the broader lesson is to measure reproducible findings and the effort required to validate them, not report volume alone. A tool that generates 1,000 findings but produces 990 false positives is not necessarily more effective than a tool that generates 10 findings with 8 real issues. The metric that matters is validated, actionable vulnerabilities per unit of reviewer time.

Security leaders should also consider how their disclosure or bounty programs will handle AI-generated submissions. Clear submission guidelines, reproduction requirements, and automated triage filters can help. But filters alone may not be enough. Programs may need to require proof-of-concept evidence, affected version details, and a clear explanation of exploitability. They may also need to rate-limit submissions from accounts that repeatedly send invalid reports.

AI can still be useful in vulnerability research. It can help with code review, fuzzing harness generation, variant analysis, and prioritizing areas for human investigation. The key is to keep humans in the loop for validation and to treat AI output as an aid, not an oracle. Google’s pause is a reminder that speed in report generation does not automatically translate into speed in vulnerability remediation.

The future of bug bounties in the AI era

Bug bounty programs have always faced false positives. What is new is the scale. AI tools can produce reports at a volume that no human review team can match without significant investment. That changes the economics of disclosure. Programs may need to adopt stricter intake requirements, use AI-assisted triage carefully, or shift toward alternative models such as patch rewards, direct maintainer funding, and coordinated hardening efforts.

Google’s OSS VRP pause may be temporary, but it signals a broader recalibration. Open-source software is critical infrastructure, and its security depends on sustainable maintainer workflows. If AI-generated reports make those workflows unsustainable, the entire disclosure ecosystem suffers. The answer is not to ban AI from security research. The answer is to build processes that reward signal over volume and that respect the limited time of the people who maintain the code.

For now, Google’s message is clear: new product vulnerability submissions to OSS VRP are paused, supply chain reports remain open, and outstanding cases are still being processed. The company plans to update the program in Q1 2027. Researchers and security teams should watch that update closely, because it may set expectations for how bug bounty programs handle AI-assisted submissions in the years ahead.

Source: eWeek News