Google has temporarily stopped accepting a major category of open-source vulnerability reports.
On October 1, 2026, Google Bug Hunters announced that it is no longer accepting product vulnerability submissions through the Google Open Source Software Vulnerability Reward Program, or OSS VRP. The pause does not affect OSS VRP supply-chain reports or outstanding reports already submitted. Google encouraged researchers to submit impact through its other VRP programs or pursue the Patch Rewards Program instead. It also said it would continue to rework this part of the OSS VRP and provide an update in the first quarter of 2027.
The reason was blunt.
There had been a significant rise in automated submissions, and the vast majority were not valid.
This is not merely a small administrative change inside one bug bounty program.
It is a sign of a larger shift in security research. AI has lowered the cost of finding, drafting and submitting vulnerability reports. But it has not lowered the cost of verifying whether those reports are real, exploitable and meaningful. That imbalance is beginning to reshape the economics of vulnerability disclosure.
The old assumption behind bug bounty programs was simple.
More eyes make software safer.
If many researchers inspect code, test products and report vulnerabilities, organizations can find and fix flaws faster. Open-source software seemed especially suited to this model because the code is visible and widely used. Google’s OSS VRP was created to reward researchers who helped secure open-source software released by Google. The program covers public repositories in Google-owned GitHub organizations and selected repositories on other platforms, including repository configuration settings such as GitHub Actions, access controls and GitHub application configurations.
But AI changes the premise.
The problem is no longer only whether enough people are looking.
The problem is whether enough valid findings can be separated from a flood of automated noise.
Google’s own March 2026 OSS VRP update had already warned that the security landscape was shifting rapidly. The company said it had seen a massive surge in AI-generated reports and increasingly encountered reports containing incorrect information or hallucinated explanations of how a vulnerability could be triggered. It also described floods of reports that might point to coding errors but have negligible security impact because of the project’s security model or because the code path is not realistically reachable.
This is the core of the issue.
AI can generate plausible vulnerability reports at scale.
But plausible is not the same as valid.
A report can name a real-looking bug class.
It can include technical vocabulary.
It can describe a theoretical attack path.
It can even look persuasive to a non-expert.
But unless the report demonstrates exploitability, reachability and security impact, it creates work rather than reducing risk.
That is what bug bounty triage teams are now facing.
A human reviewer must still read the report, reproduce the issue, assess the affected version, examine the attack scenario, determine whether the code path is reachable, judge the security impact and decide whether a reward is appropriate. AI may collapse the cost of producing reports, but the cost of triaging them remains highly human.
When submission volume rises but validity does not, the program’s signal-to-noise ratio collapses.
That is why Google’s pause matters.
Google did not say it was ending its open-source security effort. In fact, supply-chain compromise reports remain central to the OSS VRP. The current rules state that Google “first and foremost” welcomes submissions pointing out vulnerabilities affecting source or build integrity that could result in supply-chain compromise. Examples include the ability to modify code on main branches, compromise build or release infrastructure, disclose package manager credentials or compromise signing keys.
In other words, Google is narrowing the gate, not abandoning the castle.
The company is prioritizing the kinds of reports that can lead to the most severe systemic damage: compromises of source code, build artifacts, release infrastructure and packages distributed to users.
Product vulnerability reports are different.
They involve design or implementation issues in Google open-source projects that can affect confidentiality or integrity in software built using Google OSS. Examples listed in the rules include memory corruption issues, sanitizer failures, path traversal and insecure defaults or code examples in documentation.
These issues can be real and important.
But they are also easier to mass-produce as low-quality claims.
A model can scan code and point to a buffer overflow pattern.
It can speculate about path traversal.
It can generate a report about an insecure example.
But without a buildable proof of concept, reachable code path and clear impact, the report may be little more than automated suspicion.
That is why Google had already tightened acceptance criteria before this pause. For OT0 and OT1 projects, memory corruption vulnerabilities required exact OSS-Fuzz reproduction steps using an existing fuzz target or an already merged patch. For lower-tier OT2 and OT3 projects, product vulnerabilities were no longer eligible for monetary reward.
The October pause goes further.
As of October 1, 2026, Google is no longer accepting product vulnerabilities submitted to the OSS VRP. Existing product vulnerabilities submitted before that date are not affected. For some Google Cloud repositories affecting Google Cloud products, researchers may still submit through the Cloud VRP. For Google open-source projects closely tied to Google Cloud or AI products, Google encourages researchers to use the Google Cloud VRP or AI VRP so reports can be routed to the right engineers.
This distinction is important.
Google is not saying all product vulnerabilities are unimportant.
It is saying that this specific intake channel has become unsustainable in its current form.
The program must be redesigned.
The deeper issue is that AI-assisted bug hunting changes the economics of disclosure.
Before generative AI, writing a plausible vulnerability report required some level of manual effort. Researchers had to inspect code, build the project, run tests, develop proof of concept, understand impact and write a coherent report. That effort acted as a natural filter.
Now that filter is weaker.
AI can draft reports quickly.
Automated tooling can generate large numbers of candidate findings.
A researcher, or even a spammer, can submit more reports with less effort.
The marginal cost of report generation falls.
But the marginal cost of serious triage does not fall at the same rate.
That gap creates pressure on maintainers.
Open-source projects already face a maintenance burden. Maintainers review pull requests, fix bugs, respond to issues, handle releases, manage dependencies and respond to security reports. If the vulnerability queue fills with invalid or hallucinated reports, the burden shifts from fixing security issues to disproving weak claims.
This is dangerous because it can harm the very researchers bug bounty programs are supposed to encourage.
When triage teams are overwhelmed, valid reports may take longer to process. High-quality researchers may receive slower responses. Maintainers may become more skeptical by default. Programs may narrow scope, require stronger proof, or gate participation through reputation systems.
The result is paradoxical.
AI was supposed to help find more bugs.
But if it produces too much low-quality noise, it may reduce access to bug bounty programs for everyone.
The Google OSS VRP pause is therefore not just about Google.
It is a warning to the broader security ecosystem.
Bug bounty programs depend on trust and triage capacity. Researchers trust that valid reports will be evaluated fairly and rewarded. Companies trust that researchers will submit actionable, ethical and well-supported findings. When AI-generated reports flood the system with unverified claims, that mutual trust weakens.
The line between “AI-assisted security research” and “AI-generated spam” becomes critical.
There is nothing inherently wrong with using AI in vulnerability research. AI can help read code, summarize documentation, generate test cases, reason about edge cases and assist with reproduction. Used carefully, it can make researchers more effective.
But AI output must be validated.
A real report should show where the issue is, how to reproduce it, which version is affected, what the impact is and how an attacker could exploit it. Google’s reporting rules still emphasize high-quality reports with as much detail as possible, including buildable proof of concept, reproduction instructions, affected software version, impact description and attack scenario.
That is the standard AI-generated reports often fail to meet.
They may sound technical but lack proof.
They may describe an impact but not demonstrate it.
They may identify a bug class but not show reachability.
They may confuse theoretical weakness with exploitable vulnerability.
They may be generated at a scale that makes the entire queue harder to manage.
This creates a new security problem: not vulnerability discovery, but vulnerability-report quality.
In the past, security programs worried about underreporting.
Now they must also worry about overreporting of invalid findings.
The solution will likely involve more structure.
Bug bounty programs may require stronger proof before accepting certain report categories. They may demand reproducible test cases, exact fuzzing steps, merged patches, exploit demonstrations or clearer impact thresholds. They may rely more on reputation, researcher history, rate limits or pre-screening. They may separate speculative findings from verified vulnerabilities. They may route reports to more specialized programs, such as Cloud VRP or AI VRP, depending on the affected product area.
Google’s own rules already point in this direction.
The OSS VRP now places strong emphasis on supply-chain compromise, project tiers, reproducibility, security impact and report quality. Rewards vary by tier and category, while final amounts remain at the discretion of the reward panel. Supply-chain compromise reports remain eligible across major tiers, while product vulnerabilities now have no listed reward category under the current table.
The Patch Rewards Program also becomes more important in this context.
Instead of only reporting a possible product flaw, researchers can contribute security improvements directly to Google’s open-source projects. Google explicitly encourages researchers to look at Patch Rewards for security improvements to OSS projects.
This may signal a shift from “tell us what might be wrong” to “show us a verified fix or robust security improvement.”
That shift makes sense in an AI-saturated reporting environment.
When anyone can generate a report, proof becomes more valuable.
When claims are cheap, patches become more credible.
When speculation is abundant, reproducibility becomes the currency of trust.
For open-source maintainers, this is a painful but necessary adjustment. Automated tools can help identify real weaknesses, but they can also create a denial-of-service effect against human attention. A flood of invalid reports does not merely waste time. It can delay real fixes, exhaust maintainers and discourage careful review.
In security, attention is a scarce resource.
AI can create more findings than humans can validate.
So the future of bug bounty programs may depend less on who can generate the most reports and more on who can prove real impact.
That is the lesson of Google’s OSS VRP pause.
The era of low-effort vulnerability reports is ending.
The era of evidence-heavy vulnerability research is beginning.
For researchers, the message is clear.
Do not submit what AI merely suggests.
Submit what you have verified.
Do not describe only a possible bug.
Show a reachable exploit path.
Do not rely on technical language.
Provide reproduction steps, impact and evidence.
For platforms, the message is also clear.
If AI changes the cost structure of submissions, intake systems must change too. Programs need better filters, clearer scope, stronger proof requirements and more efficient routing. Otherwise, bug bounty queues can become overwhelmed by machine-generated uncertainty.
Google says it will update researchers in the first quarter of 2027.
What comes next may become a model for other vulnerability reward programs.
Will there be stricter proof requirements?
Reputation-based submission gates?
Separate queues for AI-assisted reports?
More emphasis on patches and fuzzing integrations?
Narrower product scope?
The details are not yet clear.
But the direction is.
AI has made it easier to produce vulnerability reports.
Now security programs must make it harder to submit unverified ones.
That is not a retreat from open-source security.
It is an attempt to preserve it.
Because when the volume of automated claims overwhelms the people who must verify them, even real vulnerabilities can get buried.
The future of bug bounty will not be decided by how many reports AI can generate.
It will be decided by how much verified security impact humans and machines can prove together.
