The short answer
Google has frozen its open source bug bounty because AI-generated vulnerability reports made the program too expensive to run, not because the code got safer. Since October 1, 2026 the OSS VRP no longer takes new product vulnerability reports for Google-maintained projects such as Go, Angular, Bazel and Protocol Buffers. Google says an update will follow in Q1 2027.
For teams that build on those libraries, one external safety net just got thinner. For teams that run their own disclosure inbox, it is a warning: the same flood will reach you. Now is a good time to check that your security testing and audit process does not depend on outsiders finding the bugs first.
What did Google announce?
Google’s vulnerability rewards team announced that the OSS VRP has stopped accepting new submissions. In its statement, Google said the pause “is due to a significant rise in automated submissions, the vast majority of which are not valid.” TechCrunch, which first reported the change on October 4, described Google engineers and open source maintainers as overwhelmed by invalid reports, some containing hallucinated details.
The program has paid outside researchers for flaws in Google-maintained open source code since 2022: the Go language and toolchain, Angular, Bazel, Protocol Buffers, Fuchsia and related repository and supply-chain settings. Google is not closing every door. Security fixes can still earn up to $15,000 through the Patch Rewards Program, flaws in Google Cloud open source repositories that affect Cloud products can still go to the Cloud VRP, and reports submitted before October 1 will be handled as before.
Why are bug bounties breaking under AI reports?
LLMs and automated bug-hunting scripts have pushed the cost of writing a plausible vulnerability report close to zero, while the cost of checking one has not moved. Each report still needs an engineer who knows the code to read it, try to reproduce it and explain why it is or is not a bug. When most reports are wrong, that work is spent on noise and real findings wait longer.
Google is not the first to give up on paying for volume. The curl project ended its HackerOne bounty in January 2026 after a wave of AI-generated reports, and BleepingComputer reports that Intel removed financial rewards from its Intigriti program in September. The pattern is consistent: programs that pay per valid finding but accept unlimited submissions are the first to break.
What it means for US & EU software teams
First, your dependencies lost one source of outside scrutiny. Many backend services are written in Go, many front ends use Angular, and Protocol Buffers sits inside most gRPC stacks. Google still patches these projects, but fewer paid outside researchers will be looking at them for months. Treat security advisories for these libraries as something you monitor and act on, not something you assume someone else has already found.
Second, your own disclosure inbox is next. If you run a vulnerability disclosure program or a public security@ address, the same tools that buried Google can bury a three-person security team much faster. A queue full of confident but wrong reports is not only wasted time; it is how a real, exploitable report gets missed.
Third, in the EU, an ignored report can become a compliance problem. The Cyber Resilience Act expects makers of software products to have a coordinated vulnerability disclosure policy and to handle incoming reports, and its reporting duties for actively exploited flaws already apply. “We were flooded with AI spam” will not explain a missed one. Triage capacity now belongs in the same planning as patching capacity.
What should you do now?
- Map your exposure. List services that ship Go modules, Angular, Bazel-built artifacts or Protocol Buffers, with exact versions, using your SBOM or dependency manifests.
- Watch advisories, not bounties. Subscribe to the Go vulnerability database, GitHub security advisories and OSV feeds for those dependencies, and wire them into the alerting your on-call team already reads.
- Raise the bar for incoming reports. Require a named affected version, reproduction steps and a proof of concept. A structured form filters far more noise than a free-text email address.
- Pre-screen automatically. Run a first pass that checks whether the referenced files, functions and versions exist before an engineer spends time on the report. Hallucinated code paths are the most common tell.
- Protect the signal. Keep a fast lane for known researchers and customers, publish scope and contact details in security.txt, and track the share of valid reports so you notice when the queue starts to drown.
Frequently asked questions
What did Google pause?
Google paused new submissions to its Open Source Software Vulnerability Rewards Program (OSS VRP), the bug bounty for Google-maintained open source projects such as Go, Angular, Bazel, Protocol Buffers and Fuchsia. The pause took effect on October 1, 2026. Google said it was due to a significant rise in automated submissions, the vast majority of which were not valid.
How long will the OSS VRP pause last?
Google has not set an end date. It says it is reworking the program and will share an update in the first quarter of 2027. Reports submitted before October 1, 2026 are not affected by the pause, according to BleepingComputer and Help Net Security.
Can researchers still report bugs in Google open source projects?
Yes, through other channels. The Patch Rewards Program still pays up to $15,000 for high-impact security fixes, and flaws in Google Cloud open source repositories that affect Cloud products can go to the Cloud VRP. Vulnerabilities can still be disclosed to project maintainers; what is paused is the paid reward track for product flaws.
Does this make Go, Angular or Protocol Buffers less secure?
Not directly. Google still maintains and patches these projects, and its own security teams keep working on them. The practical change is one fewer paid incentive for outside researchers, so teams that ship these libraries should rely on their own dependency scanning and advisory monitoring rather than assume bounty hunters will find problems first.
How should we protect our own vulnerability disclosure program from AI slop?
Ask for a reproducible proof of concept against a named version, use a structured submission form, publish a clear scope in security.txt and your policy, and pre-screen reports automatically for missing reproduction steps or hallucinated code paths before a human engineer reads them. Keep a fast lane for reporters with a track record, and measure how many reports turn out to be valid.
Sources
Google Bug Hunters — Open Source Software Vulnerability Reward Program rules
TechCrunch — Google froze its open source bug bounty program due to a ‘significant rise’ in AI submissions (Oct 4, 2026)
BleepingComputer — Google halts open-source bug bounty program amid AI spam surge
Help Net Security — AI slop submissions force Google to freeze its open-source bug bounty