Google has paused product vulnerability submissions to its Open Source Software Vulnerability Rewards Program after a significant rise in automated reports that the company says are overwhelmingly invalid. The Google open-source bug bounty pause took effect on October 1, 2026, and is expected to remain in place while the company changes the program.
What happened
Google’s OSS VRP pays researchers who find meaningful security flaws in Google-maintained open-source software and selected third-party dependencies. The covered ecosystem has included projects such as Go, Angular, Bazel, Protocol Buffers, and Fuchsia, along with some repository and supply-chain security issues.
Google says the volume of automated submissions increased sharply and that the vast majority were not valid. The company temporarily stopped accepting new product-vulnerability reports through this specific program and said it plans to provide an update in the first quarter of 2027.
What is confirmed
The pause applies to new OSS VRP product-vulnerability submissions. Google says it does not affect reports submitted before October 1, 2026, outstanding reports already under review, or OSS VRP supply-chain reports.
Other Google reporting routes also remain available. Researchers can continue to submit eligible security patches through Google’s Patch Rewards Program. Vulnerabilities in Google Cloud open-source repositories that affect Google Cloud products can still be reported through the Google Cloud Vulnerability Reward Program.
What this announcement does not mean
Google has not announced a breach, an actively exploited vulnerability, or a security failure in the open-source projects covered by the program. The change concerns intake and review of vulnerability reports.
The pause also does not mean that all AI-assisted security research is unreliable. Google’s stated problem is the volume of invalid automated submissions. A report still needs reproducible evidence, a clear security impact, and accurate technical analysis regardless of whether automation helped identify the issue.
Why this matters to small businesses
Many small businesses rely directly or indirectly on Google-maintained open-source components. Those dependencies may be built into websites, mobile applications, cloud services, developer tools, and software supplied by vendors.
Bug bounty programs provide one path for security researchers to alert maintainers before a flaw is widely abused. When a reporting channel is constrained, businesses should not assume that vulnerability discovery or remediation has stopped. They should instead rely on several sources of security information and maintain their own process for identifying affected software.
The announcement also highlights a broader operational issue for organizations accepting vulnerability reports. High-volume, low-quality automated findings can consume engineering time, delay review of credible reports, and create pressure to change disclosure processes.
Practical defensive actions
Track the components your business uses
Maintain an inventory of software, cloud services, and important open-source dependencies. Ask software providers whether they can supply a software bill of materials or another reliable list of embedded components. Without an inventory, it is difficult to determine whether a newly disclosed vulnerability applies to the business.
Monitor more than one advisory source
Follow security advisories from the project repository, the vendor, the GitHub Advisory Database, CISA, and the National Vulnerability Database as appropriate. Subscribe to release notifications for critical dependencies and do not depend on a single bug bounty program as the only warning channel.
Keep patching and dependency updates risk-based
Prioritize internet-facing systems, authentication software, remote-access services, and components with evidence of active exploitation. Test updates where practical, but define an emergency process that allows high-risk fixes to move faster than routine maintenance.
Validate automated findings before acting
Businesses using AI-assisted scanners should require reproducible steps, affected versions, realistic attack conditions, and a clear description of impact. Treat unverified scanner output as a lead for investigation, not proof of a vulnerability or compromise.
Strengthen vulnerability-report intake
Organizations that publish a security contact or disclosure policy should define the evidence required for a report. Structured forms, duplicate detection, rate limits, and a documented triage process can reduce noise while preserving a route for legitimate researchers.
What researchers should do during the pause
Researchers should review the current Google Bug Hunters rules before submitting a report. Reports concerning eligible supply-chain issues can still use the OSS VRP route, while qualifying Google Cloud issues and security patches may belong in other Google programs.
Researchers should avoid sending the same report through multiple channels unless program guidance specifically calls for it. A strong submission should include the affected project and version, prerequisites, step-by-step reproduction, evidence of security impact, and a safe proof of concept.
Sources
Google Open Source Software Vulnerability Reward Program rules