Summary

• Google stopped accepting new OSS VRP product vulnerability submissions from 1 October after a sharp rise in automated reports.
• Supply chain reports, outstanding cases and some vulnerabilities affecting Google Cloud products remain open through other channels.
• Google plans to redesign this part of the programme and provide an update in the first quarter of 2027.

Google has temporarily stopped accepting new product vulnerability reports through its open source bug bounty programme after automation made submitting security findings considerably easier without making most of those findings valid.

Google Bug Hunters halted new product vulnerability submissions to the Open Source Software Vulnerability Rewards Program from 1 October, citing a substantial increase in automated reports whose overwhelming majority failed validation.

The pause does not close every route into the programme. Existing submissions continue to be processed and supply chain vulnerability reports remain open, while some problems affecting Google Cloud products can still be submitted through the separate Cloud vulnerability rewards programme. Researchers can also submit security improvements through Google’s Patch Rewards Program.

Google plans to rework the affected part of OSS VRP and provide an update in the first quarter of 2027, exposing a less celebrated consequence of AI security tooling: discovery can be automated faster than experienced maintainers can verify the output.

The cost of a report continues after submission

Bug bounty programmes rely on external researchers finding security weaknesses and disclosing them privately before attackers exploit them. Rewards create an incentive to investigate software that an organisation’s internal teams may not have time to examine continuously.

The model only works while the cost of processing reports remains manageable because every submission needs some degree of triage, and plausible vulnerabilities can require engineers to reproduce the behaviour, identify affected versions and establish whether the claimed impact is real.

AI changes that balance by allowing a researcher to generate more hypotheses, scan code more quickly and automate report preparation. Those capabilities can reveal genuine flaws, but they can also produce speculative findings whose technical explanations look convincing without surviving closer testing.

Google says the vast majority of the increased automated submissions were invalid. Automation therefore shifted work rather than eliminating it: the submitter spent less time generating a report while maintainers spent time demonstrating why it did not represent a vulnerability.

The asymmetry becomes particularly damaging in open source projects because the people receiving reports may also be responsible for maintaining the software itself. Hours spent reviewing duplicated or hallucinated vulnerabilities are hours not spent fixing genuine defects or developing the project.

AI makes proof of impact more valuable

Security programmes have long distinguished between a theoretical weakness and a vulnerability capable of producing a meaningful outcome, but automated reporting increases the value of that distinction.

A language model can explain why a piece of code appears unsafe or identify a pattern associated with earlier vulnerabilities. Establishing exploitability often requires more context: how the software is configured, whether an attacker can control the relevant input, whether another security boundary prevents the attack and whether the behaviour occurs in a supported version.

Concrete reproduction steps and working proofs consequently become more valuable as the volume of machine generated hypotheses rises. A report demonstrating a real security boundary being crossed saves maintainers from having to reconstruct the researcher’s claim from first principles.

Google has already adjusted other reward programmes as AI changes vulnerability research, while maintainers elsewhere in the open source ecosystem have faced similar pressure from low quality reports.

None of this means AI cannot contribute useful security research. Automated tools have long been central to vulnerability discovery, from fuzzing to static analysis, and machine learning can extend that capability. The problem arises when cheap generation of possible findings is mistaken for cheap verification.

Open source carries the externality

The person submitting a poor report and the person absorbing its cost are often different, creating an uncomfortable incentive when another automated submission costs the researcher little but every report still consumes maintainer attention.

If a valid finding can earn a bounty, submitting a large volume of low probability reports may remain worthwhile for the researcher even when most fail. The project carries the cost of reviewing the unsuccessful majority.

Programme design may therefore have to impose stronger evidence requirements. Automated findings could be expected to include reproducible tests, clear impact demonstrations or other material that places more validation work back on the researcher before submission.

Reputation systems and submission limits provide other options, although each risks excluding inexperienced researchers who discover genuine vulnerabilities. Open programmes have historically benefited from allowing unknown participants to demonstrate skill through the quality of a finding rather than requiring established credentials first.

Google’s temporary pause gives it time to redesign that balance without closing supply chain reporting, where vulnerabilities can affect large numbers of downstream users and remain particularly valuable.

Security automation is creating a verification economy

The same pattern is appearing beyond bug bounties. Developers can produce more code with AI, analysts can generate more threat hypotheses and security tools can surface more possible weaknesses, while experienced human attention remains finite.

That moves the bottleneck towards evidence. Systems capable of discovering problems become more useful when they can also demonstrate which findings are real, prioritise them accurately and provide enough context for an engineer to act without repeating the investigation.

The effect may eventually improve security tooling by forcing suppliers to optimise for validated outcomes rather than raw finding counts. A scanner producing ten well evidenced vulnerabilities can impose less work and create more value than one generating 1,000 plausible warnings.

Google’s pause makes the imbalance unusually visible because a programme designed to reward more people for finding bugs has temporarily had to discourage an entire category of submission.

AI is making vulnerability discovery cheaper. Until verification becomes cheaper at the same rate, the difference still has to be paid in engineering time.