Google paused its OSS bug bounty for product flaws over a surge it has not quantified; last figure: 192 in 2025

The only count is for the year before the surge

Google's Open Source Software Vulnerability Reward Program (OSS VRP) processed 192 security reports in 2025, rewarded 62 of them with money, and paid out $327,672. That is the only volume figure for the programme in the Google pages read for this briefing, and it describes the year before the surge that Google now gives as its reason for closing the programme to product vulnerability reports on 1 October 2026. For 2026 Google has published no count, no share that were valid, and no definition of the word it uses for them: automated.

Those figures come from Google's own 2025 review, posted on 11 March 2026. Google's post on X on 1 October gives the reason in one sentence: the pause is due to "a significant rise in automated submissions", and the vast majority of those, it says, are not valid. Neither says how many, over what period, or what "not valid" covers. Everything here was read between about 15:30 and 15:55 BST on Monday 5 October 2026, and Google could add figures at any time.

What the 192 does not establish is how large the 2026 surge was. Google's 19 March post says it saw a "massive surge" over the past few weeks and gives no number either. The 192 is a baseline, and a small one: 16 reports a month, about 3.7 a week (derived: 192 divided by 12, and by 52). Headlines call the cause AI spam, and Tom's Hardware says Google was overwhelmed by thousands of reports, a figure that appears in no Google statement.

The 62 rewarded out of 192 is 32.3 per cent (derived). Rewarded is not the same as valid, and a 2025 share says nothing about 2026, so it is evidence for neither side of the "vast majority" claim.

The pause is also not Google's first move on this category. Between 19 March and 1 October, 196 days, Google narrowed the OSS VRP's product vulnerability category three times: new proof rules and project tiers on 19 March, an April update that stopped rewarding or triaging lower-tier projects, and the closure on 1 October. The programme had run 1,493 days since its launch on 30 August 2022. SecurityWeek's report on the pause refers to changes Google made in May to its Chrome and Android programmes; Google's post is dated 30 April 2026, 154 days before the pause, and SecurityWeek reported it on 1 May.

What Google closed, and what it left open

Google's wording sits in two places, and they do not say the same thing. The table separates what is closed from what is not, using Google's own pages.

What the OSS VRP covers after 1 October 2026. Sources: Google's OSS VRP rules page, X post and Patch Rewards rules, read on 5 October 2026 between about 15:30 and 15:55 BST.

1. Part of the programme

   New product vulnerability reports

   Status on 5 October

   Closed from 1 October. The X post says temporarily; the rules page says no longer accepting.

   Where Google says so

   Rules page, X post

2. Part of the programme

   Product reports sent before 1 October

   Status on 5 October

   Not affected. Outstanding reports of any kind are also unaffected.

   Where Google says so

   Rules page, X post

3. Part of the programme

   Supply chain compromise reports

   Status on 5 October

   Open. The rules page still lists rewards of $500 to $31,337 by project tier.

   Where Google says so

   X post, rules page

4. Part of the programme

   Other security issues, such as leaked credentials

   Status on 5 October

   Still listed: $1,000 for the top tier and $500 for the next. The X post does not mention them.

   Where Google says so

   Rules page

5. Part of the programme

   Google Cloud repositories

   Status on 5 October

   Some product reports may still be accepted through the Cloud VRP; Cloud and AI related reports are pointed to the Cloud VRP or AI VRP.

   Where Google says so

   Rules page

6. Part of the programme

   Patch Rewards Program

   Status on 5 October

   Open, and named by Google as an alternative. Pays $100 to $15,000 once maintainers accept a patch and it stays unreverted for a month.

   Where Google says so

   Rules page, Patch Rewards rules

7. Part of the programme

   When it comes back

   Status on 5 October

   No date. Google promises an update in Q1 2027, 92 to 181 days after the closure (derived).

   Where Google says so

   Rules page, X post

