Google still lists rewards up to $31,337 for supply-chain compromises in its open source projects. As of October 1, it pays nothing for a product vulnerability in the very same repositories. The program did not run out of money; it ran out of people willing to read machine-generated reports.
What Google actually turned off
Effective October 1, 2026, Google's Open Source Software Vulnerability Reward Program stopped accepting product vulnerability reports for reward. Google announced the pause on X the same day, called it temporary, and blamed "a significant rise in automated submissions, the vast majority of which are not valid." The post never used the word AI and gave no figures. It did not need to. Anyone who has worked a triage queue in the last two years knows what fills one.
The numbers behind the decision are visible in the rules. On September 30, a day before the announcement, the change landed in Google's public GitHub copy of the program rules and deleted the product-vulnerability reward table: $500 to $7,500 for flagship projects, $101 to $3,133.7 for important ones. The tier list, last updated in mid-September, covers 26 flagship repositories (Go, Angular, Flutter, Bazel, Protocol Buffers among them) and 47 important ones. The program only launched in August 2022. That is a short life for a lot of attack surface.
Reports filed before October 1 are unaffected, and the rules notice commits Google to an update in Q1 2027. No reopening date. Do not plan your research calendar around one arriving before then.
One loose end matters if you find something tomorrow: the notice does not say whether Google will still take product vulnerability reports without a reward. Go accepts security reports by email to its own team. A security policy in Google's GitHub organization points to g.co/vulnz. Angular's security policy, as of October 6, still said Angular was part of the OSS VRP and named no other channel. If you are holding a real bug, confirm the intake path before you sit on it, then disclose anyway. The fix and the credit still matter even when the invoice does not.
What still pays, and why those scopes survived
Supply-chain compromise reports are untouched. Flagship rewards there run $3,133.7 to $31,337, important tier $1,337 to $13,337, standard $500 to $3,133.7, and leaked credentials with write access stay in scope alongside them. Look at what that scope covers: repository configuration settings, GitHub Actions workflows, access control rules, GitHub app configurations, build systems, release environments, package publication credentials, cryptographic signing keys.
That selection is not an accident. A supply-chain finding is cheap to verify. Either the workflow misconfiguration lets an outsider reach the signing keys or it does not. Either the leaked credential has write access or it does not. There is no prose to argue with. Google kept paying for the categories where validity can be checked mechanically and paused the category where a convincing paragraph costs an engineer an afternoon to disprove.
It also happens to be where real exposure is growing. Build and release machinery is exactly the blind spot we covered in Your Coding Agent Installed 23 Packages in a Minute. Your SBOM Saw Zero. The code gets reviewed while the pipeline that ships it does not. If you are deciding where to point your research time, the queue that still pays and the risk that is actually rising are the same queue.
Two smaller doors stayed open
Flaws in Google Cloud-maintained open source that affect Cloud products route through the Cloud VRP, capped at the IT3b tier (acquisitions and lower-priority products) unless Google's product list says otherwise. Check the ceiling before you invest the hours.
The Patch Rewards Program still pays $100 to $15,000 for security patches, provided the project's maintainers accept your patch and it stays in the tree for a month. Single-vulnerability fixes are reviewed case by case. This program was always underused. It just became the only way to get paid for an ordinary bug in Go.
Triage economics: a plausible wrong report costs more than an obvious one
Here is the part the news coverage skipped. The problem was never raw volume. It was a specific failure mode: AI-generated submissions that look technically credible while containing invented exploit paths and wrong assumptions about how the code behaves. The classic case is a report claiming a vulnerable function is reachable when it is not.
An obviously bad report costs a triager thirty seconds. A plausibly bad one costs hours, because refuting it means building the project, checking the call graph, and proving a negative. InfoWorld reported back in March that the OSS VRP team was already worried about low-quality AI submissions that invented details about how a vulnerability could be triggered. When the vast majority of a queue is that kind of report, the queue stops being a security control. It becomes a denial-of-service attack on your engineers, launched by people who never look at the output.
The escalation was visible in public the whole time. March 2026 brought stronger proof requirements in some tiers, with a merged patch accepted as evidence. In May, Chrome cut standard payouts in favor of concise reports with concrete proof, and Android started prioritizing vulnerability types harder for AI tools to find. In early September, the Go project added an LLM section to its security policy, warning that reporters who forward large amounts of unfiltered model output will not be credited. Then the pause. Anyone watching the sequence saw where it ended.
The pushback: AI finds real bugs
True, and I have written as much. We covered a case where an AI produced a working exploit for a widely deployed plugin in about two hours. But real signal does not rescue the economics. A bounty program lives or dies on the cost of rejecting bad reports, not the value of accepting good ones. If the valid minority cannot cover the triage cost of the invalid majority, the rational move is to close the category and keep the verifiable ones, which is exactly what Google did. The assumption baked into most programs, that report flow is human-scale, broke the same way detections built for a single attacker broke against a 700-account swarm, something we saw in the Hugging Face incident.
The validation bar for AI-assisted findings
If you use AI tools in your research, and I think you should, the answer is not to stop. It is to treat model output as a lead, never as evidence. Here is the bar I would hold any report to before it goes near a program inbox:
- Rebuild the target yourself. Clone the upstream repository, check out the exact release tag or commit you are reporting against, and build it. Models get source code behavior wrong with total confidence. If the bug only exists in the chat window, it does not exist.
- Prove the function is reachable. This is the most common slop failure. Trace from attacker-controlled input to the vulnerable code:
git grepfor callers, then write a small harness or test that drives your input there. My working rule: if I cannot reach the function with a harness in an afternoon, the finding is unproven and I do not submit it. - Attach an artifact, not a narrative. For memory corruption in a C or C++ parser, build with sanitizers and run your input:
clang -fsanitize=address,undefined -g harness.c -o check
./check poc.binA symbolized ASan trace beats three paragraphs of explanation. For Go, run the fuzzer (go test -fuzz=FuzzParse -fuzztime=10m) and attach the minimized crashing input. For path traversal, show the read or write with a clean before and after.
- Map the bug to the program's own definition. The OSS VRP defined a product vulnerability as a design or implementation flaw that substantially affects confidentiality or integrity of user data in software built with the code. Draw that line in two sentences. If you cannot, the triager will not draw it for you.
- Read the project's AI policy before you send. Go now withholds credit from reporters who forward unfiltered model output. Expect every large project to adopt similar language within a year.
- Send the patch when you can. A merged patch has counted as proof since March 2026, and Patch Rewards pays for the fix itself. A patch that survives maintainer review is nearly impossible to confuse with slop, which is why it is the one lane adjacent to product bugs that still pays.
The one-line version: if the strongest evidence in your report is prose the model wrote, you do not have a report.
Which programs reform next
Google is not an outlier. It is the loudest data point. The HackerOne-run Internet Bug Bounty paused new submissions in March, saying AI-assisted discovery had outpaced the open source community's ability to ship fixes. Intel and Linux kernel maintainers have dealt with rising volumes of questionable AI-driven reports, some responding with pauses and adjustments of their own. Microsoft Edge and Linux are among the major FOSS projects facing similar floods of low-quality AI-assisted contributions, and some smaller teams have closed the door on AI-generated work entirely.
My prediction, and it is a prediction, not a leak: before Google's Q1 2027 update lands, at least one more major vendor-run open source program adopts a PoC-or-patch requirement, and several hosted programs follow Chrome's model of paying better for concise, evidence-heavy reports while cutting standard tiers. The most exposed programs share a profile: cash rewards for product bugs in heavily scanned code, a small fixed triage team, a profile high enough to attract scanner operators, and evidence rules that still accept a well-written description. Volunteer-run programs are in the hardest spot. They cannot hire their way out, so their choices are closing intake or demanding patches up front.
Two cheap moves if your income depends on any program. Subscribe to its public rules repository, because Google's change hit GitHub a day before the announcement. And build your track record of validated reports now, since reputation-based triage is the obvious next filter.
The slop problem exists inside companies too. The same tooling that flooded Google's queue is filling internal backlogs with unvalidated findings, and somebody on your team is paying that triage cost. If the gap here is coverage between annual tests, Axeploit's pentest workflow is the product page that matches this article: humans who validate before they report, which is the bar every program in this story is moving toward.
Key takeaways
- Product vulnerability rewards in Google's OSS VRP are paused from October 1, 2026 until at least the Q1 2027 update. Supply-chain compromise reports (up to $31,337), leaked write-access credentials, Cloud VRP cases, and Patch Rewards all still pay.
- The cause is triage economics, not budget. Convincing machine-generated reports with invented exploit details cost hours to refute, and the valid minority could not carry that cost.
- If you submit AI-assisted findings, the new bar is a reproducible PoC on the exact upstream commit, proven reachability, and a sanitizer or fuzz artifact. Unfiltered model output already costs you credit in Go.
- Expect PoC-or-patch requirements and Chrome-style payout restructuring at other programs before Q1 2027. Watch public rules repositories for changes before they hit the news.
- Redirect effort toward supply-chain and patch work. Those scopes pay the most, and they are the hardest for slop to fake.
