Rising Automated Submissions Strain Vulnerability Triage

Key Takeaways

Google stopped accepting new product vulnerability submissions to its Open Source Software Vulnerability Rewards Program (OSS VRP) on October 1, 2026, citing “a significant rise in automated submissions, the vast majority of which are not valid” [1][2]. The pause is a prominent example of organizations withdrawing from paid external vulnerability reporting, following curl’s end of its bug bounty in January 2026 [3] and Intel’s reported suspension of its paid bounty in September 2026, for which no reason was stated [4]. Google and curl both attribute their decisions to low-quality, largely automated submissions, which is consistent with a cost asymmetry between producing and validating reports: AI makes a plausible report nearly free to produce, while validating one still costs a human reviewer real time.

For enterprises, the immediate issue is not Google’s program in isolation. Disclosure channels for open-source components are a shared dependency, and when they degrade, real vulnerabilities in widely used code may be reported later, triaged more slowly, or not reported at all through paid channels. Organizations that consume open-source software should assume that the volume of AI-discovered findings will continue to outpace maintainer capacity, a gap CSA has already documented on the patching side [5], and should plan to contribute capacity rather than only consume it.

Background

Google launched the OSS VRP in August 2022 to reward researchers for vulnerabilities in the company’s open-source projects, including Go, Angular and Protocol Buffers. Rewards ranged from $100 to $31,337 depending on severity and project importance [1]. According to Google’s announcement as relayed by trade press, the pause applies to new product vulnerability submissions made on or after October 1, 2026. Reports submitted earlier continue to be processed, and OSS VRP supply-chain submissions remain open [1]. Google has told researchers to use its other programs, such as the Cloud VRP, or the Patch Rewards Program instead, and has said it will provide an update on a reformatted program in the first quarter of 2027 [1][2][6].

The pause did not arrive in isolation. Daniel Stenberg, lead maintainer of curl, announced in January 2026 that the project would end its HackerOne bug bounty at the end of that month. He described the goal as removing “the incentive for people to submit crap and non-well researched reports,” whether AI-generated or not [3]. Press accounts of that decision reported that none of the roughly twenty submissions received in January had identified a vulnerability, and that the reports put a high load on the curl security team [3]. The project began accepting reports through GitHub from February 1, 2026 [3]. Stenberg later wrote that the project took the whole of July 2026 off from accepting vulnerability reports and described the result as possibly “our best project decision in a long while” [7]. Intel’s paid bounty on the Intigriti platform was reported in September 2026 to have been replaced by a responsible-disclosure program without rewards. Intel gave no stated reason, so any link to AI-generated submissions is an inference by commentators rather than a reported fact [4].

A caution on the numbers is warranted. Secondary reports of curl’s historic payouts and confirmed vulnerability counts differ from one another, and this note therefore does not rely on them. Google likewise has not published the number of submissions or the share it judged invalid; “vast majority” is its only characterization in the sources reviewed. All Google facts in this note rest on trade press rather than a primary Google announcement, and the Intel account rests on a single secondary source.

Security Analysis

The Asymmetry Behind the Pause

The underlying problem appears to be a cost asymmetry. A language model can draft a report with a plausible description, a code excerpt and a severity rating in seconds, and a bounty program that pays per valid finding may give a participant a small expected payoff for each attempt. Verifying that report requires someone who understands the code to reproduce the behavior, determine reachability, and decide whether it crosses a trust boundary. Reporting on curl indicates that this verification step is where the cost lands, on a small volunteer security team [3]. The situation resembles a resource-exhaustion attack in structure: the submitter’s cost per attempt is close to zero and the reviewer’s is not. Submitters need not be adversarial for this dynamic to hold, since well-meaning automation can saturate a queue as effectively as a hostile actor.

Paid programs may sharpen the problem because they attach a financial incentive to volume. Stenberg’s stated rationale for ending curl’s bounty was to remove that incentive [3]. Google’s pause targets the same dynamic, although the company has said only that submissions were automated and mostly invalid, not why they were being sent. It is reasonable to infer that reward-seeking is one driver, but the sources reviewed do not establish this.

A Distinct Failure Mode from the Patching Gap

CSA’s analysis of Project Glasswing described one side of the AI-era disclosure imbalance: capable models find vulnerabilities faster than open-source maintainers can fix them, with only 97 of 1,596 findings disclosed to maintainers reported as patched as of that note’s June 7, 2026 publication [5]. The OSS VRP pause illustrates a second and different side. Here the problem is not that AI finds too many real bugs, but that it generates too many unverified claims, and the sorting of true from false is itself a scarce maintainer resource. The two problems may compound one another. If triage capacity is consumed by invalid reports, the high-quality AI-assisted findings that Glasswing-style efforts produce could be delayed in the same queue, and the incentive for maintainers to engage with any inbound report could decline. The sources reviewed do not show whether this has occurred.

This also suggests why the signal-to-noise problem is hard to solve by simply tightening submission rules. Legitimate AI-assisted researchers and low-effort submitters use similar tools and may produce reports with similar surface features. Filtering on whether AI was used would penalize the former group, while filtering on proof of exploitability shifts the burden onto submitters, an approach some programs are adopting.

Implications for Enterprises and Open-Source Consumers

