Google Paused Its Bug Bounty Over AI Reports
Google's open source bug bounty stopped accepting product vulnerability reports on October 1. The company's stated reason, posted on X and on the programme's rules page, is a significant rise in automated submissions, the vast majority of which were not valid. Google has the engineering capacity to review almost anything, and it closed the door rather than scale the reading.
What was paused, precisely
| Detail | Status |
|---|---|
| Product vulnerability reports | Not accepted as of October 1, 2026 |
| Supply chain reports | Unaffected |
| Reports already submitted | Unaffected |
| Some Google Cloud repositories | May still be covered via Cloud VRP |
| Next update promised | Q1 2027 |
This is a scoped pause rather than a shutdown, and the programme, which covers Google open source projects including Go, Angular and Protocol Buffers, has run since 2022. Researchers are being pointed at Google's other reward programmes and at its Patch Rewards Program, which pays for proactive security improvements instead of reports. Some coverage describes the invalid submissions as containing hallucinated findings, attributed to secondary reporting rather than to Google directly.
The asymmetry that held for twenty years
A credible vulnerability report took a researcher hours or days. That cost set the volume, and it also sorted the queue, because almost nobody spends a day producing something worthless. The programme was never designed around that constraint. It simply worked inside it.
Producing something that reads like a competent vulnerability report now takes minutes, and the reader still has to reproduce it, check the code path and decide. The sender's cost fell by orders of magnitude. The reviewer's did not. Any process balanced on that difference tips over, and it tips over quickly, because the volume arrives faster than a team can be hired.
Nothing here requires a model behaving badly. People using ordinary tools for their own ordinary reasons produced this, which makes it harder to govern than a security problem and more durable than a trend.
Three responses Google has already tried
Across its programmes Google has now tested each of the three moves available to anyone in this position, which is a useful map.
Change what you reward. For Android, Google said in May it would prioritise vulnerability classes that are harder for AI tools to find, and raised the top reward for a zero-click Pixel Titan M exploit with persistence from one million dollars to one and a half million. Pay more for the things cheap generation cannot produce.
Change what you ask for. For Chrome, standard payouts were reduced in favour of concise reports providing concrete proof that a bug exists. Requiring proof moves the work back to the sender, where it used to sit.
Close the channel. For the OSS programme, the answer was a pause with a date to revisit. A pause with a commitment to come back is a different decision from quietly letting a queue rot, which is the more common corporate version.
Your version of this channel
The test is simple. Does the channel accept free-form material from people outside your organisation, and was the volume historically limited by how long it took them to write it?
Most businesses have four or five that qualify. Job applications, where the collapse is already visible and which we work through in your applicant tracking system is full of AI resumes. Tender and RFP responses, where a twenty-page submission used to signal commitment. Support tickets and complaints, where length used to correlate with a real problem. Warranty and insurance claims, where a detailed narrative used to be costly to fabricate. Vendor pitches, where a tailored proposal meant someone had researched you.
In each one, the signal you were reading was effort, and it is gone. The question is not whether to trust submissions. It is what you ask for instead.
What to change before you have to close something
Ask for something specific and checkable. A reproducible case, a reference who can be reached, a response to a question you chose this week. Generated material is strong on plausibility and weak on particulars that can be verified against the world.
Put a small real step at the point of submission. Not a fee. A structured form that requires its fields to be answered properly, a short task, a scheduled call. The step moves effort back to the sender, which is what used to balance the equation.
Decide your triage policy out loud. Reading everything is no longer a policy you can hold without saying so, and the alternative is sampling with a recorded defect rate rather than reading whatever someone has time for. That choice is set out in quality assurance when AI writes the first draft.
Count what you are rejecting. A channel being flooded is a measurement you should be able to produce, and most businesses cannot say whether their application volume doubled or their acceptance rate halved. The habit of logging what the filter caught is the same one that makes an incident investigable, as in root cause analysis.
The wider pattern
Two programmes pausing in seven months, plus reward structures being rewritten to favour what machines find hard, describes an adjustment rather than an incident. The common thread is that volume without verification has negative value, because it consumes the attention that would have found the real thing.
That is the same cost described in the workslop problem, arriving from outside the organisation instead of inside it, and the supply-chain version of trusting submitted artifacts is in malicious AI skills in the supply chain.
Frequently Asked Questions
What exactly did Google pause?
As of October 1, 2026, Google stopped accepting product vulnerability submissions to its Open Source Software Vulnerability Reward Program. Its stated reason was a significant rise in automated submissions, the vast majority of which were not valid. The pause is scoped: supply chain reports still work, reports submitted before October 1 are unaffected, some Google Cloud repositories may still be covered through the Cloud VRP, and the company has committed to an update in the first quarter of 2027.
Is this the first program to do this?
No, and the pattern is what makes it worth noticing. HackerOne’s Internet Bug Bounty paused new submissions in March 2026, citing AI-assisted discovery outpacing the open source community’s capacity to deliver fixes. Google itself changed its Chrome and Android reward programs in May, reducing standard Chrome payouts in favour of concise reports with concrete proof, and shifting Android rewards toward vulnerability classes that are harder for AI tools to find.
Why does cheap submission break a review process?
Because the effort a submission required was doing unacknowledged filtering work. A detailed report used to cost the sender hours, so the volume was self-limiting and the ones that arrived were usually serious. When generating something that looks equally credible costs almost nothing, volume rises sharply while the cost of reviewing each one stays exactly where it was. The intake was balanced by an asymmetry that no longer holds.
Which business processes have this problem?
Anything that accepts free-form submissions from people outside your organisation. Job applications, support tickets, RFP and tender responses, vendor pitches, warranty and insurance claims, grant applications, review and complaint channels, and abuse reports. In each case the sender’s effort was the filter, and in each case that effort has fallen by an order of magnitude while your reviewing capacity has not moved.
What can we do short of closing a channel?
Three options, and they can be combined. Ask for something a generated submission cannot easily supply, such as a reproducible case, a specific verifiable detail, or a response to something you chose. Add a small cost at the point of submission, which can be a structured form or a required step rather than a fee. And triage explicitly, accepting that you will read a sample rather than everything, with the sampling rate set by how often you find something real.
Rebuild the filter before the queue wins
We help Canadian businesses redesign intake channels around signals that survive free generation, and measure what the filter is actually catching.
Related Articles
Google’s Agent Toolkit Had a Perfect-10 Flaw
When AI Invents Its Sources: A Professional Risk
An AI Escaped Its Test Sandbox: What It Means
Ajan leads the ChatGPT.ca team: 200+ custom GPT builds and automation projects for 50+ businesses across 20+ industries. Based in Markham, Ontario. PIPEDA-compliant solutions.