⌁AI·CYBER·BRIEF▌
Industry13 min read

Google stopped paying for open-source bug reports. The flood of AI submissions is only half the problem

Google froze product-bug submissions to its open-source bounty on October 1, citing a surge of mostly invalid automated reports. curl, Linux and Intel show where that leads.

By AI Cyber BriefSource:Google Bug Hunters — OSS VRP rules (google/bughunters commit f8bf23a)GoogleAnalysisOpen sourceBug BountyVulnerability DisclosureAI-Generated Reportscurl

Google has stopped accepting reports of ordinary product bugs to its Open Source Software Vulnerability Reward Program (OSS VRP), effective October 1, 2026, blaming "a significant rise in automated submissions, the vast majority of which are not valid." It is the largest program yet to retreat from paying for open-source bug reports, after curl ended its bounty in January and Intel quietly dropped rewards in September. Our reading is that the industry faces two separate capacity problems, too many fake reports and too many real ones, and a pause on payouts addresses only the first.

The short version

A bug bounty pays outside researchers for valid security flaws. Google's OSS VRP, launched in August 2022, covers Google-owned open-source projects such as Go, Angular, Flutter, Bazel and Protocol Buffers. Those projects sit inside a large share of commercial software.

Since October 1, 2026, Google no longer takes "product vulnerability" reports through that program. These are ordinary bugs such as memory corruption in a parser or a path traversal. Reports about supply-chain compromise are still accepted: those are attacks on the projects' source code or build systems, such as getting malicious code onto a main branch or stealing signing keys. Reports filed before October 1 will still be handled. Google points researchers to its Cloud VRP, its AI VRP and its Patch Rewards Program, and says it will give an update in the first quarter of 2027.

Google's stated reason is automated submissions, most of them invalid. It has not said how many reports it received or what share was invalid. The pattern is not new. This year curl's maintainer described a flood of "AI slop", Linus Torvalds called the kernel security list "almost entirely unmanageable", and Intel removed cash rewards from its program without giving a reason. Maintainers also report the opposite problem: AI tools now find more real bugs than small teams can fix.

Timeline

  • August 2022: Google launches the OSS VRP.
  • January 26, 2026: curl's lead maintainer, Daniel Stenberg, announces the end of the curl bug bounty. It stops on January 31.
  • February 25, 2026: Stenberg says moving reports to GitHub "turns out to have been a mistake". From March 1, HackerOne is again curl's reporting channel, with no money paid.
  • March 2026: Google tightens the OSS VRP rules and requires "higher-quality proof (like OSS-Fuzz reproduction or a merged patch) for certain tiers" (InfoWorld, March 20).
  • April 9, 2026: LWN publishes "A flood of useful security reports". Kernel CVEs rise from 64 in January to 191 in February and 171 in March.
  • May 2026: In the Linux 7.1-rc4 announcement, Torvalds writes that the "flood of AI reports" has made the security list "almost entirely unmanageable" (reported by Phoronix on May 18).
  • July 2026: curl takes the whole month off from accepting vulnerability reports. Stenberg's August 3 post calls it "possibly our best project decision in a long while."
  • September 18, 2026: Phoronix reports that Intel's Intigriti bounty, which paid $500 to $100,000, is "suspended". It has been replaced by "a responsible disclosure program without bounties." Intel gives no reason.
  • Around September 30, 2026: Google publishes commit f8bf23a ("OSS VRP product vuln pause") to its public google/bughunters rules repository. The commit adds the pause notice and removes every product-vulnerability reward amount.
  • October 1, 2026: The pause takes effect. Google's @GoogleVRP account announces it on X.
  • October 4–6, 2026: TechCrunch, BleepingComputer, Help Net Security, Malwarebytes and The Hacker News report the pause.
  • October 7, 2026: Stenberg announces that curl 8.23.0 will ship on October 14 with fixes for 22 vulnerabilities, one of them rated HIGH.
  • Q1 2027: Google's promised update on the reformatted program.

What we know

The rule change itself. The authoritative text is Google's public copy of the rules on GitHub. Commit f8bf23a adds this notice under "Product vulnerabilities": "As of October 1, 2026, we are no longer accepting product vulnerabilities submitted to the OSS VRP." It goes on: "We will continue to reformat and work on this aspect of the OSS VRP and commit to giving an update in Q1 2027," and "This change does not affect product vulnerabilities submitted before October 1, 2026." The notice adds that for "some Google Cloud repos impacting Google Cloud products" product bugs may still be accepted through the Cloud VRP.

