Google Froze Its OSS Bug Bounty: Triage Lessons for You

By Lazar Milicevic · Published November 1, 2026 · 10 min read

If you run a support inbox, a lead form, a contact page, or an open-source project, you already know the feeling: the volume went up, the signal did not, and a human still has to read all of it. Google just hit that wall at scale and paused its Open Source Software Vulnerability Rewards Program (OSS VRP) for product vulnerabilities. Here is what actually happened, what the evidence says about why, and how to build a filtering pipeline for your own inbound before it buries you.

What Google actually paused (and what it didn't)

Google paused new product vulnerability submissions to its OSS VRP as of October 1, 2026, and promised "an update" in Q1 2027. The stated reason was a significant rise in automated submissions, the vast majority of which were not valid (TechCrunch).

The scope is narrower than the headlines suggest. According to BleepingComputer:

• The pause covers only OSS VRP product vulnerability submissions.
• Supply chain reports and outstanding reports are not affected.
• Product vulnerabilities submitted before October 1, 2026 are also not affected.

Google launched the program in August 2022, with rewards ranging from $100 to $31,337. It pointed researchers to alternatives: the Patch Rewards Program (up to $15,000 for high-impact fixes) and the Cloud VRP, which takes reports on Google Cloud open-source repositories that affect Cloud products. The current rules page says Google no longer accepts product vulnerabilities, and its reward table lists no amounts for product vulnerabilities in any of the four project tiers (Help Net Security).

Two caveats before we draw conclusions. First, Google's October statement says "automated submissions," not "AI-generated." Its March post was more explicit about AI (more below). Second, Google has not published a submission count, an invalid-report rate, or the size of its triage backlog (Remio). "Vast majority" is the only quantification we have, so any specific percentage you see quoted elsewhere is not from Google.

The pause was the last step, not the first

Google had already been tightening the OSS VRP for months. On March 19, 2026, its Bug Hunters blog announced rule changes aimed at filtering out low-quality reports (Google Bug Hunters). The post is worth reading because it shows the escalation path any inbound channel tends to follow.

Step one: name the failure modes. Google described two kinds of problem reports:

1. AI-generated reports with hallucinated trigger details.
2. Technically valid coding errors with negligible security impact or unreachable code paths.

That second category matters for your own design. Not all noise is fake. Some of it is real-but-useless, and a filter that only catches "obviously fabricated" will miss it.

Step two: tier the targets. Google introduced four project tiers: OT0 (Flagship, e.g. Bazel, Angular, Golang), OT1 (Important), OT2 (Standard), and OT3 (Low-Priority).

Step three: raise the proof bar where stakes are highest. For OT0 and OT1, memory corruption reports now require exact OSS-Fuzz reproduction steps or a merged patch. The submitter has to bring evidence that is cheap for the reviewer to verify.

Step four: stop paying for the low-value tiers. An April 2026 update to that post removed monetary rewards and credit for "Product Vulnerabilities" and "Other Security Issues" for OT2 and OT3, and Google's security team stopped triaging those reports. It also lowered the maximum OT2 reward for Supply Chain Compromises to $3,133.70. (The update block was added without a date, so "April 2026" is as precise as I can be.)

Step five: pause the channel. That's October 1.

The pattern: add proof requirements, then remove incentives, then close the door. If you wait for step five to design a filter, you've already lost months of reviewer time.

Google isn't alone: curl, Intel, and the Linux kernel

The same pressure showed up elsewhere, and the cases differ in useful ways.

curl ended its bug bounty on January 31, 2026. According to a secondary summary of Daniel Stenberg's post, curl's confirmed-vulnerability rate fell from over 15% to below 5% in 2025, and over its lifetime the program confirmed 87 vulnerabilities and paid out more than US$100,000 (Stingrai). Stenberg said ending the bounty was meant to remove the incentive to submit poorly researched reports, "AI generated or not." In the final week before shutdown, curl received seven submissions, and none described a vulnerability (The Register).

Note his phrasing: the problem is the incentive, not the tooling. A payout attached to an unauthenticated form attracts volume regardless of who or what writes the submission.

Linux kernel: in May 2026, Linus Torvalds called the kernel's private security list "almost entirely unmanageable" because researchers were using AI to flood it with useless reports (Yahoo Tech).

Intel: its bug bounty, which paid up to $100,000, had its financial rewards pulled. Reports say this was to stop a flood of AI-generated reports, but Intel's own reasoning is unconfirmed, so treat the cause as unestablished (TweakTown).

One more data point deserves a flag. One secondary blog says that after curl's bounty ended the slop stopped, and that the confirmed rate later recovered once curl was back on HackerOne, even as report volume grew (xhack.io). The specific figures come only from that blog and aren't confirmed by a primary source, so I'm not repeating them. But if the direction is even roughly right, it changes the lesson: the problem moves from junk filtering to review capacity. Filtering out garbage doesn't help if the remaining real reports still outnumber the humans who can review them.

Why this is your problem too

You don't run a bug bounty. But the mechanics generalize to any channel where three things are true:

1. Submitting is nearly free. An LLM can generate a plausible report, lead inquiry, or support ticket in seconds.
2. There's some payoff for the submitter. A bounty, a free quote, a backlink, a refund, a sales conversation.
3. Validation is expensive. A human must read, reproduce, or research before knowing whether it's real.

When submission cost drops toward zero and validation cost stays flat, the queue fills with plausible-looking junk. For a solopreneur that looks like:

• A contact form that now gets dozens of "partnership proposals" written by a script.
• An invoice inbox full of look-alike vendor requests.
• A job-application or freelancer-pitch inbox where every cover letter is fluent and none is specific.
• A public GitHub repo whose issues tab is full of confident, wrong reports.
• Review or testimonial requests, RFP responses, or affiliate applications.

Google's response teaches the right order of operations: don't try to detect AI. Detect missing evidence.

Build a triage pipeline: gate, score, route

Detecting "was this written by an AI?" is a losing game. Detectors are unreliable, and as curl's case shows, the issue isn't authorship, it's quality and incentive. Instead, require checkable evidence, score what arrives, and route by score. Here's a design I'd actually ship.

Layer 1: Cheap deterministic gates (no model call)

Before spending a token, reject what fails structural checks. Google's OT0/OT1 rule is the template: no reproduction, no review.

import re
from dataclasses import dataclass

@dataclass
class Submission:
    title: str
    body: str
    repro_steps: str
    affected_version: str
    attachments: list

def hard_gate(s: Submission) -> tuple[bool, str]:
    if len(s.repro_steps.strip()) < 80:
        return False, "missing_repro"
    if not re.search(r"\d+\.\d+", s.affected_version):
        return False, "no_version"
    if not s.attachments and "```" not in s.body:
        return False, "no_artifact"  # no log, PoC, or code excerpt
    return True, "ok"

Return an auto-reply that tells the submitter exactly what's missing. Honest submitters fix it. Scripts don't.

Layer 2: Verify claims against ground truth

The hallucinated-trigger-details problem Google described is checkable. If a report cites a function, file, or version, confirm it exists.

import subprocess

def claim_exists(repo_path: str, symbol: str) -> bool:
    out = subprocess.run(
        ["git", "-C", repo_path, "grep", "-n", symbol],
        capture_output=True, text=True
    )
    return bool(out.stdout.strip())

If a report says "buffer overflow in parse_header_v3()" and that symbol doesn't exist in your repo, that's a near-certain reject, with no model judgment needed. The same idea applies outside security: a vendor invoice referencing a PO number you never issued, or a lead citing a product you don't sell.

Layer 3: LLM scoring with a rubric, not a vibe

For what survives, use a model to score against explicit criteria and return structured output. Keep the rubric aligned with Google's two failure modes: fabricated detail, and real-but-negligible impact.

{
  "reproducible_from_text": 0,
  "claims_verified_against_source": 0,
  "reachable_code_path": 0,
  "impact_stated_and_plausible": 0,
  "duplicate_of": null,
  "recommended_route": "reject | needs_info | human_review | fast_track",
  "reasoning": "one paragraph, cites specific lines from the submission"
}

Two rules I follow: the model must quote the submission to justify a score (no free-floating verdicts), and the model never auto-closes anything above a threshold. It only reorders the queue.

Layer 4: Route by score and sender history

Sender reputation is the cheapest signal you aren't using. Track per-sender history of accepted vs. rejected submissions and let it move people between lanes. Treat a new sender's first submission with a stricter gate and a repeat contributor's with a lighter one.

Layer 5: Measure review capacity, not just the junk rate

The curl follow-up (if accurate) is the warning: you can succeed at filtering and still drown. Log three numbers weekly:

• Intake volume by route.
• Precision of the high-score lane (what fraction of "human review" items turned out real).
• Reviewer hours per accepted item.

If precision is high but hours-per-item is climbing, your bottleneck is humans, not filters, and the fix is more capacity or a harder gate, not a smarter model.

Decide what to do with the incentive, too

Filtering treats the symptom. Stenberg's argument was about incentives, and Google's tiering shows the same instinct: it stopped paying for the lowest-value report types while keeping rewards where proof is verifiable.

Questions to ask about your own channel:

• Does the submitter get anything for being wrong? Free quote, free audit, free sample? Gate those behind a short qualifying question that a script can't answer from a template.
• Can you make evidence the entry fee? Google's "exact OSS-Fuzz reproduction or merged patch" is a proof-of-work for reports. Your equivalent might be a project budget range, a screenshot, an order number, or a link to the existing thing they're writing about.
• Can you tier by stakes? Google applies its strictest rules to flagship projects and withdrew rewards for low-priority ones. Not every inbox deserves the same service level.
• Do you need to be open at all? Sometimes the honest answer is Google's: close the channel and point people to a better one. Google pointed researchers to the Patch Rewards Program and Cloud VRP, which are narrower, higher-signal doors.

What we don't know yet

Be skeptical of confident predictions. Google committed only to "an update" in Q1 2027, not to a reopening date, and not to any specific design. Commentary suggesting it will add automated pre-triage, rate limits, or mandatory proof-of-concept requirements is speculation from analysts, not a Google statement. Several other claims circulating about platform-wide freezes and submission caps at other programs came from single or aggregator sources that I couldn't confirm against primary reporting, so I've left them out.

What we can say with reasonable confidence: three well-documented organizations (Google, curl, and the Linux kernel's security list, per the sources above) found their intake channels strained by low-quality submissions, and each responded by raising the cost of submitting, lowering the reward, or closing the door. That's the pattern to learn from, regardless of how the OSS VRP eventually reopens.

How BizFlowAI approaches this

The bug bounty story is a high-profile version of a problem we build for routinely: high-volume inbound where most items are low-value and a few are important. The shape described above is the one I'd use: deterministic gates first, verification of claims against a source of truth, rubric-based model scoring with quoted justification, and routing by score and sender history, with humans reviewing only the lane that earns their time. To be clear about scope, none of the sources suggest Google or curl used a pipeline like this; this is a design approach applied to inboxes like lead forms, invoices, support queues, and application intake.

If you're drowning in low-quality inbound and want to see what a filtering pipeline would look like for your specific channel, get in touch and we can map it out together: what to gate, what to verify, what to score, and where a human should stay in the loop.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.