Vulnerabilities

Google pauses OSS bug bounty after AI report flood

By Yaali. October 7, 2026, 6 min read, Vulnerabilities, Threat intel.

Google stopped taking product bug reports for its open source bounty on October 1. What is still in scope, and how maintainers and users should adapt.

Since October 1, 2026, Google's Open Source Software Vulnerability Reward Program (OSS VRP) no longer accepts new product vulnerability reports. That is the category for bugs in the code of Google's open source projects, such as Go, Angular and Protocol Buffers. Google gave a one-line reason: "a significant rise in automated submissions, the vast majority of which are not valid." Reports filed before October 1 are still processed, and Google says it will give an update in the first quarter of 2027.

This matters to three groups. Researchers lose a paid channel for code bugs in some of the most widely used open source projects. Maintainers everywhere get confirmation that AI-generated reports are now a triage cost large enough to close a program run by one of the best-staffed security teams in the industry. And teams that build on Go, Angular or Protobuf need to know that fixes still arrive, through the same advisory feeds as before.

What Google paused and what it kept

The OSS VRP launched in 2022 and pays for two kinds of finding. Product vulnerabilities are design or implementation flaws that significantly affect the confidentiality or integrity of user data: memory corruption, sanitizer crashes, path traversal, insecure defaults. Supply chain compromises are about who can change the software that gets shipped, for example a way to push code into a repository or tamper with a release artifact. Only the first category is paused.

Supply chain reports still pay. For flagship projects, Google's published range for a supply chain compromise has been $3,133.70 to $31,337 since launch. Product bugs in repositories that affect Google Cloud products can still go to the Cloud VRP, and the Patch Rewards Program still pays for proactive hardening work, such as fuzzing integrations in OSS-Fuzz, in Google's open source code.

Google also has not stopped fixing bugs. Projects keep their own disclosure channels. Go's security policy, for example, still takes private reports and sorts them into PUBLIC, PRIVATE and URGENT tracks by impact. What has gone, for now, is the reward for product bugs, which removes the financial reason to mass-submit them.

Why the reports broke the program

Producing a plausible-looking vulnerability report now costs almost nothing. A model can read a codebase, flag a suspicious pattern and write a confident report with a severity rating and a made-up proof of concept. Checking that report still needs an engineer who knows the code, and most of the submissions Google received failed that check: speculative, duplicated or hallucinated findings.

Google is not the first to stop. HackerOne paused the Internet Bug Bounty (IBB), which funds bounties for core open source projects, from March 27, 2026, saying the balance between findings and maintainers' capacity to fix them had shifted. The curl project ended its HackerOne bounty earlier in 2026 after years of AI-written reports, and Intel stopped offering bounties on its Intigriti program. In May, Google itself reworked its Chrome and Android reward tables.

Go's policy now addresses this directly. Curated LLM-assisted submissions with a high share of real findings get credit; bulk, uncurated batches do not.

What to do if you report vulnerabilities

Before you file anything with a Google open source project, check where it belongs:

Supply chain issue (repository write access, build or release tampering, a compromised published artifact): file it with the OSS VRP as before.
Code bug in a repository that affects a Google Cloud product: file it with the Cloud VRP.
Any other code bug: report it through the project's own security policy (its SECURITY.md, or Google's form at https://g.co/vulnz). Expect a fix and credit, with no reward, until Google's 2027 update.

Whatever the channel, send what Google's rules already ask for: a proof of concept that builds and runs, the affected versions, the impact and a realistic attack scenario. If an AI tool found the bug, reproduce it yourself before you send it and say which tool you used. A suggested patch speeds things up.

What to do if you maintain a project

The same flood reaches small projects, with nobody paid to triage it. A few settings cut the cost:

Publish a SECURITY.md that lists the minimum a report must contain (version, reproduction steps, observed versus expected behaviour) and says that reports without a working reproduction are closed unanswered.
Turn on GitHub private vulnerability reporting under the repository's security settings, so reports arrive as private draft advisories in one place where only maintainers can see them.
Triage in a fixed order: does it reproduce on the latest release, is the code path reachable from untrusted input, and is it a duplicate of a known advisory. Stop at the first "no".
Keep a short public note on how you handle AI-assisted reports. Go's wording is a good template.

If you build on Go, Angular or Protobuf

Fixes for these projects are still published through the usual channels. Keep consuming advisories as you do now, and check that your dependencies match what was published:

Go: run govulncheck ./... in each module. It checks the Go vulnerability database and reports only vulnerabilities in functions your code actually calls. Run go mod verify to confirm downloaded modules still match the hashes in go.sum.
Angular and npm packages: run npm audit for known advisories and npm audit signatures to check registry signatures and provenance attestations on installed packages.
Any stack: osv-scanner reads lockfiles for Go, npm, Python, Maven and others and checks them against the OSV.dev database, which also aggregates the GitHub Advisory Database.

Supply chain compromise stayed in scope because it is the higher-impact failure: one tampered release reaches everyone at once. If go mod verify reports a mismatch, or npm audit signatures shows a package with an invalid signature, treat it as a possible compromise. Pin the last known-good version, rebuild from a clean cache, and check CI logs for when the changed artifact first appeared.

The wider lesson

Bug bounties assumed that sending a report cost the reporter real effort, so most reports were worth reading. AI removed that cost on the reporting side and left it on the triage side. Expect more programs to require working reproductions, cap submissions or score reports automatically before a human looks, and expect the payout to move towards findings that are hard to fake, such as supply chain access.

If you want a human-verified view of your own exposure, our red team and code review work reproduces every finding before it reaches your engineers, and our attack surface management service tracks which third-party components you run. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: SecurityWeek, The Hacker News, Help Net Security, Malwarebytes, The Cyber Express, Google VRP on X, Google OSS VRP rules, Google Security Blog, OSS VRP launch, Go security policy, Dark Reading on the IBB pause.