Open the rules page for Google's Open Source Software Vulnerability Reward Program today and scroll to the reward table. It has three rows. Supply chain compromises still pay $3,133.70 to $31,337 on flagship projects. Other security issues still pay $1,000 there. The middle row, product vulnerabilities, has a dash in every column.

The coverage since Sunday has run under headlines saying Google froze or halted its open source bug bounty. TechCrunch had it first, and BleepingComputer's report lists what remains open. The headline version loses the detail I find most useful, which is that Google closed one door of three and told you which one.

What the page says

The notice sits under the "Product vulnerabilities" heading and reads, in part: "As of October 1, 2026, we are no longer accepting product vulnerabilities submitted to the OSS VRP." Reports filed before that date are unaffected. Some Google Cloud repositories may still be covered through the Cloud VRP. Google commits to "giving an update in Q1 2027" and, in the meantime, points researchers to its other reward programs or to the Patch Rewards Program.

The rules page gives no reason. That comes from a post from the Google VRP account on X, quoted by BleepingComputer: "This pause is due to a significant rise in automated submissions, the vast majority of which are not valid." The same post says the change "does not impact OSS VRP supply chain reports, or any outstanding reports."

For scale, BleepingComputer reports the programme launched in August 2022 with rewards from $100 to $31,337, and that Google's reward programmes as a whole paid a record $17.1 million to more than 700 researchers in 2025. This is a company that pays for reports at volume and has done since 2010. It has paused the one category.

The row that stayed open

Here is how the rules describe the two categories.

A product vulnerability is a flaw in the code itself: memory corruption in a parser, a failing HTML sanitizer, a path traversal, an insecure example in the documentation. Every one of those can be argued from the source. A reporter, or a model, reads a public repository and writes a case for why a function is reachable with bad input.

A supply chain compromise is a way to tamper with what Google ships: pushing to a main branch, a misconfigured GitHub Action, leaked package manager credentials, a compromised signing key. The rules attach a condition, marked Important: "You must be able to demonstrate that the vulnerability is exploitable, bypassing the requirement that external contributors must first have PRs approved." A finding that only works after a maintainer approves it is treated as insider risk and considered for credit only.

Google has not said why one row survived and the other did not, and I am not going to put words in its mouth. What the page shows is that the surviving category is defined by an attack on one specific live configuration, with a demonstration requirement written into its definition. The paused category is the one where a plausible argument can be assembled from reading code.

There is a second detail on the page. Product vulnerability reports were already subject to acceptance criteria. For the two top tiers of project, a memory corruption report needed either "exact OSS-Fuzz reproduction steps" or "an already merged patch in the target repository." Non-memory-corruption reports in those tiers did not need a patch. And for the two lower tiers, product vulnerabilities were not eligible for money at all. I could not establish from the page when those criteria were added, so I will not claim an order of events. They are still printed there, above a reward row that is now empty.

What the announcement leaves out

Two quantities appear in Google's explanation: "a significant rise" and "the vast majority." Neither is a number. There is no count of submissions, no valid rate, no comparison with last year, and no statement of which subcategory or which projects took the load.

Compare the curl project. When Daniel Stenberg ended curl's bug bounty at the end of January, he published the trend: the share of reports confirmed as real vulnerabilities had fallen from above 15 per cent to below 5 per cent during 2025. He also published what the programme had bought over its life, which was 87 confirmed vulnerabilities for over $100,000 in rewards. A reader can weigh that.

And compare Intel, which removed cash rewards from its Intigriti programme in September. Risky Business reported that the programme had offered up to $100,000 per confirmed report and that Intel declined to say why it changed. I would not file Intel under the same cause without a stated reason. Three programmes changed inside nine months, and only two have given the same explanation.

The arithmetic underneath

A bounty is a price on a claim. It works while a claim costs the sender about as much to write as it costs the receiver to check. Writing a convincing vulnerability report used to require understanding the code, which is most of the work of finding a real bug. That cost has fallen a long way. The cost of refuting a wrong report has not fallen with it, because somebody still has to trace the claimed path through the real code and find the place where it does not hold.

The picture that made this click for me is a lost property office that pays a finder's fee. If the fee is paid when someone hands an umbrella across the counter, the office can run all day with one clerk. If the fee is paid for a written description of an umbrella the finder says is somewhere in the building, the clerk now has to walk the building for every slip of paper. Nothing about umbrellas changed. The office started paying for something that became free to produce.

Seen that way, the two paths Google is steering researchers toward share a property. Supply chain reports require a demonstrated bypass. Patch Rewards pays for a merged improvement. The one gate the paused row already had, for memory corruption in the top tiers, asked for the same kind of thing: a fuzzer reproduction or a merged patch. In each, the sender hands over something the receiver can run or merge.

I wrote in July about Google fixing 1,072 security bugs across two Chrome milestones which the company credited to applying models like Gemini. Put next to this week's pause, the two stories describe the same tools at two ends of a queue. Inside a team that owns the code and can run its own reproductions, automated finding produced fixes. Arriving from outside as prose, it produced a pile somebody had to read.

Who this is for

It is for anyone who runs an intake queue where a stranger can submit a claim and someone on staff has to evaluate it: a security@ mailbox, a public issue tracker, a vendor questionnaire inbox, a grants or RFP portal, a support form with a refund attached. The question to ask of your own queue is what the cheapest valid-looking submission costs to produce today, and what it costs you to reject.

It is not for anyone looking for evidence that automated bug finding does not work. Google's statement is about submissions it received in one category. It says nothing about what the same tools find in the hands of people who can test their own output.

What to do with this

  • Read your intake rules for the word "demonstrate". If a submission can be accepted on argument alone, that is the row to look at first.
  • Ask for something runnable. A reproduction script, a failing test, a diff. Running a script is a cheaper check than tracing a paragraph of reasoning through the code by hand.
  • Pay for the fix where you can. A merged patch has already passed your own review.
  • Publish your valid rate. curl's two percentages told the rest of us more than any headline. If your queue is degrading, the number is the argument for changing it.
  • Close the narrowest door that solves it. Google kept two rows paying. A whole-programme shutdown also turns away the reporters who can demonstrate.
  • Keep a free channel open. curl still takes reports by email and through GitHub's private vulnerability reporting. The payment went and the mailbox stayed.

Google has promised an update in the first quarter of 2027. The thing I will be reading for is whether the product vulnerability row comes back with a number in it, and what a reporter has to attach to claim it. If the answer is a reproduction for every category, what does that do to the researcher whose real finding is a design flaw that no fuzzer will ever trip?