Why Google is suspending part of its open source bug bounty

On 1 October 2026, Google stopped accepting "product" vulnerability reports in its reward programme dedicated to open source software, the OSS VRP. The official @GoogleVRP account attributes this pause to "a significant rise in automated submissions, the vast majority of which are not valid". The measure is presented as temporary, with no resumption date: Google commits to giving an update in the first quarter of 2027.

Google joins curl, HackerOne's Internet Bug Bounty and arXiv, which have closed or narrowed their intake since January. For software vendors, the issue is taking a regulatory turn. Since 11 September 2026, the Cyber Resilience Act has required every manufacturer selling in the Union to issue an early warning within 24 hours for any actively exploited vulnerability in its products that it becomes aware of. That still means spotting it in the flood.

What Google has suspended, and what remains open

The suspension covers only the "product vulnerabilities" strand of the OSS VRP, that is, flaws found in the code of Google's open source projects. Reports concerning the software supply chain remain eligible. Google encourages researchers to turn to its other reward programmes or to its Patch Rewards Program.

The updated programme rules add two clarifications. "Product" vulnerabilities submitted before 1 October are not affected. Some repositories linked to Google Cloud products can still be reported through the Cloud VRP.

This pause extends an earlier tightening. On 19 March 2026, in a post titled "Streamlining Google's OSS VRP: Key Rule Updates" and supplemented in April, Google reported "a massive surge in AI-generated reports". The company sorted its projects into four tiers, from OT0 (Bazel, Angular, Golang) to OT3. On the first two, a memory corruption had to be reproduced with OSS-Fuzz or accompanied by a merged patch. Tiers OT2 and OT3 no longer qualified for any reward for "product" vulnerabilities. The stated aim was to "filter out low-quality reports" in order to "focus on real-world impact". The 1 October pause extends the restriction to all tiers.

curl went from more than 15% to under 5% confirmed reports

A quantified precedent comes from curl, the open source data transfer tool. On 26 January 2026, its creator Daniel Stenberg explained on his blog the end of the project's bug bounty as of 31 January, a decision made public through a pull request opened on 14 January. Launched in April 2019 with HackerOne, the programme had confirmed 87 vulnerabilities and paid out more than 100,000 dollars to researchers. In previous years, more than 15% of submissions led to a confirmed vulnerability. In 2025, that rate fell below 5%. "Not even one in twenty was real," he writes, blaming "the mind-numbing AI slop", "humans doing worse than ever" and "the apparent will to poke holes rather than to help".

curl then removed all financial rewards, whatever the severity, and redirected reports to GitHub's private vulnerability reporting feature. On 22 April, a second post took stock. The project returned to HackerOne in March 2026, as "GitHub was not good enough". It receives roughly twice as many reports as in 2025, but the rate of confirmed vulnerabilities has climbed back to "somewhere in the 15-16% range". Almost every report now uses AI, Daniel Stenberg notes, and they are now "mostly very high quality".

The Internet Bug Bounty and arXiv have also tightened the filter

The Internet Bug Bounty (IBB), the pooled fund hosted by HackerOne that long paid curl's bounties, froze new submissions on 27 March 2026. Its programme page explains that AI-assisted research "is expanding vulnerability discovery" and that "the balance between findings and remediation capacity in open source has substantively shifted". As of 6 October, HackerOne's API still lists it as "paused". arXiv, for its part, capped submissions on 1 October, citing on its blog an increase in "dense, AI-written papers".

A report is cheap to produce and costly to refute

Daniel Stenberg puts forward an explanation: "the idea of getting money for it" accounts for much of it, since the bounty brings in real reports but "makes it too easy to be annoying with little to no penalty".

The asymmetry lies in verification. Invalid reports take "sometimes also a long time to debunk", the maintainer writes. Pull requests do not pose this problem for curl, since they must pass "200 CI jobs" before any human review. A security report has no automated equivalent: someone has to reproduce the scenario and read the code. Cloudflare reached the same triage finding in a different context, retaining only 49 leads, after human review, out of 1,107 attempts by AI models against its firewall.

Cyber Resilience Act: 24 hours for an exploited flaw

Article 14 of Regulation (EU) 2024/2847 on cyber resilience has applied since 11 September 2026, fifteen months ahead of most of the text, which applies from 11 December 2027 under its Article 71. It requires every manufacturer of a product with digital elements to notify two categories of events: actively exploited vulnerabilities and severe incidents having an impact on the security of the product. Notification goes through ENISA's single reporting platform, launched on 11 September, and reaches at the same time the CSIRT designated as coordinator of the Member State of the manufacturer's main establishment.

An unverified report triggers nothing by itself, but the date on which the manufacturer "becomes aware" of an exploitation depends on how quickly it triages its reports. Article 64 provides, for breaches of Articles 13 and 14, a fine of up to 15 million euros or 2.5% of total worldwide annual turnover, whichever is higher. Like most of the text, this penalty regime only applies from 11 December 2027. Article 64(10), read in the light of recital 120, nevertheless rules out the fine in two cases. The first concerns micro and small enterprises that miss the 24-hour early warning deadline. The second covers any infringement committed by an open-source software steward. A corrigendum to the English version of the regulation extends this exemption to paragraphs 2 to 9 of the Article, and therefore to the fine for Articles 13 and 14. Article 13(6) also creates a flow in the opposite direction. A manufacturer that identifies a vulnerability in a component, including an open source one, must report it to the person or entity maintaining the component. It must also address it and share with them the fix it has developed. Maintainers already solicited by automated reports therefore receive these reports as well.

"Open-source software stewards", legal persons that provide sustained support for free software intended for commercial activities, fall under a separate regime. Article 24 extends the notification obligation to them where they are involved in the development of the products, but it will only apply from 11 December 2027, ENISA recalled on 11 September.

Reproduction, proof of exploitation, fix

Recent reorganisations point in the same direction. Since 19 March 2026, Google had required, for memory corruptions in its first two project tiers, an OSS-Fuzz reproduction or a merged patch. It also points researchers to its patch reward programme (Patch Rewards). The IBB is looking for incentives so that discoveries "translate into durable remediation outcomes". In January, Daniel Stenberg criticised many report authors for rarely offering a fix or working with the team. For a CISO running a disclosure programme, this translates into verifiable requirements: a reproduction scenario on an identified version, proof of exploitation rather than a hypothesis, and an author who can be reached during remediation. These criteria do not exclude AI-assisted reports, which curl accepts provided that the use of AI is disclosed in the report, according to its policy on HackerOne, without requiring the tool used to be specified.

AI-assisted reports also lead to confirmed flaws. On 25 July, three Hacktron researchers compromised OpenAI's internal repository with Claude Opus 5, the model having produced the exploit within a few hours. And on 2 September, CISA added to its catalogue of exploited vulnerabilities an authentication bypass in LiteLLM, precisely the type of event that Article 14 targets.

Verification becomes the bottleneck

These episodes describe a shift in the constraint. Automated discovery is no longer the limiting factor; verification and remediation are, and they remain human. Daniel Stenberg put it this way in April: some projects will struggle to absorb this increase "without any added maintainers". For a vendor subject to the CRA, the ability to triage a report becomes a component of compliance, on a par with component tracking. It determines the moment at which the vendor becomes aware of an exploitation, the starting point of the 24-hour deadline.

Google has promised a progress update in the first quarter of 2027. On 11 December 2027, open-source software stewards will in turn come within the scope of notifications, without exposure to administrative fines, at the same time as all of the regulation's requirements.