Google pauses OSS bug bounty submissions over AI-generated spam

Google has temporarily stopped accepting product vulnerability submissions to its Open Source Software Vulnerability Rewards Program (OSS VRP), blaming a flood of low-quality automated reports. The pause took effect October 1 and was confirmed publicly on October 5 through Google's Vulnerability Rewards Program account.

Google's stated reason, verbatim: "This pause is due to a significant rise in automated submissions, the vast majority of which are not valid." The program itself is not shuttered — Google said it will "reformat and work on this aspect of the OSS VRP," with updates expected in Q1 2027.

What's affected

Per Google's announcement:

• Paused: new OSS VRP product vulnerability submissions.
• Not affected: OSS VRP supply-chain reports, and any reports already outstanding.

The OSS VRP, launched in 2022, pays researchers for vulnerabilities in Google-maintained open-source projects and their dependencies. The product-submission channel is the one now closed to new reports.

Why this matters

This is a maintainer-side data point in a problem practitioners have been describing anecdotally for a year: LLM-assisted "researchers" mass-producing vulnerability reports that read plausibly but describe non-existent or non-exploitable bugs. Triage is the scarce resource in any disclosure program, and a generator that emits confident, well-formatted, wrong reports at scale is a denial-of-service against human reviewers.

Google is not alone. The open-source curl project has been vocal for months about AI-generated bug-bounty slop wasting maintainer time, and the pattern — plausible prose, fabricated specifics, no working reproduction — is now familiar to anyone running an intake queue. Google's move is notable because it's a large, well-resourced program publicly conceding that its triage can't keep pace, and choosing to close a channel rather than keep burning reviewer hours.

What to take from it

If you run a disclosure or bug-bounty program:

1. Require a working proof-of-concept or reproduction as an intake gate, not a nice-to-have. Narrative-only reports are the ones AI generators produce cheaply.
2. Rate-limit and attribute submissions per researcher, and track a validity ratio. A submitter whose reports are near-uniformly invalid is a cost, regardless of intent.
3. Don't let report volume become a KPI. The metric that matters is valid findings triaged, not submissions received.
4. Expect this to get worse before tooling catches up. Treat an intake queue as an attack surface, because it now is one.

Context

The irony is pointed: a security program designed to harness human curiosity is being overwhelmed by automated output, and the defense is to add friction back in. The AI-security beat usually tracks models as targets or as attack tooling; this is the quieter third category — AI as ambient operational load on the processes security teams already run. The question Google's pause raises, and doesn't yet answer, is whether disclosure programs can rebuild intake to tell a good AI-assisted report from a bad one, or whether they fall back to proof-of-concept-or-it-didn't-happen. For now, the industry is defaulting to the latter.