Open source bug bounty payments for flaws in Google’s own open source projects have stopped, and Google is blaming AI. On 1 October 2026 the company’s Vulnerability Reward Program account posted on X that it was “temporarily no longer accepting OSS VRP product vulnerability submissions”. The reason it gave was blunt: “This pause is due to a significant rise in automated submissions, the vast majority of which are not valid.”
TechCrunch picked the story up on 4 October, reporting that Google had paused its open source bug bounty program “until next year”. The Verge said the scheme would be “frozen until at least next year” and put it more plainly: “It’s slop’s fault.” Google has promised an update in the first quarter of 2027.
The headline is accurate in spirit but broader than the notice itself. Google has paused one category of report, product vulnerabilities, inside its Open Source Software Vulnerability Reward Program, known as the OSS VRP. Supply chain reports are still accepted, reports already in the queue will still be handled, and Google is steering researchers towards its other reward programmes.
Below we explain exactly what is paused and what is not, how this open source bug bounty worked, why AI-generated reports broke it, how the same pressure has already closed programmes at curl, HackerOne’s Internet Bug Bounty, Node.js and Intel, and what the pause means for security researchers and for UK businesses that run on open source code.
Table of contents
- What Google Paused in Its Open Source Bug Bounty Program
- How Google’s Open Source Bug Bounty Worked
- Why AI Submissions Broke the Open Source Bug Bounty Model
- The Open Source Bug Bounty Retreat Across the Industry
- What the Linux Kernel Reveals About AI Bug Hunting
- The Case for AI in Open Source Bug Bounty Work
- What Researchers Should Do While the Open Source Bug Bounty Is Paused
- What the Open Source Bug Bounty Pause Means for UK Businesses
- What Happens Next for Google’s Open Source Bug Bounty
- Frequently Asked Questions About the Open Source Bug Bounty Pause
- References and Further Reading
What Google Paused in Its Open Source Bug Bounty Program
The change is narrower than “Google froze its bug bounty” suggests, and the detail matters to anyone holding an unreported finding.
The notice on X
The announcement came from the @GoogleVRP account at 16:00 UTC on Thursday 1 October 2026, under the heading “PSA for open-source bug hunters”. Its first paragraph reads: “We are temporarily no longer accepting OSS VRP product vulnerability submissions. This does not impact OSS VRP supply chain reports, or any outstanding reports. As an alternative, we encourage you to find impact across our other VRP programs and submit there instead, or pursue the Patch Rewards Program.”
The second paragraph asks “Why is this happening?” and answers with the line about automated submissions, “the vast majority of which are not valid”. It closes with a commitment: “We will continue to reformat and work on this aspect of the OSS VRP and commit to giving an update in Q1 2027.” The post links to the product vulnerabilities section of the open source bug bounty rules on Google’s Bug Hunters site. By Monday it had been viewed more than 57,000 times.
What is still open
Tom’s Hardware, which reported the change on 3 October, added two details. The suspension took effect on 1 October, the day of the announcement, and does not affect product vulnerabilities reported before that date. And Google may still accept product vulnerability reports through its Cloud VRP “for some Google Cloud repos impacting Google Cloud products”.
Put together, the open source bug bounty now looks like this:
| Report type | Status from 1 October 2026 | Source |
|---|---|---|
| New product vulnerability in a Google open source project | Paused | @GoogleVRP on X |
| Product vulnerability reported before 1 October | Still handled | @GoogleVRP; Tom’s Hardware |
| Supply chain report | Still accepted | @GoogleVRP on X |
| Product flaw in some Google Cloud repos that affects Google Cloud products | May be accepted through the Cloud VRP | Tom’s Hardware |
| A security fix contributed to an open source project | Patch Rewards Program suggested | @GoogleVRP on X |
| Bugs in Chrome, Android, Google Cloud or Google’s AI products | Other VRPs remain open | @GoogleVRP on X |
How the headlines compare with the notice
Several outlets framed the change as total. TechCrunch’s headline says Google “froze its open source bug bounty program”, and Neowin’s says Google “issues complete OSS VRP bug bounty pause”. Tom’s Hardware was more careful in its web address, which says Google “suspends part of the OSS VRP”.
For a researcher the difference is real. A supply chain finding, such as a weakness in how a Google project is built or released, can still go to the open source bug bounty today. A code-level bug in the same project cannot, at least not for a reward, until Google publishes its Q1 2027 update.
How Google's Open Source Bug Bounty Worked
Google has paid outside researchers to report security flaws since 2010. The OSS VRP extended that model to the large body of open source code that Google writes and maintains in public.
Launched in 2022 with a $31,337 ceiling
Google opened the OSS VRP in August 2022. Rewards topped out at $31,337, a nod to the “eleet” slang of early hacker culture, and the highest tier covered the company’s flagship projects: Bazel, Angular, Go, Protocol Buffers and Fuchsia. From the start, Google framed this open source bug bounty as a defence against software supply chain attacks as well as a hunt for conventional bugs.
It sat inside a much bigger operation. In its review of 2025, Google said it had paid $17.1 million to 747 researchers across all its programmes that year, a record, with a top single reward of $250,000 and $81.6 million paid since 2010. The Chrome team alone awarded $3,716,750 to more than 100 reporters, and the Cloud VRP paid $3,574,399 to 143 researchers in its first full year.
Two kinds of report
The OSS VRP splits findings into two categories. According to Tom’s Hardware, product vulnerability submissions “focus on code defects, logic flaws, or design bugs within Google’s public repositories”. Supply chain reports cover the machinery around that code, meaning the ways an attacker might tamper with how Google’s open source projects are stored, built or distributed.
Only the first category is paused, and it is the one AI tools find easiest to target. Anyone can point a model at a public repository, ask it to find a flaw, and paste the answer into a submission form. As Tom’s Hardware put it, this used to be “painstaking, manual work requiring skill”, and AI bug-hunting scripts “nearly eliminated the cost and effort the task required”.
The March 2026 warning shot
This is not the first time Google has tightened the open source bug bounty rules. On 19 March 2026 its Bug Hunters blog published “Streamlining Google’s OSS VRP: Key Rule Updates”, describing changes “designed to help us filter out low-quality reports and focus on real-world impact”.
InfoWorld quoted the central change: “To ensure our triage teams can focus on the most critical threats, we will now require higher-quality proof (like OSS-Fuzz reproduction or a merged patch) for certain tiers to filter out low-quality reports and allow us to focus on real-world impact.” InfoWorld also reported that the team was “increasingly concerned about the low quality of some AI-generated bug submissions”, many of which included “hallucinations about how a vulnerability can be triggered”.
Raising the evidence bar did not hold back the tide for long. Roughly six months later, the open source bug bounty stopped taking product reports altogether.
Google has been reworking its other programmes too. On 8 April it introduced “Information Tiers and Action Criticality” to standardise rewards across Google VRP, and on 30 April it changed Chrome and Android reward amounts to reflect “the types of reports and bug categories that provide the most value to security today”.
Why AI Submissions Broke the Open Source Bug Bounty Model
Bug bounties have always attracted weak reports. What changed is the cost of producing one that looks convincing.
What an AI slop report looks like
TechCrunch warned about this in July 2025, when it reported that “AI slop” was reaching bug bounty platforms. Vlad Ionescu, co-founder and CTO of RunSybil, a start-up that builds AI bug hunters, described the experience: “People are receiving reports that sound reasonable, they look technically correct. And then you end up digging into them, trying to figure out, ‘oh no, where is this vulnerability?'”
“It turns out it was just a hallucination all along,” Ionescu said. “The technical details were just made up by the LLM.” The root cause is that chatbots are built to be helpful. “If you ask it for a report, it’s going to give you a report,” Ionescu told TechCrunch. “We’re getting a lot of stuff that looks like gold, but it’s actually just crap.”
According to Tom’s Hardware, Google engineers and open source maintainers were reportedly overwhelmed by “thousands” of poorly written reports that claimed to find bugs but were invalid or “unexploitable hallucinations”, and spent too long validating code instead of fixing genuine flaws.
Cheap to send, expensive to check
The economics explain why the open source bug bounty broke rather than bent. Writing a fake report now costs a few seconds of model time. Ruling one out still costs an engineer’s attention, because the reviewer has to read the code path the report describes and prove that the claimed flaw is not there.
curl, the data-transfer tool, gives a measured example. Its maintainers said that more than 15% of bounty submissions used to be real vulnerabilities, and that in 2025 the figure fell below 5%. The number of reports a reviewer must read to find one real bug is simply one divided by the validity rate:
Reports read to find one real bug, by validity rate (1 ÷ rate)
Each bar is scaled against 100 reports. The 15% and 5% rows use curl’s published rates; the other rows are points on the same curve, included to show how quickly the work grows. Google said only that “the vast majority” of automated submissions were invalid, which puts its rate somewhere below 50%. It has not published a figure.
To put a time on it, assume for illustration that a reviewer needs 30 minutes to rule out a plausible false report. At a 15% validity rate, the 5.7 false reports that come with each real bug cost about 2.9 hours. At 5%, the 19 false reports cost 9.5 hours. At 1%, the 99 false reports cost 49.5 hours, which is more than a working week spent on noise before a single real flaw is fixed.
Why maintainers cannot just filter
The obvious answer is to filter reports automatically, but that carries its own risk. In 2025, Mozilla told TechCrunch that its Firefox reviewers did not use AI to filter reports, as it “would likely be difficult to do so without the risk of rejecting a legitimate bug report”.
That is the trap at the heart of every open source bug bounty. One missed critical vulnerability can cost far more than a thousand wasted hours, so a human reads everything. AI has made the “everything” much larger without making the humans any faster.
The Open Source Bug Bounty Retreat Across the Industry
Google is not the first to step back from an open source bug bounty. Its pause is the latest in a run of programme closures stretching back to January.
curl ended its programme in January
curl launched its open source bug bounty in April 2019 through HackerOne, confirmed 87 vulnerabilities and paid out $101,020 over its life. In January 2026 lead developer Daniel Stenberg announced that the programme would close after 31 January. “AI slop and generally bad reports have only increased even more recently, so we have to make an attempt to slow down the river so as not to drown,” Stenberg wrote.
curl still accepts vulnerability reports. It simply stopped paying for them, removing the incentive to send poorly researched ones. We covered the wider picture in our analysis of how AI is straining open source maintainers.
HackerOne’s Internet Bug Bounty and Node.js
HackerOne’s Internet Bug Bounty, an industry-funded scheme that has run since 2012 and paid more than $1.5 million, paused new submissions from 27 March 2026. Up to then, 80% of its payouts had rewarded new discoveries and 20% supported fixes. “AI-assisted research is expanding vulnerability discovery across the ecosystem, increasing both coverage and speed,” HackerOne said. “The balance between findings and remediation capacity in open source has substantively shifted.”
Node.js felt the effect within a week. On 2 April it announced that it was discontinuing security bug bounties, which it had offered through the Internet Bug Bounty since 2016. Reports are still accepted through HackerOne, but they no longer earn a reward. Node.js has no independent budget to fund an open source bug bounty of its own.
Intel goes bounty-free
In September, Phoronix reported that Intel had suspended its bug bounty, which paid up to $100,000 per flaw. Its replacement on the Intigriti platform “is a responsible disclosure program without bounties”. Intel gave no reason, and Tom’s Hardware noted that experts suspect AI-generated reports played a part. The programme mattered: Intel has said that 105 of the 231 vulnerabilities it addressed in 2020 came through it.
| Date | Programme | What changed | Reason given |
|---|---|---|---|
| 31 Jan 2026 | curl | Bounty closed; reports still accepted | AI slop and bad-faith reports |
| 19 Mar 2026 | Google OSS VRP | Higher proof bar for certain tiers | Low-quality reports |
| 27 Mar 2026 | Internet Bug Bounty | New submissions paused | AI-assisted discovery shifted the balance |
| 2 Apr 2026 | Node.js | Bounties discontinued; reports still accepted | Internet Bug Bounty funding paused |
| Sep 2026 | Intel | Bounty suspended; disclosure without rewards | None given |
| 1 Oct 2026 | Google OSS VRP | Product vulnerability reports paused until a Q1 2027 update | “Significant rise in automated submissions” |
The pattern is consistent. Each open source bug bounty that closed still accepts reports. What has gone is the money, because the money is what draws the flood.
What the Linux Kernel Reveals About AI Bug Hunting
The Linux kernel does not run an open source bug bounty, which makes it a useful control case. It shows what AI bug hunting does to volume even when nobody is being paid per finding.
CVEs per release
According to an August Phoronix report cited by Tom’s Hardware, Linux stable maintainer Greg Kroah-Hartman showed a slide in which the number of CVEs fixed per kernel release jumped from roughly 500 through much of the 6.x era to more than 1,000 with Linux 7.0 and more than 1,500 with Linux 7.2. On that trend, Linux 7.3 could pass 2,000.
CVEs fixed per Linux kernel release (Kroah-Hartman via Phoronix, August 2026)
Bars are scaled against 2,000, so 500 draws at 25% width. The 7.0 and 7.2 rows are drawn at their stated thresholds, and the 7.3 row is a projection rather than a count. Even the floor is a fourfold rise.
“We are completely overwhelmed”
The rise is not a sign that Linux has become less secure. Tom’s Hardware attributes it mainly to people using AI tools to comb through a source tree of more than 40 million lines. Some of what they find is real, but much is low priority, questionable or hallucinated.
In the Linux 7.3 networking pull request, maintainer Jakub Kicinski estimated that between a third and a half of the 648 net-next patches handled in the cycle were AI-driven low-priority fixes, clean-ups or clarifications. “We are completely overwhelmed,” Kicinski wrote. Linus Torvalds has called the duplicate AI reports on the kernel security list “almost entirely unmanageable”.
The pressure is changing what the kernel keeps. In April, developer Andrew Lunn proposed removing about 27,646 lines of legacy network drivers for ISA and PCMCIA-era hardware. “These old drivers have not been much of a maintenance burden until recently,” Lunn wrote, adding that newcomers using AI and fuzzers to find issues were “resulting in more work for Maintainers”.
If AI-generated reports can push maintainers to delete working code that nobody was paid to attack, it is easy to see why an open source bug bounty, which pays per finding, became untenable.
The Case for AI in Open Source Bug Bounty Work
None of this means AI is useless for security research. The same tools that flood inboxes are finding real flaws, and Google is one of the biggest investors in that work.
AI finds real bugs too
Linux CVE records this year explicitly credit AI-assisted static analysis with finding vulnerabilities that were later confirmed by Intel Product Security. Kroah-Hartman has used locally run AI-assisted fuzzing tools to uncover kernel bugs. Tom’s Hardware also reported that OpenAI paid Hacktron researchers a $6,500 bounty for an exploit chain discovered with Anthropic’s model.
The speed is real on the attack side as well. We covered one example in our report on an AI tool that claimed to weaponise a Chrome V8 patch in under a day. Good open source bug bounty work increasingly uses AI. The problem is reports that nobody has checked.
Google’s own bet on AI fixes
Google runs OSS-Fuzz, a free fuzzing service that has found “tens of thousands of bugs” in open source projects since 2016. In July 2026 it began pairing OSS-Fuzz with CodeMender, a Google DeepMind security agent, so that for some memory-safety bugs in C and C++ projects it delivers a proposed patch along with the bug.
The blog post announcing that change, by Alex Kilian and Dustin Ingram, named the problem directly: “Many in the community have experienced large volumes of AI-generated patches that bring net-negative value when accounting for the cost of triage and review.” Google’s answer was to aim AI at fixes that need little review, rather than findings that need a lot.
Paying for triage instead of findings
In March, the Linux Foundation announced $12.5 million in grant funding from organisations including Google, Anthropic, AWS, Microsoft and OpenAI, managed by Alpha-Omega and the Open Source Security Foundation, to help maintainers cope with AI-generated security reports. Kroah-Hartman was candid about its limits: “Grant funding alone is not going to help solve the problem that AI tools are causing today on open-source security teams.”
Platforms are fighting AI with AI. In July 2025 HackerOne launched Hai Triage, which uses AI agents “to cut through noise, flag duplicates, and prioritize real threats” before human analysts step in. The kernel team has secured access to several frontier models to help review patches and filter out hallucinated results.
What Researchers Should Do While the Open Source Bug Bounty Is Paused
If you hunt bugs in Google’s open source code, the open source bug bounty pause changes where your work earns a reward, not whether it is worth doing.
Where Google still pays
Google’s notice points to its other VRPs and the Patch Rewards Program. These are the main routes that remain:
| Route | Best for | Note |
|---|---|---|
| OSS VRP supply chain reports | Weaknesses in how Google projects are built or released | Not affected by the pause |
| Cloud VRP | Flaws in some Google Cloud repos that affect Cloud products | Paid $3,574,399 to 143 researchers in 2025 |
| Chrome VRP | Browser bugs, including Chromium code | Paid $3,716,750 to 100+ reporters in 2025 |
| Android and Google Devices | Mobile and hardware flaws | Paid more than $2.9 million in 2025 |
| AI VRP | Abuse and security flaws in Google’s AI products | Launched in 2025 |
| Patch Rewards Program | Security fixes contributed to open source projects | Named in the pause notice |
The table shows the shift Google wants. Its open source bug bounty paid for finding problems; the Patch Rewards Program pays for fixing them. A researcher who writes the fix rather than just the report is doing exactly the kind of work maintainers have been asking for.
How to write a report that survives triage
Whenever the open source bug bounty reopens, the bar will almost certainly be higher than it was. The March rules already hint at the shape:
- Reproduce it yourself. Run the proof of concept against a real build and include the exact steps and output. An OSS-Fuzz reproduction is the strongest form Google has named.
- Send a fix if you can. A merged patch was the other form of proof Google named in March.
- Show the impact. Explain what an attacker gains, under what conditions, and in which version. A theoretical flaw in unreachable code is the report maintainers like least.
- Disclose your tools. If AI helped, say so, and say what you verified by hand. Honesty about method builds trust with triage teams.
- Never paste model output unread. If you cannot explain every line of a report in your own words, it is not ready to send.
What the Open Source Bug Bounty Pause Means for UK Businesses
Most organisations will never send a report to Google’s open source bug bounty. Almost all of them run software that depends on Google’s open source projects, and many run their own disclosure programmes, so the pause still matters.
Your dependencies have lost a paid audience
Go, Angular and Protocol Buffers sit inside a vast amount of commercial software. Until 1 October, an open source bug bounty gave outside researchers a financial reason to look at that code. That incentive is now gone for product flaws until at least early 2027.
This does not make those projects insecure overnight. Google’s own security teams, OSS-Fuzz and CodeMender keep working, and plenty of researchers report bugs without payment. But fewer paid eyes is a weaker safety net, and it lands at the same time as maintainers say they are already overwhelmed. Expect patch timelines in some projects to stretch.
The practical response is to know what you run. A software bill of materials, regular dependency scanning and a scheduled vulnerability assessment tell you which open source components you rely on and how quickly their fixes reach you.
If you run your own disclosure programme
Any company with a public vulnerability disclosure policy or bounty should assume AI slop is coming. Meta, for example, added a clearer safety warning to its Muse agent after a vulnerability reported privately through its bug bounty, which shows the value of a working channel. The lesson from Google’s open source bug bounty is to protect that channel before it floods, not after.
The defences are simple to describe. Require a reproducible proof of concept. Ask reporters to disclose AI use. Set a published triage target so you can measure volume. Consider safe-harbour wording for good-faith research, and pay for verified impact rather than volume. Commissioned penetration testing remains the most reliable way to get expert eyes on your own systems on your own schedule.
A practical checklist
| Action | Why it matters now | Effort |
|---|---|---|
| Build a software bill of materials | Shows which Google and other open source components you depend on | Medium |
| Automate dependency scanning | Catches published fixes quickly when outside research slows | Low |
| Require proof of concept in your disclosure policy | Filters AI slop before it reaches your engineers | Low |
| Ask reporters to declare AI use | Lets triage weigh unverified output appropriately | Low |
| Track triage hours per valid report | Gives early warning before volume becomes unmanageable | Low |
| Commission independent testing | Replaces the outside scrutiny that bounties used to attract | Medium to high |
For a wider view of how to test AI systems themselves, see our guide to AI red-teaming before launch. Good cybersecurity practice now includes planning for AI on both sides: the attackers using it, and the well-meaning reporters whose unverified output can bury a real warning.
What Happens Next for Google's Open Source Bug Bounty
Google has given itself until the end of March 2027 to say what comes next. It has not said whether the open source bug bounty will reopen in its old form, and its wording, “reformat and work on this aspect”, suggests it will not.
Three likely directions
Based on Google’s March rule changes and what other programmes have done, three directions look most plausible. This is our analysis, not Google’s guidance.
- A permanent proof requirement. Google could extend the March rule so that every product report needs an OSS-Fuzz reproduction or a merged patch. That would cut volume sharply and favour experienced researchers.
- Paying for fixes, not findings. The Patch Rewards Program and CodeMender point towards rewarding remediation. HackerOne said much the same when it noted that the balance between findings and remediation “has substantively shifted”.
- Gated access. Some platforms already restrict programmes to researchers with a track record. A reputation gate would keep the open source bug bounty open to proven hunters while shutting out anonymous bulk submissions.
What to watch before Q1 2027
Three signals will show which way Google is leaning: further updates to the OSS VRP rules page, any change to how the Patch Rewards Program is promoted, and whether more of the open source bug bounty work moves into the Cloud VRP. The wider question is whether paying strangers per finding still works at all when finding is almost free and checking is not.
Frequently Asked Questions About the Open Source Bug Bounty Pause
Has Google shut down its open source bug bounty completely?
No. Google has paused new product vulnerability submissions to the OSS VRP from 1 October 2026. Supply chain reports are still accepted, reports sent before 1 October are still being handled, and Google’s other reward programmes remain open.
Why did Google pause the open source bug bounty?
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 overwhelmed by invalid or hallucinated reports that took time away from fixing real flaws.
When will the open source bug bounty come back?
Google has committed to “giving an update in Q1 2027”, meaning by the end of March 2027. It has not promised that product submissions will reopen then, or on the same terms.
Can I still report a bug in a Google open source project?
You can report it, but you will not be paid through the open source bug bounty for a product flaw while the pause lasts. Check the project’s own security policy, often in a SECURITY.md file. If the flaw affects Google Cloud products, the Cloud VRP may accept it.
Is Google banning AI-assisted bug hunting?
No. Google’s own security work relies heavily on AI, through OSS-Fuzz and CodeMender. The problem is unverified output. A report found with AI but reproduced, explained and ideally fixed by a human is exactly what open source bug bounty triage teams want.
What should my business do about it?
Know which open source components you depend on, scan them continuously, and make sure your own disclosure programme demands reproducible evidence. If you have no programme, commissioned testing is the most dependable way to get independent scrutiny.
References and Further Reading
PSA for open-source bug hunters (Google VRP on X)
Google pauses open-source bug bounty over AI slop submissions (The Verge)
Google Open Source Software Vulnerability Reward Program Rules (Google Bug Hunters)
Streamlining Google’s OSS VRP: Key Rule Updates (Google Bug Hunters)
Stop using AI to submit bug reports, says Google (InfoWorld)
VRP 2025 Year in Review (Google)
From finding to fixing: reducing maintainer burden with automated patches (Google)
AI slop and fake reports are coming for your bug bounty programs (TechCrunch)
The end of the curl bug bounty (Daniel Stenberg)
Internet Bug Bounty program hits pause on payouts (CSO Online)
Discontinuing security bug bounties (Node.js)
Intel suspends bug bounty program that paid up to $100,000 per flaw (Tom’s Hardware)
Google paid $17.1 million for vulnerability reports in 2025 (BleepingComputer)
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.
