Google stopped accepting new product-vulnerability submissions to its Open Source Software Vulnerability Reward Program on October 1, 2026. Its stated reason was a large rise in automated submissions, most of which were invalid. The company expects another update in the first quarter of 2027.
That is a pause in one intake category, not a shutdown of Google’s entire reward system or a ban on AI-assisted research. It exposes a more specific failure: generating a plausible security claim has become cheap, while establishing whether the claim is real still requires scarce expertise.
What closed, and what remains available
Google launched OSS VRP in 2022 for qualifying open-source security issues. Product-vulnerability reports concern defects in code, logic or design. The October pause applies to new submissions in that category; reports arriving before the cutoff remain eligible.
Supply-chain submissions remain open. Some issues involving Google Cloud repositories may qualify under Cloud VRP, depending on the affected product and program rules. Other Google programs, including those covering Chrome, Android, devices and AI security, also continue. Researchers should check actual scope rather than assume that every repository has the same alternative route.
The suspension followed earlier changes. Google’s 2026 rules required submitters to validate AI-assisted findings and show real security impact. In April it removed monetary rewards and public credit for certain lower-tier product vulnerabilities and other security issues. Those narrower incentives and evidence rules did not prevent the later pause.
Google has not supplied a precise count, acceptance rate or triage backlog for the suspended channel. Secondary reporting described thousands of weak submissions, but that is not a number in Google’s notice. “Most invalid” establishes a serious quality problem without providing a complete statistical baseline.
The replacement is undecided publicly. Tested reproductions, submission limits, identity requirements and automated screening are possible responses, not announced conditions for a reopened program.
A convincing report can still describe no vulnerability
A model can identify a suspicious operation, draft an exploit narrative and attach an apparently professional severity assessment. The operation may never receive attacker-controlled input, may be unreachable, or may already sit behind effective validation. A real programming defect may also lack a security consequence under the project’s threat model.
Reviewers have to reconstruct those conditions. They inspect revisions, reproduce behavior, examine mitigations and search for duplicates. An invented function or triggering condition can remain hidden inside otherwise coherent technical prose. Good formatting is no longer a useful substitute for research evidence.
Christopher Robinson of the Open Source Security Foundation estimated in March reporting that projects accustomed to two or three weekly reports could receive hundreds at once. He put individual investigations at two to eight hours of unplanned maintainer work. Those are attributed observations across projects, not Google-specific queue measurements.
Financial incentives can intensify the imbalance. A submitter can generate many speculative claims while the receiving project pays most of the validation cost. Duplicates, exaggerated severity and misunderstood documented behavior consume attention alongside genuine discoveries. Even well-intentioned volume can crowd out repairs.
The relevant distinction is not whether a model helped write the report. Translation, explanation and test generation can improve legitimate work. A person still needs to understand the reachable path, reproduce the result and answer follow-up questions. Rewriting an untested AI claim in human prose does not make it verified.
Validated AI research shows why a blanket rejection would fail
Google continues to develop AI-assisted defenses, including OSS-Fuzz, Big Sleep and CodeMender. Its internal teams can define targets, collect execution evidence and review patches. An external program receives submissions from many different tools and environments without the same controlled chain.
Google’s wider rewards also remain substantial. Its annual review says it paid more than $17 million to over 700 researchers in 2025, more than 40% above 2024. These totals cover its broader programs; they are not the budget or productivity of the paused OSS category.
Another useful contrast comes from validated AI research. Anthropic said Claude Opus 4.6 found more than 500 previously unknown open-source vulnerabilities, each validated by humans or external researchers before disclosure. Mozilla received 112 reports over two weeks and issued 22 advisories, including 14 high-severity ones. Many remaining reports were classified as non-security bugs.
Those units should stay separate: reports, advisories and validated vulnerabilities are not interchangeable counts. The example supports a workflow of machine discovery plus expert validation, not a guarantee that any model-generated report is reliable.
Automated triage might also help cluster duplicates or request missing evidence. It can make mistakes too. A model agreeing with another model is weaker evidence than an independently reproducible test. Human escalation remains necessary for unusual findings and disagreements.
Curl, Linux and HackerOne changed different parts of the handoff
Curl ended monetary bounties on January 31, 2026 after running its program since 2019. Daniel Stenberg reported 87 confirmed vulnerabilities over the program’s life, but the share of submissions confirmed as vulnerabilities fell from above 15% previously to below 5% in 2025.
His explanation combined AI-generated noise, weaker non-AI reports and an excessive focus on rewards. Removing payments did not end responsible security disclosure: private GitHub reporting and email remained routes. It targeted incentives while accepting the risk that careful independent researchers might also lose motivation.
Linux faced repeated discoveries from people using similar AI tools. Private handling prevented researchers from seeing existing discussions or fixes, so maintainers repeatedly processed the same issue. Torvalds argued for public project channels for many broadly rediscoverable findings unless genuine secrecy was needed.
That is not an instruction to publish every unpatched exploit. The kernel’s guidance emphasizes concise descriptions, affected revisions, triggering conditions, tested reproductions and realistic impact. Reporters should understand the code and involve the right maintainers, contributing a patch where possible.
HackerOne reported industry submission volume rising by more than 100% after stronger AI tools appeared in February 2026. Its account includes useful discoveries as well as duplicates and unverifiable claims. It reinforces reproducible proof, accurate severity and consideration of defenses; large unverified batches can trigger enforcement. This is an attributed platform observation, not Google’s invalid-report rate.
The interventions differ: Google paused a category, curl removed monetary incentives, and Linux adjusted reporting expectations and routing. Their shared constraint is limited expert attention, especially where important commercial dependencies are maintained by volunteers.
Reopening needs both evidence and a route for newcomers
Strict gates can protect reviewers while hiding real vulnerabilities. Reputation requirements favor established researchers. Deposits or opaque invitation systems can exclude newcomers. A mandatory exploit can also encourage unsafe testing when a minimal controlled reproduction would have demonstrated the issue.
A sound evidence package identifies the commit, environment, attacker influence, triggering input and security boundary crossed. It should document what was actually tested, distinguish inference from observation and protect confidential details. It need not demand harmful exploitation or disclosure of sensitive code to an unapproved hosted service.
Screening should reject missing evidence without treating AI-sounding prose as proof of invalidity. There is no dependable writing-style test for whether a finding is real. Appeals and specialist escalation matter because unconventional chains may not fit a simple template.
Google’s next update will show whether the lane reopens with clearer evidence requirements or narrower participation. Useful outcomes include confirmed and duplicate rates, review time, remediation time, reviewer burden and false rejection—not merely fewer submissions. Other projects have reported different experiences, including Mozilla’s earlier stable invalid-report rejection rate, so Google’s situation cannot define the whole ecosystem.
The constructive dividing line is between discovery scale and submission scale. Agents can explore broadly, but humans should receive validated, deduplicated findings with accountable owners. Google’s pause is not a verdict that AI cannot find bugs. It is evidence that unlimited hypotheses do not become security value until someone proves them.
Sources
Google OSS program rules · Maintainer workload reporting · False-report investigation · Mozilla’s validated findings · Curl bounty decision · Engineering knowledge base · Google suspension reporting · Google’s earlier rule changes · Google 2025 reward totals · HackerOne report-volume analysis · Linux security reporting rules · TechCrunch report on Google's pause · Techmeme coverage of Google's pause