The Google bug bounty for open source code just hit the brakes. On October 1, 2026, Google stopped accepting new product vulnerability reports in its Open Source Software Vulnerability Reward Program, known as OSS VRP. The reason is blunt. Too many automated, mostly invalid submissions were landing in the queue.

I'm Nitin Kumar, Lead Project Coordinator at Debugged Pro. Our teams build and maintain software for clients in India and the USA, and many of those clients now run their own security inboxes. This pause is a warning for all of them. Below I cover what Google actually said, what is still open, and what agency teams should change this week.

Rows of identical toy robots on a yellow background, a symbol of automated AI bug bounty submissions — Identical bots, identical reports: the problem Google cited when it paused OSS VRP product submissions. Image credit: DBenitostock / Getty Images via TechCrunch

What Happened to the Google Bug Bounty for Open Source

Google announced the change in a post from its Bug Hunters account on X and on the program website. Anthony Ha covered it for TechCrunch on October 4, and you can read the TechCrunch report on the Google open source bug bounty pause for the original story.

Google's own explanation was short:

"This pause is due to a significant rise in automated submissions, the vast majority of which are not valid."

Google said it will keep working on this part of the program and committed to giving an update in the first quarter of 2027. Note the wording. It promised an update, not a reopening date.

What OSS VRP covers

OSS VRP rewards independent researchers who find and responsibly disclose security flaws across Google's open source projects. Product vulnerability reports focus on code defects, logic flaws, or design bugs inside Google's public repositories. That is the part that is now paused.

Finding these bugs used to take slow, skilled manual work. As Tom's Hardware put it, large language models and automated bug hunting scripts have nearly wiped out that cost and effort. When filing a report costs almost nothing, the queue fills fast.

What Is Still Open in the Google Bug Bounty Program

The headline sounds like a full shutdown. It is not. Here is what Google said stays in place:

Supply chain reports: OSS VRP still accepts supply chain vulnerability reports.
Outstanding reports: anything filed before October 1 is not affected.
Other VRP programs: Google is pointing researchers to its other reward programs.
Patch Rewards Program: researchers can still pursue rewards for security fixes.
Some Google Cloud repos: product bugs in certain repos that affect Google Cloud products may still be accepted through the Cloud VRP.

If your team does security research, read the official Google OSS VRP rules page before you file anything. The rules decide what counts, not news summaries, including this one.

Why AI Bug Reports Broke the Queue

Last year, TechCrunch reported that security experts were warning about AI slop and the risk it posed to bug bounty programs. This pause shows that warning playing out at one of the biggest software companies in the world.

According to Tom's Hardware, Google engineers and open source maintainers were reportedly overwhelmed by thousands of poorly written reports. Many claimed to find bugs that were invalid or simply hallucinated. The real cost was time. People spent hours checking fake findings instead of fixing real, critical vulnerabilities.

Magnifying glass over a red bug on a background of code, representing AI bug reports and vulnerability triage — Every invalid report still needs a human to read it. Image credit: Getty Images via Tom's Hardware

Google is not alone

Tom's Hardware also pointed to similar pressure elsewhere in the industry:

Linux: maintainers said they were "completely overwhelmed" after AI-powered bug hunters pushed the kernel to a record 2,000 vulnerabilities per release.
Linux drivers: the project ended support for some older network drivers after a wave of false AI-generated bug reports.
Intel: the company suspended a bug bounty that paid up to $100,000 per flaw. Intel did not confirm AI reports as the reason, though experts suspect it.

The pattern is clear. AI makes it cheap to produce something that looks like a security report. It does not make it cheap to verify one. That gap lands on whoever owns the inbox.

What the Google Bug Bounty Pause Means for Agencies

Most agencies do not run a bug bounty. But a lot of our clients have a security contact page, a vulnerability disclosure policy, or a shared support inbox where researchers send findings. Those inboxes face the same flood, just at a smaller scale.

There are three ways this news touches agency work in India and the USA.

You receive reports. If you maintain apps or open source packages for clients, invalid AI reports will reach you too. Someone has to triage them.
You send reports. If your developers use AI scanners and file issues with vendors or open source projects, you can become part of the problem.
You advise clients. Clients will ask whether they should start, pause, or change a bounty program. You need a clear, honest answer.

We covered a related shift in our Claude security guide for agency teams. AI tools can genuinely help find bugs. The issue is reports that skip human checking before they go out.

How to Triage AI Bug Reports Without Burning Out

CISA's coordinated vulnerability disclosure process is a good model for small teams. In its intake step, the CISA team first checks whether a report appears legitimate, is actionable, is in scope, and is already known or public. You can read the full CISA coordinated vulnerability disclosure process on the agency's site.