The same commit replaces the product-vulnerability rewards with a dash. According to The Hacker News, those rewards had been $500–$7,500 for flagship projects and $101–$3,133.70 for important ones. Supply-chain rewards are unchanged in the current rules at $3,133.70–$31,337 for flagship (OT0) projects, $1,337–$13,337 for important (OT1) projects and $500–$3,133.70 for standard (OT2) projects.

The reason. The rules text on GitHub gives no reason. The reason comes from Google's post on X, quoted identically by TechCrunch, BleepingComputer and Help Net Security: "This pause is due to a significant rise in automated submissions, the vast majority of which are not valid." Google's wording is "automated submissions", not "AI". The AI framing comes from the coverage, though it is hard to see what else would explain a sudden surge of automated reports in 2026.

The proof bar was already high. Even before the pause, the rules' acceptance criteria required memory-corruption reports against flagship and important projects to include "either exact OSS-Fuzz reproduction steps … or an already merged patch in the target repository." Product bugs in standard and low-priority projects were "not eligible for monetary reward" at all. Google added the stronger-proof requirement in March, saying the goal was "to filter out low-quality reports and allow us to focus on real-world impact" (via InfoWorld).

Projects are writing their own rules. Go's security policy now states: "Please do not send LLM-generated reports without proper curation." It also says: "Modern LLMs are very good at finding real and important security bugs. Unfortunately, they are also very good at finding imaginary issues." Go "only attribute[s] discoveries to reporters with a substantial percentage of real findings." Go takes reports by email to the Go security team, so the OSS VRP pause does not close that channel.

curl's numbers. In his January 26 post, Stenberg wrote that the bounty produced 87 confirmed vulnerabilities and paid out more than $100,000. The confirmed rate was above 15% in earlier years and fell "below 5%" from 2025, which he linked to "an explosion in AI slop reports." He added: "We suspect the idea of getting money for it is a big part of the explanation." In February he wrote that since the bounty ended, the inflow had "dried out substantially."

The kernel's version. LWN's April 9 article reported that Stenberg was spending hours a day on "really good" LLM-generated reports, and that the kernel security team had added maintainers to handle more useful reports. LWN also said "the high volume of reports causes its own problems." As reported by Phoronix, Torvalds wrote in May that "AI detected bugs are pretty much by definition not secret," and that "if you found a bug using AI tools, the chances are somebody else found it too." The kernel documentation was updated so that such reports go to public discussion rather than the private security list.

Money context. BleepingComputer reports that Google has paid more than $81.6 million through its reward programs since 2010, including a record $17.1 million to more than 700 researchers in 2025.

Technical analysis

This section is our assessment unless attributed.

Bounty economics have shifted. A bounty program works as long as producing a convincing report costs the reporter more than reviewing it costs the vendor, and the payout covers the reporter's gap. Large language models have cut the cost of producing a plausible report close to zero. Disproving a report still takes an expert: to reject a claimed heap overflow in a protocol parser, a triager has to build the project, run the reproducer and read the code. Each invalid report therefore transfers expensive human time from the vendor to whoever generated it. The CSA note likens this to resource exhaustion, a denial-of-service attack on triage that can happen even without bad intent. A cash reward makes it worse, because sending one more report costs the sender almost nothing and might pay.

Proof gates did not hold, and that is the telling detail. Google already demanded an OSS-Fuzz reproduction or a merged patch for the most common bug class at its most valuable tiers. It still paused. Google has not explained why, but there are three plausible readings. Confirming that a "reproduction" really reproduces still costs triage time. Non-memory-corruption bugs never needed a merged patch, so they stayed cheap to claim. And an automated sender can produce the form of a proof without the substance. Whichever it is, evidence requirements alone did not bring the queue back to a manageable size.

The supply-chain carve-out makes sense. Google kept the category where a valid finding is rare, high-impact and hard to fake. The rules require showing an exploit that bypasses the requirement for maintainer approval of external pull requests. That is a statement about Google's own GitHub organisation and build infrastructure, which Google can check against its own logs. Product bugs in widely forked libraries are the opposite: plentiful, cheap to allege, and expensive to rule out.