Part of the programme	Status on 5 October	Where Google says so
New product vulnerability reports	Closed from 1 October. The X post says temporarily; the rules page says no longer accepting.	Rules page, X post
Product reports sent before 1 October	Not affected. Outstanding reports of any kind are also unaffected.	Rules page, X post
Supply chain compromise reports	Open. The rules page still lists rewards of $500 to $31,337 by project tier.	X post, rules page
Other security issues, such as leaked credentials	Still listed: $1,000 for the top tier and $500 for the next. The X post does not mention them.	Rules page
Google Cloud repositories	Some product reports may still be accepted through the Cloud VRP; Cloud and AI related reports are pointed to the Cloud VRP or AI VRP.	Rules page
Patch Rewards Program	Open, and named by Google as an alternative. Pays $100 to $15,000 once maintainers accept a patch and it stays unreverted for a month.	Rules page, Patch Rewards rules
When it comes back	No date. Google promises an update in Q1 2027, 92 to 181 days after the closure (derived).	Rules page, X post

The reason sentence is on X only. The rules page says Google is no longer accepting product vulnerabilities and gives no reason; SecurityWeek's report quotes the two together as if they were one statement. The rules page's own reward table shows nothing for product vulnerabilities in any tier. Yet Google's OSS VRP overview page, read at about 15:35 BST, still lists $500 to $7,500 for product vulnerabilities in its flagship block and $101 to $3,133.7 in the block it labels Standard (a label that sits oddly with the rules page, where Standard is the tier that earns nothing for product reports), and still carries a button to report a vulnerability. If that stays uncorrected, a researcher arriving from that page can file a report Google will not take, which would add to the volume Google is trying to cut. That is inference, and Google may fix the page within the hour.

By 1 October the category was already narrow. Since the April update, repositories in the two lower tiers (OT2 and OT3) earn no reward or credit for product vulnerabilities, and Google says its security team will not triage them. For the top two tiers (OT0 and OT1), memory corruption reports needed an OSS-Fuzz reproduction or an already merged patch. So what the closure newly removed is product reports on the flagship and important tiers, which is derived from the rules page and the 19 March post. At launch in 2022, Google welcomed design issues that cause product vulnerabilities; that is the part now closed.

Three narrowings, and the wording that changed

Google's own words moved between steps. On 19 March it wrote of a "massive surge" in AI-generated reports and named two failure modes: reports with invented detail about how a flaw could be triggered, and reports that were technically right about a coding error but of negligible security impact, or in code that cannot be reached. On 1 October the word AI is gone and the word is "automated". The rules page, where the programme's terms live, gives neither as a reason.

That matters because automated can describe scanner output, scripts, AI agents, or a person pasting a model's output into a form. Each has a different fix. Google does not say which dominates. BleepingComputer's headline says AI spam and Tom's Hardware says AI-driven, but neither cites a Google statement that uses those words for October.

The 30 April post on Chrome and Android is about rewards, not volume. It says AI has made it "effortless to produce lengthy, detailed write-ups", shifts the Chrome programme toward concise reports with a reproducer, reduces some amounts, and expects total 2026 rewards to rise. It gives no submission counts either.

Stated and not stated

What Google has published about the OSS VRP surge, and what it has not. Sources: Google's X post of 1 October, the rules page, the 19 March post and the 11 March review, read on 5 October 2026.

1. Question

   How many reports in 2026?

   Stated by Google

   Nothing for 2026. For 2025: 192 processed, 62 rewarded with money, $327,672 paid (11 March).

   Not stated

   Any 2026 count, or the period of the surge. 19 March says the past few weeks; 1 October says a significant rise.

2. Question

   What share were valid?

   Stated by Google

   The vast majority of automated submissions are not valid (1 October). In March, two failure modes: invented trigger detail, and real errors with negligible impact.

   Not stated

   The share, how validity was judged, and whether the share covers 2026 or only the months since March.

3. Question

   AI or automated?

   Stated by Google

   AI-generated reports on 19 March. Automated submissions on 1 October.

   Not stated

   What automated means: scanner output, scripts, AI agents, or people using AI tools, and how many of each.

4. Question

   Cost, capacity or quality?

   Stated by Google

   March: let triage teams focus on the most critical threats. October: invalid volume.

   Not stated

   Any figure for triage hours or cost, or why the March proof rules were not enough.