Agencies can borrow that same first filter. Here is a simple triage flow we suggest:

Check scope first. Is the asset actually owned by you or the client? Close out-of-scope reports quickly with a short template reply.
Ask for a working proof of concept. No steps to reproduce, no deep review. A real finding should be repeatable on a recent build.
Check for duplicates. AI tools often flag the same pattern for many people at once. Search your tracker before you start testing.
Time-box the first look. Give each new report a fixed first review window. Escalate only when the evidence holds up.
Track your invalid rate. Log how many reports were valid each month. That number tells you when a policy change is needed.

Update the client's disclosure page

CISA separates two ideas. A vulnerability disclosure policy, or VDP, sets how an organization receives reports, what is in scope, and what reporters can expect. Coordinated disclosure is the wider process of working with vendors and publishing fixes.

For most client websites and apps, a clear VDP is the right first step. Add lines like these:

Reports must include clear steps to reproduce and the affected version or URL.
Automated scanner output without manual verification will be closed.
Reporters must disclose if AI tools were used to find or write the report.
Out-of-scope assets and low-impact findings are listed plainly.

None of this blocks honest researchers. It just sets a bar that a copy-paste report cannot clear.

Rules for Your Own Team Using AI Security Tools

This is the part agencies tend to skip. If your developers or QA engineers run AI code scanners, set rules before anyone files a report with an outside vendor or open source project.

Human verification is required. A team member must reproduce the issue before it leaves the company.
One owner per report. Every outgoing report needs a named person who can answer follow-up questions.
No bulk filing. Never send a batch of scanner findings to a maintainer as separate reports.
Read the program rules. Each vendor's bounty sets its own scope and terms. The Google pause shows those terms can change overnight.
Log tool use. Record which AI tool found the issue and how it was confirmed.

For USA clients with formal security reviews, this log helps during audits. For India-based delivery teams working across time zones, a named owner stops reports from going stale when the person who filed them goes offline.

Should Clients Start or Pause a Bug Bounty Now?

Clients sometimes ask whether they should launch a paid bounty to look mature. After this news, my honest answer is "not yet" for most small and mid-size businesses.

Situation	What we suggest
No security contact at all	Publish a simple VDP and a monitored security email first
VDP exists, low report volume	Add reproduction and AI disclosure rules, then review quarterly
Growing volume of invalid reports	Add a triage template, time-box reviews, and track invalid rates
Mature security team, real budget	Consider a scoped, invite-only bounty with strict proof requirements

Money attracts volume. If your team cannot triage at that volume, a paid bounty can create more noise than safety.

If you need help setting up intake, triage, or secure release workflows, our software development consulting team does this for clients in both regions. For teams running AI agents in production, our AI reliability services cover monitoring and failure handling.

Key Takeaways

The Google bug bounty for open source stopped taking new product vulnerability reports on October 1, 2026.
Google blamed a significant rise in automated submissions, most of them invalid.
Supply chain reports, earlier reports, other Google VRPs, and the Patch Rewards Program are still available.
Google promised an update in Q1 2027, not a reopening date.
Linux maintainers and Intel's bounty have faced similar pressure, according to Tom's Hardware.
Agencies should require proof of concept, update client VDPs, and set internal rules for AI-assisted reports.

FAQ: Google Bug Bounty Pause

What exactly did Google pause in its bug bounty?

Google stopped accepting new product vulnerability submissions to its Open Source Software Vulnerability Reward Program (OSS VRP) from October 1, 2026. Supply chain reports and reports already in the queue are not affected.

Why did Google pause OSS VRP product reports?

Google said the pause is due to a significant rise in automated submissions, the vast majority of which are not valid. Tom's Hardware reported that engineers and maintainers were spending too much time checking reports that turned out to be invalid or hallucinated.

Is the Google bug bounty closed until 2027?

Not exactly. Google committed to giving an update in the first quarter of 2027. That is a promise of an update, not a confirmed reopening date. Other Google VRP programs and the Patch Rewards Program remain options.

Can researchers still report bugs in Google Cloud related repos?

Google said some product vulnerabilities in certain Google Cloud repos that affect Google Cloud products may still be accepted through the Cloud VRP. Check the official rules page before filing.

What should an agency change after this news?

Set a clear policy for AI-assisted security reports, require a working proof of concept before anything goes to a vendor, add triage rules to client vulnerability disclosure pages, and track how much time your team spends on invalid reports.

About the Author

Nitin Kumar is Lead Project Coordinator at Debugged Pro. He works with software and IT agency teams in India and the USA on delivery planning, release processes, and practical security workflows for client projects.