Google has stopped accepting product vulnerability reports for its open source projects. On October 1, 2026, the Google VRP team posted a public service announcement on X: it is "temporarily no longer accepting OSS VRP product vulnerability submissions." The stated reason, reported by TechCrunch, is "a significant rise in automated submissions, the vast majority of which are not valid."
This is the clearest sign yet that AI-generated report spam has moved from a maintainer complaint to a reason for a top lab to shut a reward channel. If you maintain open source, hunt bugs for a living, or run any intake process that pays for findings, the mechanics behind this freeze apply to you. This post covers what exactly is paused, what still works, why the economics broke, and what to change in your own workflow. It builds on explainx.ai's earlier coverage of AI slop and the slopocalypse.
TL;DR: what is paused and what is not
| Question | Answer |
|---|---|
| What happened? | Google paused OSS VRP product vulnerability submissions on October 1, 2026. |
| Why? | A significant rise in automated submissions, most of them invalid, per Google. |
| Still accepted? | OSS VRP supply chain reports and any outstanding reports. |
| Other routes? | Google points researchers to its other VRPs; some Cloud repos may be taken via Cloud VRP. |
| When does it return? | No date. An update is expected in Q1 2027, per press reports. |
| Is this only Google? | No. Other projects have cut or changed bounties for the same reason (see below). |
| Is AI bug hunting dead? | No. Validated, human-reproduced findings are still valuable. |
What exactly did Google announce?
The primary source is the Google VRP post on X, which describes the change as a PSA for open source bug hunters. Three points are explicit in it and in the coverage by TechCrunch and Tom's Hardware:
- Scope. Only product vulnerability submissions are paused. That is the category where a researcher reports a bug in a Google open source project's code and asks for a reward.
- Not affected. Supply chain reports and outstanding reports continue. Supply chain reports concern tampering in build and release pipelines, which are harder to fake because they require showing real compromise in an environment.
- Alternative. Google encourages researchers to find impact across its other reward programs, and has said some Google Cloud repositories that affect Cloud products may still be accepted through the Cloud VRP.
The rules page for the program, hosted on Google Bug Hunters, lists reward amounts for the program in its normal state. We have not seen a changelog entry there beyond the announcement, so treat the X post and the press coverage as the current record.
Why did AI submissions break the model?
Bug bounties work because producing a good report is expensive. You have to read code, understand an attack surface, build a proof of concept and write it up clearly. That cost filters out most noise before it reaches a human triager.
Large language models remove that filter on the sending side. A script can scan a repository, ask a model to "find vulnerabilities," and paste the output into a submission form. The marginal cost of a report falls to nearly zero. The cost of reading it does not fall at all, because someone still has to check whether the claimed bug exists.
The result is an asymmetry that favors spammers: a thousand plausible-sounding reports cost a thousand reviewer sessions, even if 990 are hallucinated function names, impossible call paths or "vulnerabilities" that need a precondition the attacker can never reach. One summary of the episode, byteiota's write-up, cites the curl project's experience, where it says 20% of submissions were AI-generated, only about 5% of reported vulnerabilities turned out to be real, and each report took between 30 minutes and 3 hours to review. Treat those figures as a secondary account rather than Google's own data, but the shape is consistent with what maintainers have been saying publicly for months.
The same pattern elsewhere
Google is not alone. The same summary reports that curl ended its bounty in January 2026 and that other programs, including an Intel program and the Internet Bug Bounty, paused or curtailed submissions for similar reasons. We could not independently confirm each of those from primary sources for this post, so read them as reported. What we can say from our own coverage is that open source projects have been tightening rules on generated contributions: Codeberg banned vibe-coded projects and System76's COSMIC desktop banned AI-generated code. A bounty freeze is the security-intake version of the same reaction.
Who loses when the channel closes?
The cost lands on the wrong people. Legitimate researchers who used AI as a tool but verified every finding lose a paid route to disclose. Maintainers lose a structured way to receive external security review. The people who automated mass submissions pay nothing, since they were never going to be paid for invalid reports.
There is also a signal-quality issue. If a program cannot separate valid from invalid reports quickly, real vulnerabilities can sit in a queue behind noise. That is a security regression for everyone who depends on the affected code, not just for the bounty hunters.
Is AI bad at finding vulnerabilities?
No, and it would be a mistake to read the freeze that way. Labs are actively building AI for defense. See explainx.ai's coverage of OpenAI's Daybreak and Codex Security, the open source Codex Security CLI and SDK, and Claude Security scan and fix. These tools are designed to produce findings with reproduction steps, and to propose fixes, inside a workflow where a person or a gated pipeline confirms the result.
The distinction that matters is validated versus unvalidated. A model that finds a bug and then writes a failing test that demonstrates it is doing real research. A model that outputs a paragraph claiming a buffer overflow in a function that does not exist is generating text. Programs like OSS VRP cannot afford to read the second kind at scale.
What should researchers do now?
If you were planning to submit to OSS VRP, here is a practical sequence.
- Check the scope of your finding. Is it a product vulnerability in a Google open source project (paused) or a supply chain issue (still accepted)?
- Look at alternatives Google named. Its other VRPs may cover the same code if it ships inside a Google product. Read each program's rules before filing.
- Follow the project's own security policy. Most large open source projects publish a
SECURITY.mdwith a private reporting address or GitHub private vulnerability reporting. - Hold the report if the project has no private channel. Do not file public issues for unpatched exploitable bugs.
- Keep a reproduction. Whatever route you use, a runnable proof of concept is the single best way to get taken seriously.
A minimal pre-submission checklist you can adopt, whether or not you use AI to help:
[ ] I ran the proof of concept myself on a clean checkout and it reproduces.
[ ] I can name the exact file, function and commit where the bug lives.
[ ] I can state the attacker's starting position and why the precondition is reachable.
[ ] I read the project's security policy and am using its private channel.
[ ] A human (me) wrote or fully verified every claim in the report.
What should maintainers and program owners learn from this?
If you run any intake that pays for or prioritizes findings, Google's freeze is a case study in the failure mode. A few mitigations that other teams have discussed publicly, offered here as options rather than a prescription:
- Require a working reproduction as a condition of triage, and auto-close reports without one.
- Add a cost to submitting, such as reputation thresholds, a small refundable deposit, or limits on new accounts.
- Prefer categories that are hard to fake. Google's decision to keep supply chain reports open is an example: they demand evidence of real compromise.
- Use AI on the receiving side. A first-pass triage model that tries to reproduce the claim in a sandbox can discard obvious fabrications before a human reads them. The same agents that generate spam can be pointed at filtering it, though that needs care. See explainx.ai's piece on agent security patterns for why sandboxing the triager matters.
- State your AI policy. Say clearly whether generated reports are welcome and what disclosure you expect.
Rewards still exist elsewhere in the AI ecosystem when the target is narrow and verifiable. For comparison, OpenAI ran a bio bug bounty with a $50,000 prize for a GPT-5.6 jailbreak, a tightly specified challenge where success is easy to test.
What people are asking
Is this the end of bug bounties?
Not likely. Programs with narrow scopes, strong reproduction requirements and hard-to-fake categories can keep working. Open, broad programs are the ones under the most pressure.
Will Google bring it back?
Google says an update is expected in the first quarter of 2027. Whether the program returns in the same form, with new rules, or with different reward tiers is unannounced. We will update this post when Google publishes details.
Does this affect Google's other bounty programs?
The announcement is specific to OSS VRP product vulnerability submissions. Google pointed researchers to its other programs, so there is no indication that they are closed.
Should I stop using AI to look for bugs?
No. Use it to generate hypotheses and to write tests, then verify. The rule of thumb is that a report should be something you would stake your reputation on without the model.
How this fits the bigger trend
Three forces are converging. Code generation is cheap, so the volume of contributions and reports is rising. Review capacity is fixed, so maintainers become the bottleneck. And incentive programs, which pay per accepted item, invite automated gaming. Related benchmarks reflect the same worry from the engineering side: SlopCodeBench measures how maintainable AI-written code is, because generated output that nobody can review is a cost, not a gain.
For builders, the practical takeaway is to make verification the product. Whether you are shipping a security agent, a coding agent or a content pipeline, the winning design emits evidence a human or a checker can confirm in seconds. Tools that only produce confident text will increasingly get blocked, banned or ignored by the systems they target.
Related reading
- What is AI slop and how to avoid it
- The slopocalypse: AI slop and the internet
- Codeberg bans vibe-coded projects
- COSMIC desktop bans AI-generated code
- OpenAI Daybreak and Codex Security
- Claude Security scan and fix
- SlopCodeBench and maintainability
Sources: Google VRP on X, TechCrunch, Tom's Hardware. Follow @explainx_ai for updates.
Program details are accurate as of October 5, 2026 and may change when Google publishes its Q1 2027 update.