Two problems, not one. The failure in the Google and curl cases is invalid volume, meaning hallucinated or inflated reports. The kernel's failure is valid volume: real bugs, many of them duplicates, because many people run similar tools on the same code. Torvalds's point that AI-found bugs are "by definition not secret" sums it up. If five teams can find the same bug with the same model, a private 90-day embargo protects very little. Refusing to pay addresses the first problem by removing the incentive. It does nothing about the second, and could make it worse if capable researchers stop reporting through structured channels. Vendor claims of large AI-assisted discovery programmes, such as Google's own threat-intelligence data in our October 1 coverage, the Glasswing tally in our October 7 article and Microsoft's FORGE lab figures in our analysis of its 140 Windows CVEs, point to more valid findings coming, not fewer.

What is new about the AI angle. Low-quality bounty spam is nothing new. What has changed is that the same technology produces both the noise and a growing share of the real findings, so triage teams cannot filter "AI reports" as a class. Go's policy reflects this: it judges reporters on their track record of real findings, not on their tools. That moves the trust decision from the report to the reporter, and that shift is the real design change.

What remains unclear

  • The numbers. Google has published no submission count, no invalid share and no breakdown by tier. "Vast majority" is all there is.
  • "Automated" versus "AI". Google's post does not use the word AI. We do not know whether it saw fully automated agent pipelines, people pasting model output, or both.
  • Which wording is current. BleepingComputer quotes the live rules page as saying "We are temporarily no longer accepting OSS VRP product vulnerability submissions." The GitHub copy we read says "As of October 1, 2026, we are no longer accepting…". The live page may have been edited separately. We could not read the X post or the rendered rules page directly.
  • Where valid reports go now. Google points to the Cloud VRP, the AI VRP and the Patch Rewards Program. The Patch Rewards Program pays for accepted patches, not for findings. It is unclear whether a valid, unpatched memory-corruption bug in a flagship library now has any paid route at all.
  • Intel's motive. Phoronix links the change to AI report floods only as speculation. Intel has said nothing.
  • Sources disagree on curl's channel. The CSA research note says curl moved reports to GitHub from February 1. Stenberg's own February 25 post says that was reversed, and that HackerOne has been the official channel again since March 1.
  • curl's 22 pending fixes. Stenberg's October 7 post does not say how the vulnerabilities were found and does not mention AI. Details of the HIGH-severity CVE-2026-92392 are due on October 14.

Lessons and what to do

For security and vulnerability-management teams

  • Do not read fewer public advisories as fewer bugs. Bounty retreats reduce one disclosure channel, not the number of bugs in the code. Watch release notes for the open-source projects you depend on most. Put curl 8.23.0 (October 14) in this month's patch plan now, since curl ships inside a very wide range of products.
  • Map your critical dependencies to their reporting channels. For Go, that is an email address; Angular routes reports through Google's Bug Hunters site. If your own researchers find something, you need to know where it goes now.
  • Assume AI-found bugs are not secret. If an internal scan with a commercial model finds a flaw in a widely used library, assume someone else has found it too, and shorten your internal timeline for mitigation and upstream reporting.

For AI builders and anyone running automated bug-hunting

  • Curate before you send. Reproduce every finding by hand, include a working reproducer or a failing test, and include a patch where you can. Projects with policies like Go's will judge you by your share of real findings.
  • Say when a report is AI-assisted, and name one person who is accountable for it.
  • Rate-limit your own pipeline. Sending fifty unverified reports to one maintainer is a denial of service, whatever the intent.

For bounty-programme owners

  • Measure invalid, duplicate and valid report rates and triage time per category before changing payouts. Google has not published these numbers. Publishing them would help the whole industry.
  • Consider gating by reputation: a fast lane for reporters with a validated track record, and stricter proof requirements for new accounts.
  • Treat duplicates as a design input. Public known-issue lists and quick public acknowledgement reduce duplicate reports of the same AI-findable bugs.

For leadership

  • Triage capacity is a cost, not a fixed constant. If your organisation depends on open-source projects whose maintainers are overwhelmed, paying for maintenance, triage tooling or engineering time does more for your risk than another scanner licence.
  • Expect more programmes to follow Google. Plan for vulnerability intake to be rate-limited, invitation-only or unpaid across parts of the open-source ecosystem in 2027.

Sources

Primary:

Coverage:

Newsletter

Get the daily brief

AI + security signal by email: headlines, a two-line summary, a link. No noise, no spam.

How often