5. Question

   Did real flaws go unreported?

   Stated by Google

   Researchers are pointed to other reward programmes and Patch Rewards.

   Not stated

   Any estimate of valid reports turned away, or where they now go.

6. Question

   Will it reopen, and will others follow?

   Stated by Google

   An update in Q1 2027 and a plan to reformat the programme.

   Not stated

   Whether or in what form it reopens. Other programmes have acted for different reasons (see below).

Question	Stated by Google	Not stated
How many reports in 2026?	Nothing for 2026. For 2025: 192 processed, 62 rewarded with money, $327,672 paid (11 March).	Any 2026 count, or the period of the surge. 19 March says the past few weeks; 1 October says a significant rise.
What share were valid?	The vast majority of automated submissions are not valid (1 October). In March, two failure modes: invented trigger detail, and real errors with negligible impact.	The share, how validity was judged, and whether the share covers 2026 or only the months since March.
AI or automated?	AI-generated reports on 19 March. Automated submissions on 1 October.	What automated means: scanner output, scripts, AI agents, or people using AI tools, and how many of each.
Cost, capacity or quality?	March: let triage teams focus on the most critical threats. October: invalid volume.	Any figure for triage hours or cost, or why the March proof rules were not enough.
Did real flaws go unreported?	Researchers are pointed to other reward programmes and Patch Rewards.	Any estimate of valid reports turned away, or where they now go.
Will it reopen, and will others follow?	An update in Q1 2027 and a plan to reformat the programme.	Whether or in what form it reopens. Other programmes have acted for different reasons (see below).

Google owes no one counts. The point is what a reader can conclude. The strength of the reason, a vast majority, is a claim from the party that did the counting, and the claim has no denominator. A pause for the stated reason is plausible; this briefing has no way to check it, and neither does anyone else from the published record.

Not valid, duplicate, or right but too many

Programmes that have narrowed or ended rewards in 2026, the reason each gives in its own words, and the figures it gives. Sources: each programme's own page, read 5 October 2026. The Intel report and the kernel list's daily rate are secondary and are marked.

1. Programme and date

   Google OSS VRP: 19 March, April and 1 October 2026

   Reason it gives

   AI-generated reports with invented detail or negligible impact; later, automated submissions, mostly not valid.

   Figures it gives

   None for 2026.

2. Programme and date

   curl: bounty ended at the end of January 2026

   Reason it gives

   To remove the incentive to submit weak or made-up reports, AI generated or not (lead developer, 16 January).

   Figures it gives

   On 16 January: seven reports in 16 hours, none a vulnerability; 20 submissions in 2026 so far.

3. Programme and date

   Internet Bug Bounty (HackerOne): paused from 27 March 2026

   Reason it gives

   AI-assisted research has shifted the balance between findings and capacity to fix them.

   Figures it gives

   None for 2026. The page lists lifetime totals of $1,621,304 paid and 1,059 reports resolved.

4. Programme and date

   Node.js bounty, after the IBB pause

   Reason it gives

   Lost the pooled funding; says the decision was not the project's.

   Figures it gives

   None.

5. Programme and date

   Linux kernel security list: documentation read 5 October 2026

   Reason it gives

   A significant fraction of reports are AI-assisted code reviews that overload maintainers; AI-found bugs are treated as public and need a tested reproducer.

   Figures it gives

   None in the document. A secondary report cites 5 to 10 a day, unchecked.

6. Programme and date

   Intel: mid September 2026 (reported)

   Reason it gives

   None given; Risky Bulletin says Intel declined to comment.

   Figures it gives

   None.

Programme and date	Reason it gives	Figures it gives
Google OSS VRP: 19 March, April and 1 October 2026	AI-generated reports with invented detail or negligible impact; later, automated submissions, mostly not valid.	None for 2026.
curl: bounty ended at the end of January 2026	To remove the incentive to submit weak or made-up reports, AI generated or not (lead developer, 16 January).	On 16 January: seven reports in 16 hours, none a vulnerability; 20 submissions in 2026 so far.
Internet Bug Bounty (HackerOne): paused from 27 March 2026	AI-assisted research has shifted the balance between findings and capacity to fix them.	None for 2026. The page lists lifetime totals of $1,621,304 paid and 1,059 reports resolved.
Node.js bounty, after the IBB pause	Lost the pooled funding; says the decision was not the project's.	None.
Linux kernel security list: documentation read 5 October 2026	A significant fraction of reports are AI-assisted code reviews that overload maintainers; AI-found bugs are treated as public and need a tested reproducer.	None in the document. A secondary report cites 5 to 10 a day, unchecked.
Intel: mid September 2026 (reported)	None given; Risky Bulletin says Intel declined to comment.	None.

