TL;DR: On October 1, 2026, Google stopped taking new product bug reports in its open-source bounty (OSS VRP, the program that pays you for security holes in Google’s public code). A hole in the program itself, such as a bug in Go or Angular, is not a paid OSS VRP report right now. A hole that lets someone change the source, or swap the file people download, still is. Old reports already in the queue still move. Google promised an update in the first quarter of 2027. That is not a date when the door reopens. Headlines that say the whole bounty is frozen until 2027 are wrong.
The program people are talking about has a dull name. A vulnerability (a mistake in software that lets someone do something the owner did not allow) is the thing they pay for. A report (a private write-up of that mistake, sent to the people who can fix it, not posted in public first) is how you ask. A bug bounty (a standing offer: find a real one, tell us privately, we may pay you) is the offer. Google calls its offers VRPs (vulnerability reward programs, the same idea under a longer name). OSS VRP is the one for open source (software whose source you are allowed to read, and, under its license, change).
Google opened that offer on August 30, 2022. Francis Perron and Krzysztof Kotowicz wrote the launch note. The pay range they printed was $100 to $31,337. By the 2022 year-in-review, more than 100 people had taken part and Google had paid more than $110,000 on this program alone. The whole family of Google bounties is much bigger. This post is only about the open-source one, and only about what changed on October 1.
What kind of hole still pays?
Two holes. They are not the same job. Only one is still a new OSS VRP ticket.
A product vulnerability (a flaw in the program itself, so a person who runs an honest copy can be hurt) is the kind of bug most write-ups mean. The file you downloaded is the file the project published. The instructions inside that file are wrong. Google’s own rules, still on the page under the pause banner, say it is a design or implementation issue that substantially affects the confidentiality (keeping data from people who should not see it) or the integrity (keeping data from being changed without permission) of user data in software built with that project.
A made-up example, so the shape is obvious. Suppose the Go compiler (the program that turns Go code into something you can run; the project is golang/go) had a bug that made a safe-looking program do something the programmer did not ask. The release archive would still be the real release archive. The hole would be in the product. As of October 1, OSS VRP is not taking that kind of report. I am not claiming that bug exists.
A supply-chain vulnerability (a flaw in the path from a developer’s save, through the build, to the file a stranger installs) is the other kind. The path is the supply chain. The file at the end is an artifact (the package, the release archive, or the container people actually install). Google’s rules say this includes the ability to change source, and the ability to compromise artifacts or packages that package managers hand to users.
Another made-up example. Suppose a stranger could push code onto the main branch of golang/go. Or suppose a GitHub Action (a script GitHub runs when code changes, often the script that builds and publishes the release) could be tricked into shipping a different file than the one the maintainers wrote. The honest program would never reach the user. That kind of report is still in scope. The October 1 note says so in one sentence. I am not claiming either hole is open today.
What did October 1 actually close?
One lane. Not the program. Not every Google bounty.
The Google Bug Hunters account posted this at 16:00 UTC on October 1, 2026:
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.
Why is this happening? This pause is due to a significant rise in automated submissions, the vast majority of which are not valid. We will continue to reformat and work on this aspect of the OSS VRP and commit to giving an update in Q1 2027.
The rules page repeats it, and adds two details the tweet compresses. For some repositories tied to Google Cloud products, a product bug may still be accepted through the Cloud VRP (the separate bounty for Google Cloud, not this open-source one). Reports submitted before October 1 are not thrown out.
An automated submission (a report a script sent, often with the words written by a model and a person only clicking send) is the reason they gave. They did not publish a count. I am not going to invent one. Secondary write-ups this weekend say “thousands.” Google’s own words are “a significant rise” and “the vast majority of which are not valid.” Use those.
A pause (a stop, with a date when they will speak again) is not a shutdown. Q1 2027 is when they said they will give an update. It is not a printed reopen date. If you write “frozen until 2027,” you added a promise they did not make.
What does the price list say while the pause is on?
Supply-chain money is still printed. Product-bug cells are dashes.
A tier (a label for how much damage a project can do if it is compromised, which also sets the pay band) is how Google sorts repositories. They published the names in March 2026.
| Tier | What Google said it is | Examples on the public list |
|---|---|---|
| OT0, flagship | The most sensitive projects. Highest pay. | golang/go, angular/angular, bazelbuild/bazel, protocolbuffers/protobuf, flutter/flutter, Fuchsia, google/gvisor, Tink |
| OT1, important | High community impact or high security criticality. | dart-lang/sdk, google-gemini/gemini-cli, the ADK repos, google/re2, google/osv-scanner |
| OT2, standard | Active, stable, often in a package manager. No public list. | The reward panel decides at pay time. |
| OT3, low-priority | Small, experimental, or sample projects. | Also not a public list. |
The full OT0 and OT1 list lives in the google/bughunters repository, under oss-repository-tier. I am not pasting all of it. If your project is not in that file, do not guess that it is flagship.
The same rules page, as indexed on October 4, prints this reward table. The odd cents are not a typo. 31337 is old hacker spelling for “elite.” $31,337, $13,337, $3,133.7, and $1,337 are jokes that also happen to be the amounts.
| Category | OT0 | OT1 | OT2 | OT3 |
|---|---|---|---|---|
| Supply-chain compromise | $3,133.7 – $31,337 | $1,337 – $13,337 | $500 – $3,133.7 | dash |
| Product vulnerability | dash | dash | dash | dash |
| Other security issues | $1,000 | $500 | dash | dash |
Two readings, both required. The dashes on the product row match the pause: there is no listed price for a new product report, at any tier. The “other security issues” row (leaked credentials, weak passwords, insecure installs, in the words of the 2022 launch) still shows $1,000 and $500 for OT0 and OT1. The October 1 note does not mention that row. If that is your finding, read the live page before you file. I am not promising the panel will pay it.
The rules also say the panel picks the final number. They can pay more for a clever, severe, wide bug. They can pay less if the hole needs another bug that nobody has found, or if the user has to do something rare. One report can be several bugs. Several reports can be one bug.
The rules page is a web app. I am quoting the table search engines could read on October 4, plus the banner text. If you are about to file, open the page. Do not file from this post.
Was this a surprise?
No. They already stopped reading the small product bugs in April.
On March 19, 2026, Camille Schneider, Jessica Zhang, and Hayden Blauzvern posted a rule change. The job they named was triage (reading a report and deciding if it is real, a duplicate, or junk). Their words: higher-quality proof, so the triage team can stay on real impact.
What “higher quality” meant, for a memory bug (a bug where the program writes or reads past the memory it was given) in an OT0 or OT1 project: either exact steps that reproduce it in OSS-Fuzz (Google’s system that throws junk inputs at a program for days, looking for crashes), using a fuzz target that already exists, or a patch (a code change that fixes the hole) that is already merged (accepted into the project’s main copy). A non-memory product bug in those tiers did not need a merged patch. OT2 and OT3 product bugs were no longer paid, and an April update on that same post said the Google security team would not triage them at all.
So the October pause is the flagship projects joining a line the smaller projects were already on. From April, a product bug in a sample repo was unpaid and unread by that team. From October 1, a product bug in Go is not accepted as a new OSS VRP product report either.
Where do you send a real finding this week?
Sort by what the attacker can do. Then stop if you cannot show it.
Use this order.
- Can a stranger change Google’s source, or replace the artifact users install? File it with OSS VRP as a supply-chain report. The form still exists. In the Bug Location step, Google says to select OSS VRP and give the repository URL. Say, in the first lines, that this is a supply-chain issue, and name the branch, the Action, or the package. Do not make the reader guess which lane you meant.
- Is the build honest, and the program wrong? Do not send that to OSS VRP and hope the pause is a suggestion. If the repository is closely tied to a Google Cloud product, the rules say you may still report the product bug through the Cloud VRP. The word on the page is “may,” and it says “some” repos. If the hole only exists because you are talking to a model (a large language model, the system that writes the next word), read the AI VRP (the separate bounty for security and abuse issues in Google and Alphabet AI products, launched in its current form in October 2025). A normal bug in Go is not an AI VRP bug. A jailbreak that only makes a model say something rude, inside your own session, is listed as ineligible there.
- Did you already land a security improvement? That is a different program: Patch Rewards (pay for a proactive fix that is already in the project, not for an essay about a maybe-bug). The current rules list tier-1 amounts of $500 for a small “one-liner,” $2,000 for a modest fix, $7,500 for a moderately complex one, and $15,000 for a complicated change that almost certainly blocks a major hole. Through the end of 2026 there is a 2x multiplier for secure-by-design memory-safety work on tier-1 projects, and 3x if that work is on core infrastructure data parsers. Those multipliers do not stack, and they do not apply to the one-liner. You may submit at most 3 times a month. The patch must be at least a month old, so they can see the maintainers did not revert it.
- Was the report already in before October 1? Leave it. Google said outstanding reports are not affected.
If you cannot name the repository, the version, and the line, you do not have a report yet. You have a hunch.
What does a report a human can check look like?
Four pieces. Google already asked for them. The pause is what happens when the queue is full of the other kind.
The rules page asks for a high-quality report: as much detail as you have, a buildable proof of concept (a small demonstration another person can run and see the hole) against a recent build, a crash dump if you have one, and instructions to reproduce it. Test on your own machine. Do not spray a live project with a scanner that creates a pile of traffic. That sentence was on the rules before this pause. It is the whole argument in one line.
A hypothesis (“this function looks like it might be unsafe”) is not a proof. A model is good at that sentence. It is cheap to produce and expensive to refute, because a maintainer (the person who accepts changes, and who has to read the report before anyone writes a fix) has to go and look. That cost is the thing the bounty was spending. The cash was never the scarce part. The afternoon was.
I do not have Google’s rejected pile, so I will not describe a sample bad report they did not publish. I will describe the bar they already printed. If a second person cannot run your steps and see the same result, do not send it. If you used a model to draft the words, that is not the problem. The problem is sending the draft before you have done step 2.
Why does curl belong in a Google post?
Same pressure. Different payroll. Do not mix the numbers.
Curl (the tool and library that moves data across the network, maintained by Daniel Stenberg, used on a huge number of devices) is not a Google project. Its numbers are not Google’s numbers. I am putting it here because it is the public diary of what this pause is reacting to, written by the person who had to read the queue.
On January 26, 2026, Stenberg wrote that the curl bounty would stop on January 31. He dated the slide to the second half of 2024, and said 2025 made it much worse: an explosion of AI slop (fluent reports that are junk, or that hide a model’s guess inside a serious tone), and lower quality even in reports that were not obvious junk. The point of killing the money, in his words, was to remove the incentive to submit made-up findings. They also left HackerOne (the site many projects use to receive private security reports).
On February 25 he undid half of that. GitHub’s private reporting was not good enough for the curl security team. From March 1, 2026, reports go to HackerOne again. The money stayed dead. He wrote that after the bounty ended, the flood dried up substantially, and he was not sure it would stay that way once they returned to the old inbox.
In April 2026, preparing a talk for foss-north on April 28, he described the next phase and called it high quality chaos. The obvious junk was no longer the problem. The rate was higher than ever, about double the 2025 rate, and 2025 was already more than double the years before that. The share of reports that confirmed a real vulnerability was back around the 2024 level, about 15 to 16 percent. Almost every report now used AI somewhere. You can see it in the wording, and in detailed duplicates that a room of separate people would not produce.
Read that next to Google’s note. Turning off the cash can thin out lies. It does not, by itself, shrink a queue of long, mostly-serious, model-assisted reports. Google did not turn off the whole OSS VRP. It turned off the lane that was cheapest to automate: “read this repository, invent a product bug, file it.” The supply-chain lane is harder to fake, because you have to show that you can touch the source or the artifact. That is a guess about why they drew the line there. They did not say that sentence. The line they drew is still the useful fact.
What should you not repeat?
Five claims that are already in circulation, and why they fail.
| Claim | What the sources support |
|---|---|
| Google froze its open-source bounty until 2027. | Product reports are paused. Supply-chain reports are not. The 2027 date is an update, not a reopen. |
| They received thousands of fake reports. | Google did not publish a count. Do not promote a count you cannot point at. |
| A bug in Go is no longer worth fixing. | It is still worth fixing. It is not a new paid OSS VRP product report. Tell the maintainers the way that project already asks, if you have a real proof. |
| Any Cloud repo still pays through OSS VRP. | The rules say some Cloud-tied repos may take a product bug through the Cloud VRP. “Some” and “may.” |
| Curl reopened its bounty and the reports got worse. | Curl brought back the HackerOne inbox on March 1 and left the money off. By April, Stenberg said the junk had eased and the serious-looking volume had not. |
What do you do on Monday?
Three moves. None of them is “generate twenty reports.”
If you hunt bugs for the pay, spend the week on supply chain for an OT0 or OT1 repository, or on a fix you can merge and then leave alone for a month. Read the tier file before you pick a target. A weekend on an unlisted sample repo was already unpaid in April.
If you maintain a Google open-source project, expect the product-bug bounty inbox to go quiet and the confident-but-unproven mail to show up somewhere else: the public issue tracker, a direct email, a pull request with a three-page theory. The four checks above are the filter. Ask for the version, the steps, and what an attacker wins. Close the rest without a debate.
If you only wanted to know whether the headline was the whole story, it was not. The door that was easy to spam is shut. The door that protects the file millions of people install is the one they left open, and it still lists $31,337 at the top.
Common questions about Google OSS VRP product vulnerability pause
Is the whole Google open-source bounty frozen until 2027? No. Product vulnerability submissions to OSS VRP are paused. Supply-chain reports and outstanding reports are not. Q1 2027 is when Google said it will give an update, not a printed reopen date.
Can I still get paid for poisoning a build or swapping a release artifact? That is the supply-chain lane, and the October 1 note says it stays open. The live reward table still prints supply-chain ranges up to $31,337 for OT0. Read the rules page before you file.
Where should a product bug in Go go now? Not as a new OSS VRP product report. Tell the maintainers the way the project already asks if you have a real proof. Some Cloud-tied repos may still take a product bug through Cloud VRP — “some” and “may.”