Three consequences follow for organizations that depend on open-source code. First, the number of channels through which a vulnerability in a Google-maintained project can reach a paid researcher has narrowed, and researchers with real findings may route them elsewhere, disclose publicly, or hold them. Reporting to date does not show whether this has happened, so it should be treated as a risk to monitor, not an observed outcome. Second, if more programs follow, a researcher’s choice of where to send a finding becomes less predictable, and enterprises relying on vendor advisories for early warning may see gaps. Third, Google has kept supply-chain submissions open [1]. Google has not said whether this reflects a shift in priority toward fixes; the pattern is consistent with that reading but does not establish it.

The following table summarizes the three cases reviewed and what each did and did not disclose.

Recommendations

Immediate Actions

Security teams should inventory which of their critical open-source dependencies rely on Google-run or similar paid disclosure channels, and identify an alternate path for reporting a finding in each, such as a security contact address, coordinated disclosure through a CNA, or the repository’s private advisory feature. Teams that run their own AI-assisted code review should confirm that anything they report upstream has been manually reproduced first, with a minimal proof of concept, since unreviewed model output is the content now straining maintainers. Organizations that receive external vulnerability reports through their own programs should check their current triage backlog and the share of reports that are invalid, so that they have a baseline before volume rises.

Short-Term Mitigations

Organizations that operate bounty or disclosure programs should consider requiring reproducible evidence at submission, limiting submissions by new accounts, and charging reputation or deposits for repeated invalid reports, while recognizing that each measure has trade-offs for legitimate researchers. Programs can also separate the reward channel from the intake channel, as curl did by moving to unpaid GitHub reporting [3], so that the incentive to submit speculative reports is reduced without closing the path for real ones. Where AI is used to pre-screen incoming reports, a human should confirm any rejection of a high-severity claim, because automated filtering errors would then silently discard genuine findings.

Strategic Considerations

Beneficiaries of open-source software have a structural interest in funding triage capacity, not only patch capacity. Enterprises that depend on a project can offer security engineering time, sponsor maintainers, or underwrite shared triage services, consistent with the recommendation in CSA’s Glasswing analysis to support maintainer infrastructure [5]. Over time, disclosure ecosystems may need standard machine-readable evidence formats, verified-researcher identity tiers, and shared triage services across projects. These are proposals for the community to evaluate and are not yet established practice. Finally, security leaders should treat vulnerability-intake channels as capacity-limited infrastructure, with the same resilience planning applied to other services that adversaries or well-meaning automation can saturate, for example intake rate limits and published response-time targets.

CSA Resource Alignment

CSA’s research note Project Glasswing: AI Discovery Outpaces Open Source Patching Capacity [5] is the most directly related published work. It documents the discovery-to-remediation gap that results when AI-assisted discovery outruns open-source maintainer capacity, and it recommends direct maintainer communication channels and investment in maintainer infrastructure. The OSS VRP pause adds the intake side of the same problem: even before a finding reaches a patch queue, the triage step is constrained, and the two constraints compete for the same people.

CSA’s AI Controls Matrix v1.1 (AICM) [8] provides the control framing for the enterprise response, particularly its threat and vulnerability management (TVM) and application and interface security (AIS) domains, which apply to how an organization receives, validates and acts on vulnerability information about its AI and software supply chain. Organizations operating their own disclosure programs can use those domains to assess whether triage capacity, evidence requirements and escalation paths are documented and resourced.

CSA has also published related work on coordinated disclosure and patch velocity in the AI era [9][10] and the broader “Vulnpocalypse” analysis [11], which address the policy and enterprise-response dimensions of the same trend. Readers interested in national and international coordination can consult these publications directly.

References

[1] Bleeping Computer. “Google halts open-source bug bounty program amid AI spam surge.” Bleeping Computer, October 5, 2026.

[2] Infosecurity Magazine. “Google Suspends Open-Source Bug Bounty Due to AI Vulnerability Reports.” Infosecurity Magazine, October 5, 2026.

[3] Bleeping Computer. “curl ending bug bounty program after flood of AI slop reports.” Bleeping Computer, January 22, 2026.

[4] Privacy Savvy. “Intel Suspends $100,000 Security Bug Bounty Program Amid AI-Generated Report Surge.” Privacy Savvy, September 22, 2026.

[5] Cloud Security Alliance. “Project Glasswing: AI Discovery Outpaces Open Source Patching Capacity.” CSA, June 7, 2026.

[6] Help Net Security. “AI slop submissions force Google to freeze its open-source bug bounty.” Help Net Security, October 5, 2026.

[7] Stenberg, Daniel. “What the bliss taught us.” daniel.haxx.se, August 3, 2026.

[8] Cloud Security Alliance. “AI Controls Matrix v1.1.” CSA, June 22, 2026.

[9] Cloud Security Alliance. “AI-Era Vulnerability Disclosure: Coordinated Patch Velocity Frameworks.” CSA, 2026.

[10] Cloud Security Alliance. “Enterprise Patch Velocity Under AI-Accelerated Vulnerability Discovery.” CSA, 2026.

[11] Cloud Security Alliance. “The Vulnpocalypse: AI-Accelerated Vulnerability Discovery and Defense.” CSA, 2026.