Google pauses its open source bug bounty over AI reports

📌 Later developments: Chrome: a $250,000 exploit chain built with AI in six days (October 14, 2026) · Chrome VRP: Google raises rewards, but only partly (October 13, 2026)

Google has suspended until 2027 part of its reward programme for vulnerabilities in open source projects, the Open Source Vulnerability Rewards Program (OSS VRP). The reason, in the company’s words, is a significant rise in automated submissions, the vast majority of which are not valid.

There are no CVEs to fix and no products to update. The news still matters to anyone who handles vulnerabilities: AI makes convincing reports cheap to produce, while checking them still takes an engineer’s time.

What happened

According to Infosecurity Magazine, the announcement came on 1 October 2026 in a statement Google posted on social media. The Hacker News and CSO Online specify that the pause covers product vulnerability reports in the OSS VRP: Infosecurity Magazine speaks more broadly of a suspension of the programme, but confirms two exceptions:

• OSS VRP supply chain reports are still accepted;
• reports already submitted are not affected by the suspension.

Google plans to reformat the programme and expects to provide an update in the first quarter of 2027. In the meantime it encourages researchers to look for impact in its other reward programmes or to take part in the Patch Rewards Program.

The OSS VRP programme

The OSS VRP was launched in August 2022 and rewards those who find vulnerabilities in Google’s open source projects. It covers the latest versions of software hosted in Google’s public repositories on GitHub and in selected repositories on other platforms, including their configuration: GitHub Actions workflows, access control rules, GitHub application settings. Rewards range from $100 to $31,337, depending on severity and the importance of the project.

Vulnerabilities in projects closely linked to Google Cloud or to AI products go through dedicated programmes instead, the Cloud VRP and the AI VRP.

Warning signs in previous months

According to CSO Online, the suspension follows earlier attempts to contain the problem. In March Google had already tightened the OSS VRP rules after a sharp rise in AI-generated reports: some described incorrectly how the vulnerability could be triggered, others flagged coding defects with little security impact. For some classes of vulnerability Google began asking for stronger evidence, such as reproducible results or accepted patches, and later stopped rewarding certain lower-tier product reports.

The technical picture: validation is the bottleneck

The sources describe no attacks, malware or indicators: there is no attack chain to map to MITRE ATT&CK. The technical point lies elsewhere: whoever receives a report has to establish whether the code exists, whether the attack path is reachable and whether the impact is real. A credible report can be generated in minutes; checking it may require an engineer to trace the code and reproduce the claimed conditions.

A high volume of submissions does not necessarily mean low quality. CSO Online cites two examples:

• Vercel received 1,285 reports in two weeks during a security challenge on its Sandbox environment, automated part of the triage and eventually validated a few dozen;
• a critical vulnerability in Rejetto HTTP File Server, found with the help of an AI model, was later targeted in exploitation attempts.

The experts interviewed by CSO Online point to two risks for defenders:

1. triage as a target: an unfiltered reporting channel could let an attacker consume a security team’s capacity without breaching any system, for example by submitting variations of the same report to several services. The sources stress that there is no evidence Google was the target of such a campaign;
2. prompt injection in reports: if triage is handed to an AI agent, a malicious report may contain instructions designed to manipulate its assessment or make it take actions through connected tools.

Impact for European and Italian companies

The suspension concerns Google’s programme, but the same imbalance between discovery and validation can arise inside a company: in reports coming from outside and in the output of AI-assisted analysis tools used internally. A finding that reaches an application owner before it has been assessed can waste hours of work even when the affected version is not deployed or the vulnerable code cannot be reached.

For NIS2 entities, vulnerability handling and disclosure are part of the risk management measures the directive requires: a triage process that only holds up at low volumes is a weakness to take into account.

What to do now

1. Ask for reproducible evidence from anyone reporting a vulnerability through your channels, group duplicate reports and limit submissions when abuse patterns emerge.
2. Check presence and reachability first: is the affected version installed? Is the service exposed? Only then does the report become a priority.
3. Treat every scanner finding as a hypothesis, not as proof of an exploitable vulnerability.
4. Prioritise by context: an exposed, critical system or a vulnerability already exploited counts for more than the severity score alone.
5. Treat report text and code as untrusted input: if you use AI for triage, keep testing away from production systems and have a person check important actions.
6. Measure validation effort and the age of confirmed high-risk vulnerabilities, not the number of findings tools produce. If the team spends more and more time rejecting weak reports while confirmed issues stay open, the process needs revisiting.

How ARXDOME helps

ARX Shield shows open vulnerabilities by machine and by package, with their age and those already exploited by attackers highlighted: it helps you see straight away whether a reported piece of software is actually installed on your systems. ARX Expose adds the outside view, with known vulnerabilities on public services, to tell what is exposed from what is not.

Last updated: 6 October 2026