Google Zeroed Out the Payout Column: OSS VRP Stops Taking Product Vulnerabilities

2026-10-03 Agent & Supply Chain Security by al-ice.ai Editorial

Google has stopped paying for product vulnerabilities in its open-source software. The change was committed to google/bughunters on 30 September 2026 under the commit message “OSS VRP product vuln pause,” and it takes effect 1 October 2026. The notice now sits at the top of the Product vulnerabilities section of the OSS VRP rules:

“As of October 1, 2026, we are no longer accepting product vulnerabilities submitted to the OSS VRP. For some Google Cloud repos impacting Google Cloud products we may still accept reports covering product vulnerabilities through the Cloud VRP. We will continue to reformat and work on this aspect of the OSS VRP and commit to giving an update in Q1 2027. In the meantime, we encourage you to find impact across our other VRP programs and submit there instead, or pursue the Patch Rewards Program. This change does not affect product vulnerabilities submitted before October 1, 2026.”

The same commit does the quieter thing that tells you it is not a temporary formatting exercise. In the rewards table, the Product vulnerabilities row previously read $500 – $7,500 for the top project tier and $101 – $3,133.7 for the next. Both were replaced with a dash. Every tier in that row now pays nothing.

What is still being bought

Read the rest of the rules file and the shape of the decision becomes clear. The Supply chain compromises category is untouched, and it remains the program’s headline: the ability to modify or submit code on main branches, vulnerabilities in build and release infrastructure, insecure GitHub Actions configuration, disclosure of package-manager publishing credentials, compromise of signing keys. The reward band for that category still tops out in the $13,337 – $31,337 range depending on project tier. The “Other security issues” row still pays $1,000 and $500 at the top two tiers.

So this is not Google withdrawing from open-source security funding. It is Google declining to pay for one specific input — “this function in this library has a bug” — while continuing to pay a 4× premium for “I can put my code into your release artifact.”

The supply-chain rules also retain a requirement that reads very differently in October 2026 than it did when it was written. A submitter must demonstrate the issue is genuinely exploitable, “bypassing the requirement that external contributors must first have PRs approved” — via a TOCTOU condition, a repository that does not enforce review, or some other concrete path. Anything that only triggers after a maintainer approves it is downgraded to credit only. That is a demand for a working attack chain, not a finding. It is close to unsatisfiable by a report generator that has never executed anything.

The pattern this completes

Press coverage has attributed the pause to a flood of AI-generated submissions. Google’s own text gives no reason at all — it says the program is being “reformatted” and promises a Q1 2027 update. We are not going to put a motive in Google’s mouth that Google did not publish. But the sequence stands on its own, and we have been tracking it for most of the year:

curl ended its bug bounty in January after an AI slop flood made triage cost exceed the value of the findings.
ZDI reported an AI-driven submission surge in April that forced major programs to pause intake.
Google restructured its VRP programs in May explicitly for the AI era.
Now the open-source arm of that same restructuring stops buying the commodity category outright.

Set that against Google’s own threat-intelligence finding that monthly vulnerability disclosures roughly doubled over 2026. A company publishing research on a disclosure volume explosion, and simultaneously closing the intake channel for the most voluminous disclosure type, is drawing a line between more findings and more security. Those stopped being the same thing somewhere in the last eighteen months.

Why the split is economically coherent

Bug bounties were always an arbitrage on asymmetric effort: the researcher spends hours the vendor cannot, and the vendor pays a fraction of what the discovery cost. Generative tooling collapsed the researcher’s side of that trade for exactly one class of work — reading a function and producing a plausible vulnerability narrative about it. Supply and triage cost both went up; signal did not.

Supply-chain compromise resisted the collapse because it is not a reading task. Demonstrating that you can land code on a main branch or forge a release artifact requires standing up infrastructure, finding a real misconfiguration in a specific repository, and proving the bypass end to end. The current generation of automated submission pipelines is good at the first kind of work and conspicuously bad at the second. Google’s price list has now been rewritten to match: the category machines can flood is worth nothing, and the category they cannot is worth up to $31,337.

There is a second-order effect worth naming plainly. Product vulnerabilities in Google’s open-source projects did not stop existing on 1 October; they stopped having a paid disclosure channel. Researchers with real findings now route to the Patch Rewards Program, to the Cloud VRP where a Cloud product is implicated, or to the project trackers directly — where as we have repeatedly documented, unpaid reports against volunteer-maintained repositories tend to sit. Removing the bounty does not remove the bug; it removes the incentive to tell you about it before someone else finds it.

What this means if you run a disclosure program

Price by verification cost, not by severity label. Google’s new table is a severity-blind decision: the whole product-vulnerability row is zero regardless of CVSS. The discriminator is how expensive it is to tell a real finding from a confident one.
Make exploitability the admission ticket. The supply-chain section’s demand for a demonstrated review-bypass is the structural defence, and it is portable. Requiring a working chain — not a described one — filters generated submissions without insulting competent researchers.
Expect the reporting channel, not the bug count, to be your bottleneck. The programs that failed this year failed at triage capacity, not at finding things.
If you depend on Google OSS, adjust your assumptions. For the next two quarters at minimum, product-level flaws in those repositories carry no bounty-driven discovery pressure. Treat your own dependency review as the control, not someone else’s incentive program.
Watch Q1 2027. Google committed to an update. The interesting question is whether product vulnerabilities return with a verification gate attached or stay unpriced permanently.

Our verification was primary-source-led. We read the OSS VRP rules file google-open-source-software-vulnerability-reward-program-rules.md from the main branch of the google/bughunters repository and quote the pause notice verbatim as published. We retrieved commit f8bf23ad8 (“OSS VRP product vuln pause,” authored 2026-09-30T15:17:23Z) through the GitHub API and read its diff, which is the source for the $500–$7,500 and $101–$3,133.7 figures being replaced with dashes; those prior amounts are the removed lines of that patch. Supply-chain and other-security-issue reward figures and the PR-approval-bypass requirement were read from the current rules file. Google published no stated reason for the pause in the rules text, and we do not attribute one; the AI-submission context is drawn from our own prior reporting on curl, ZDI and Google’s May VRP restructure, and from Google’s published GTIG disclosure-volume research, each cited in place. We did not submit any report to any Google program.

Sources: