Google pauses its open source bug bounty after a flood of automated reports
As of October 1, 2026, Google has stopped taking product vulnerability reports through OSS VRP, its reward program for flaws in open source software. The company points to a steep climb in automated submissions, most of which turned out to be invalid. It plans to rework the program and expects to share news on it in Q1 2027.
Product vulnerability submissions are on hold
OSS VRP, short for Open Source Software Vulnerability Rewards Program, pays researchers who find security flaws in open source projects run by Google. The pause took effect on October 1, 2026. Google announced it on the program website and on X; TechCrunch covered it on October 4, followed on October 5 by BleepingComputer, Help Net Security and the Turkish outlet Webrazzi. The Google statement quoted by BleepingComputer opens plainly: "We are temporarily no longer accepting OSS VRP product vulnerability submissions."
The stated cause is a sharp increase in automated reports, "the vast majority of which are not valid," in Google's words. Citing Tom's Hardware, TechCrunch reports that Google engineers and open source maintainers have been buried under invalid reports, some of them filled with AI hallucinations. According to TechCrunch, Google is pointing participants to its other bug bounty programs in the meantime.
What stays open and where researchers can go instead
The statement carried by BleepingComputer draws the boundaries. Supply chain reports filed under OSS VRP are not affected, and neither are reports already in the queue. Product vulnerabilities sent in before October 1, 2026 are still handled. Researchers keep two alternatives: they can submit fixes to the Patch Rewards Program, which pays up to 15,000 dollars for high-impact patches, and they can report flaws in Google Cloud open source repositories that touch Cloud products through Cloud VRP.
The program has some history behind it. BleepingComputer notes that OSS VRP launched in August 2022 with payouts ranging from 100 to 31,337 dollars. Help Net Security adds that it rewards flaws found in Google projects like Go, Angular and Protocol Buffers. Google says it will keep reshaping the program and has committed to sharing an update in Q1 2027. The sources describe it as a pause, not a shutdown.
More noise makes real flaws harder to spot
Google is not the first to pull back this year. BleepingComputer recalls that in January the maintainer of curl shut down the project's HackerOne bug bounty after a wave of low-quality, AI-generated reports. The same outlet notes that in mid-September Intel dropped all cash rewards from its program on Intigriti. Intel has yet to explain that move, so it would be wrong to pin it on the same cause.
For businesses, the point is less the bounty itself and more the software chain behind it. Websites and online stores lean heavily on open source libraries. When the reporting channels that protect those libraries clog up with automated, low-value reports, genuine flaws may take longer to surface. The episode shows how unchecked use of AI can strain quality control. We looked at a related tension when an open source package registry was flooded by automated tooling in the RubyGems case.
The sources say nothing about Türkiye, so this section is commentary
None of the four sources contains any information about Türkiye. Webrazzi covers the story in Turkish, but its content is limited to Google's global announcement. This section is therefore not drawn from the sources; it is UNALSOFT commentary.
Here is what we do not know: how researchers in Türkiye who report to OSS VRP will be affected, how many invalid submissions arrived or how fast they grew, and what the new setup due in Q1 2027 will look like. Our reading: small business sites in Türkiye run on the same open source components. If the security process behind a library slows down, keeping your own dependencies up to date matters even more.
UNALSOFT's take
We read this less as a bounty decision and more as a reminder about dependency management. A site's security lives not only in its own code but also in how quickly the open source parts it relies on are maintained. The practical step is simple: know which libraries, plugins and versions your site runs, put updates on a schedule and check them before each release. In our web design projects we treat that inventory as part of the handover. Since the sources hold no data on Türkiye, this article does not offer a local impact forecast.
Do you know which open source components your site runs on?
A short conversation is enough to review your libraries, plugins and update routine together.