Read together, these describe at least three different problems. Wrong reports: invented trigger paths, or code errors with no reachable impact, which is what Google said in March and what curl describes. Duplicate reports: many people running the same tools on the same code and filing the same bug. The Linux kernel's documentation says bugs found with AI assistance surface across several researchers, often on the same day, and the OpenSSF and CNCF guide of May 2026 calls duplicates a common problem. Right reports, too many: the Internet Bug Bounty's stated concern is that findings now outrun the capacity to fix them. The same guide says report quality improved a few months into 2026, after an initial flood it calls AI slop.

Google's October sentence puts the OSS VRP in the first group. Nothing published says what share of its reports belong to which. A count of AI reports would hide all three.

A day before Google closed the door, its threat intelligence group published data from the other side of the ledger. The GTIG analysis of 30 September counts vulnerability disclosures, not reward programme submissions: 5,045 in January 2026, 10,477 in July and 10,740 in August. Exactly half of the vulnerabilities it identified as AI-discovered led to remote code execution, against 26 per cent across the wider CVE record. It also warns that raw volume misleads: about 5,000 CVEs mentioning the Linux kernel were issued from January to August, with no zero-day exploitation observed. GTIG built its AI-discovered set from confirmed lab and vendor disclosures and from advisories that credit AI agents, so by construction it contains accepted findings and not rejected reports (this briefing's reading of its method). It does not contradict a flood of invalid reports to one programme. It does mean that AI-found cannot be read as invalid, and cannot be read as valid. This site's brief on the Rejetto HFS flaw covers an AI-found flaw that was real and was exploited, and the one on Microsoft's weaponisation claim covers how an unsourced timing claim travels.

A bounty is a market for reports

"Bug bounty" and "vulnerability reward program" sound like controls. They are payments for reports. In plain economics, and as inference rather than measurement: where a report costs hours of skilled work to write, payment and effort roughly balance, and where a model can draft one in minutes, the writer's cost falls toward nothing and the reader's does not. Google's 30 April post says as much about write-ups. The people who carry the cost of a bad report are the triagers and maintainers who must disprove it, not the person who sent it. The curl project's own file on why it ended its bounty puts the incentive in one sentence: a bounty gives "too strong incentives" to find and make up problems in bad faith.

For scale, the OpenSSF and CNCF guide says a vulnerability report can take a developer 1 to 8 hours to review, and gives no source for the range. As illustration only, not a Google figure: 100 reports that turn out to be invalid would cost 100 to 800 hours, which is 2.5 to 20 working weeks at 40 hours a week.

The reward money was small. In 2025 the OSS VRP paid $327,672, which is 1.92 per cent of the $17,077,749 Google paid across its programmes (derived from Google's Key Stats page). What a surge of invalid reports consumes is triage time, which Google does not price in anything it has published. That is inference; Google does not say whether cost, capacity or quality drove the decision.

The alternative Google names pays for something else. The Patch Rewards Program pays once the project's maintainers have accepted a patch and it has stayed unreverted for a month, so a person who owns the code has already done the validating. It paid $210,748 in the year to January 2026, against $327,672 for the OSS VRP. The OpenSSF and CNCF guide says the same thing in four words: "Fixes are more important than findings."

"AI found it" is not evidence that a report is valid, and "AI" is not the same as "invalid". The Linux kernel documentation says a report that cannot be reproduced is not a security bug, and that if a tool cannot produce a working reproducer the validity of the report "should be seriously questioned". Google's March post asks researchers to validate AI output while they research. Those are tests of the report, not of the tool that wrote it.

Every publisher here has a stake. Google runs the programme, and its 30 April post names automated tools it builds to find and fix vulnerabilities (Big Sleep, CodeMender and OSS-Fuzz). Google and Google DeepMind are among the seven funders of the $12.5 million the Linux Foundation announced on 17 March for open-source security. HackerOne, which runs the Internet Bug Bounty, says qualifying projects get a community edition that includes AI-assisted triage. None of that makes the stated reasons wrong. It means each party has a view on where the fix lies.

Did real vulnerabilities go unreported?

Nothing published answers that. Reports sent before 1 October are still being handled, supply chain reports are still open, and researchers are pointed at Google's other programmes and Patch Rewards. Whether a researcher with a genuine product flaw in a Google open-source repository now reports it elsewhere, reports it publicly, or does not report it is unknown.

Pointing people at "other VRP programs" may also move volume rather than remove it. Google has not said whether those programmes see the same surge, although its Chrome and Android rules changed on 30 April in the same AI context. This is the gap in the record that matters most to a defender: the pause protects the triage queue, and nobody has measured what it costs the finding of flaws.

What a UK organisation with a small disclosure programme should take from this

The UK reference is the NCSC's Vulnerability Disclosure Toolkit, published on 14 September 2020 and reviewed on 7 November 2024. Its version 2 PDF adds validation and triage. It asks for three things: a contact route, a policy and a security.txt file. Neither the toolkit nor the government reporting policy mentions AI-generated or automated reports (text searched on 5 October 2026), so what follows is what the existing guidance supports, with this briefing's own suggestions labelled. Four points in and around it matter more this week than they did last month.

• The NCSC's own example policy pays nothing. It says the organisation does not offer monetary rewards, expects a response within 5 working days and a triage aim of 10, and tells reporters not to submit non-exploitable findings or best-practice observations such as missing security headers. The government's Vulnerability Reporting Service, which the NCSC's own security.txt points to, also says it offers no monetary rewards.
• The toolkit already has closed states for the reports that arrive in a flood. Its lifecycle closes reports as not applicable (spam, not a vulnerability, out of scope), duplicate, informative or remediated, and it says to validate first by following the steps to reproduce and to tell the finder when a report is not a vulnerability.
• security.txt is not a standard in the strict sense. It is RFC 9116, published as informational in April 2022. Its section 5.8 warns that publishing the file raises the likelihood of reports sent automatically or from scans without human analysis, and tells organisations to weigh the extra resources needed to analyse reports. That warning predates the current wave by roughly four years.
• The route is not optional for some. Under Schedule 1 of the Product Security and Telecommunications Infrastructure security requirements regulations, in force from 29 April 2024, manufacturers of relevant connectable products must publish a point of contact for security reports and when the reporter will get an acknowledgement and status updates. A pause on rewards is a policy choice. A pause on the route is not available to them.

On safe harbour, a policy cannot grant authority it does not have. Section 1 of the Computer Misuse Act 1990, as published on legislation.gov.uk on 5 October 2026 and last amended on 7 February 2023, turns on whether access is unauthorised and contains no defence for good-faith research. The government's own reporting policy says it gives no permission to act in a way that is inconsistent with the law, and says only that if a third party takes legal action against a reporter who complied, it can take steps to make it known that the reporter complied. A review of the Act was proposed in a new clause to the Cyber Security and Resilience Bill on 24 February 2026; this briefing did not establish whether any change has been made. This is not legal advice.

On dependencies, the NCSC's patch wave blog of 1 May 2026 expects a rush of software updates as AI tools expose long-standing technical debt, and recommends that larger organisations gain assurance from their supply chains, commercial and open source. In the cases above (curl, the kernel list, Node.js) the people absorbing the volume are the maintainers themselves. If more programmes close, more of the volume may land on them; that is inference.

The question the pause leaves open

Reward programmes publish what they pay the people who find things. Google has published that for the OSS VRP: $327,672 across 62 rewarded reports in 2025. It has not published what it cost to read the other 130 reports, which earned no money, or how many it is reading now. The same gap exists in your own disclosure programme and in the open-source projects your services depend on.

Who is paid to read the reports that earn nothing, and how many can that person disprove in a week?

Key facts