AI Slop Broke the Bug Bounty: Why Google Froze Its Open-Source Rewards and What It Means for Software Security

For more than a decade, the global cybersecurity ecosystem operated on an implicit economic bargain: software companies put bounties on vulnerabilities, independent researchers hunted for flaws, and financial rewards bridged the gap between altruism and commercial exploitation. Platforms like HackerOne and Bugcrowd turned responsible disclosure into a multi-million-dollar industry, while tech giants created dedicated open-source programs to safeguard public digital infrastructure. The foundation of this entire model was a simple economic premise: finding a genuine vulnerability required deep human intellect, writing an exploit proof of concept was expensive, and evaluating a submission was a manageable filter on expert human judgment.

Over the past eighteen months, generative artificial intelligence completely obliterated the arithmetic behind that bargain.

On October 1, 2026, Google quietly froze product vulnerability submissions to its flagship Open Source Software Vulnerability Rewards Program (OSS VRP). The program, which covered premier open-source initiatives including the Go programming language, Angular, Bazel, Protocol Buffers, and Fuchsia, was officially placed on hiatus until at least the first quarter of 2027. The explanation published across Google Bug Hunters and confirmed by security teams on October 5 was stark: a massive surge in automated submissions, the vast majority of which were completely invalid.

Google's freeze is not an isolated event; it is the culmination of an industry-wide collapse. In January 2026, Daniel Stenberg, creator and lead maintainer of curl, permanently eliminated the project's HackerOne bug bounty program after seven years and more than 100,000 dollars in payouts, citing a relentless deluge of AI-generated hallucinated reports that destroyed maintainer morale and threatened mental health. In mid-September 2026, Intel removed all financial rewards from its Intigriti bug bounty portal, quietly converting the program into a zero-dollar responsible disclosure inbox. Across the Linux kernel, stable maintainer Greg Kroah-Hartman reported that CVE assignments have surged past 1,500 and are heading toward 2,000 per release, driven by automated AI static analysis bots flooding triage queues with low-priority warnings and outright hallucinations.

The bug bounty economy did not fail because researchers lost skill or because software became bug-free. It broke because generative language models dropped the marginal cost of creating persuasive, technically formatted vulnerability reports to near zero, while the cost of verifying those claims remains bound to scarce, expensive human engineering time. When spam is free and verification is costly, open systems face an asymmetric tragedy of the commons.

To grasp why Google, Intel, and independent open-source maintainers are abandoning cash rewards for vulnerability reports, one must dissect the deceptive architecture of modern AI-generated security reports.

Prior to the proliferation of large language models, automated bounty spam was crude and easily identified. Security teams faced brute-force fuzzing dumps, noisy web scanner logs from automated scripts, and uncompiled garbage payloads. Junior triage staff or automated rule filters could reject ninety percent of those submissions within seconds based on syntax checks, missing crash dumps, or unparseable headers.

Generative AI inverted that dynamic by mastering the formal rhetoric of cybersecurity. A modern AI-generated report arrives with impeccable visual and structural credentials. It features an executive summary written in authoritative engineering prose, an assigned Common Vulnerability Scoring System (CVSS 3.1) metric calculated down to the decimal point, an explicit threat model detailing how an unauthenticated remote attacker could achieve remote code execution, and a step-by-step reproduction guide complete with bash snippets and mock curl requests.

Crucially, the report weaves in real code references. The language model extracts genuine function identifiers from public GitHub repositories, references actual memory management patterns in C++ or Go, and quotes recent commit hashes. To a triage analyst scanning a queue of fifty tickets before lunch, the report looks indistinguishable from a disclosure prepared by a seasoned penetration tester.

The fatal deception only emerges when an experienced systems engineer attempts to verify the claim. The cited function may exist, but it sits in an internal debugging harness that is never compiled into production binaries. The claimed buffer overflow exists in theory, but the surrounding framework sanitizes input lengths three stack frames higher. The race condition sounds plausible in isolation, but the operating system scheduler or thread lock architecture makes the described execution path physically impossible.

Triaging these phantom vulnerabilities requires an engineer to pull the branch, configure the specific build environment, read hundreds of lines of adjacent context, attempt reproduction under a debugger, and write a detailed technical rebuttal. A malicious or lazy bounty hunter can prompt an LLM to generate one hundred such tickets across ten open-source projects in five minutes for less than three dollars in API tokens. The defending engineering team must expend fifty hours of senior engineering labor to prove the tickets are baseless.

When Daniel Stenberg analyzed the final months of the curl bounty program, he observed that the historical confirmation rate—which had hovered reliably around fifteen percent for five years—plummeted below five percent in 2025. Over ninety-five percent of submissions were hallucinations or bad-faith exaggerations. When ninety-five out of every one hundred tickets represent wasted effort, a bounty program stops functioning as a security shield and transforms into a distributed denial-of-service attack on developer cognition.

Google's Open Source Software Vulnerability Rewards Program was not an afterthought; it was the crown jewel of big-tech open-source support. Launched in August 2022 under the bughunters.google.com umbrella, the OSS VRP offered tiered payouts ranging from 100 dollars up to 31,337 dollars for critical vulnerabilities affecting Google-owned open-source repositories and their core dependencies.

The program was designed to solve a well-known systemic vulnerability in modern digital infrastructure: commercial cloud giants rely heavily on open-source codebases, yet the developers maintaining those codebases often lack institutional security backing. By subsidizing external auditing on projects like Golang, Angular, Bazel, and Fuchsia, Google provided a viable economic incentive for elite researchers to inspect the bedrock of cloud computing.

The operational reality of that program unraveled throughout 2026. On October 1, 2026, Google Bug Hunters quietly revised the official OSS VRP rules and issued a public notice on its communication channels:

• Product Vulnerabilities Paused: Google officially halted all product vulnerability submissions for the OSS VRP until at least the first quarter of 2027.
• Scope of the Suspension: The freeze specifically targets bug reports against the software code of Go, Angular, Bazel, Protocol Buffers, and related repositories.
• Preserved Ingestion Paths: Google kept open its supply chain vulnerability track, which compensates researchers up to 31,337 dollars for discovering repository credential leaks, build pipeline tampering, and continuous integration exploits.
• Cloud and Corporate Boundaries: Vulnerabilities affecting Google Cloud infrastructure repositories or Alphabet corporate web properties remain active under their respective, separate VRP guidelines.
• Grandfathered Reports: Product vulnerability tickets logged prior to the October 1 cutoff date will be honored, triaged, and paid according to legacy reward schedules.

The official justification was unequivocal: Google cited a significant rise in automated submissions, the vast majority of which are not valid. While Google possesses some of the most advanced automated security filtering and static analysis tooling on the planet, its systems could not sustainably absorb the tidal wave of synthetic, plausible-sounding hallucinated reports without degrading the core engineering teams responsible for maintaining Go and Angular.

The collapse of manual triage under automated pressure is not confined to userspace runtimes and web application frameworks. The operating system kernel that runs the modern world is experiencing an identical structural crisis.

At the Kernel Recipes 2026 technical conference, Linux stable branch maintainer Greg Kroah-Hartman presented data that sent shockwaves through the systems engineering community. Historically, through the long tenure of the Linux 6.x series, the kernel project assigned and resolved approximately 500 Common Vulnerabilities and Exposures (CVEs) per stable release.

Beginning in early 2026, that metric decoupled from reality:

• Linux 7.0: Surpassed 1,000 CVEs assigned in a single release cycle.
• Linux 7.2: Exceeded 1,500 CVEs per release cycle.
• Linux 7.3 Projections: On track to approach or exceed 2,000 CVEs per release cycle.

This exponential increase did not happen because kernel code suddenly degraded in quality, nor did it indicate that Linux became four times more vulnerable overnight. It happened because automated AI agents, script-driven static analysis engines, and commercial vulnerability brokers began indiscriminately scanning the kernel's 40-million-line codebase.

Over 35 years of continuous development, the Linux kernel has absorbed support for thousands of legacy architectures, discontinued peripheral standards, and esoteric enterprise bus drivers. Millions of lines of C code exist solely to support industrial hardware manufactured in the late 1990s. When an AI static analysis tool parses these dusty, rarely exercised drivers, it inevitably flags hundreds of missing null-pointer checks, theoretical race conditions, and unusual memory boundary states.

A fraction of these discoveries represent real issues. In 2026, several Linux CVE records explicitly credited AI-assisted static analysis tools for uncovering subtle memory synchronization flaws that were subsequently verified and patched by Intel Product Security engineers. But the overwhelming majority of automated findings are harmless code quirks, unreachable error paths, or cosmetic defects elevated to critical status by automated scoring algorithms.

Because the Linux kernel project chose to become its own CVE Numbering Authority (CNA) to prevent commercial security vendors from sensationalizing unpatched bugs, maintainers adopted a policy of assigning CVEs to virtually every bug fix that touches kernel memory. When combined with automated AI scanners, this policy created an unsustainable feedback loop. Maintainers are drowning in an administrative quagmire, forced to arbitrate whether an AI-flagged pointer anomaly in an unmaintained sound card driver warrants an emergency security advisory.

The human cost is severe. As Kroah-Hartman noted, the maintainer corps is running on empty. Senior kernel developers are burning out not from writing code or solving hard concurrency puzzles, but from spending their evenings debunking automated slop generated by opportunists seeking a CVE badge for their resumes.

When developers spend their cognitive bandwidth reviewing bad-faith vulnerability reports, core infrastructural maintenance stalls. Security fixes for high-impact subsystems compete for attention against hundreds of automated reports claiming theoretical integer overflows in uncompiled architectures. The open-source commons becomes congested, sluggish, and vulnerable to burnout.

While Google paused its open-source bounty program to re-evaluate guidelines, hardware giant Intel took an even more decisive step by quietly closing the cash spigot entirely.

For nearly a decade, Intel operated one of the most prominent hardware vulnerability reward programs in the technology industry. Hosted on the European bug bounty platform Intigriti, Intel's program offered rewards scaling from 500 dollars for minor issues up to 100,000 dollars for critical microarchitectural, firmware, and hypervisor vulnerabilities.

The program was widely considered a structural pillar of hardware security. In 2020, Intel publicly reported that 105 out of 231 CVEs addressed across its entire product catalog—nearly half of all security fixes—originated through external researcher disclosures. Between late 2024 and October 2025, Intel expanded the program's scope to encompass cloud services and open-source platform software.

Yet in mid-September 2026, visitors to Intel's Intigriti portal discovered that the bounty board was listed as suspended. In its place, Intel launched a new vulnerability reporting track with a critical modification: the financial reward table was completely erased.

The new program terms stated unambiguously: this is a responsible disclosure program without bounties. While researchers retain a secure channel to report hardware flaws, firmware backdoors, and cryptographic bugs, Intel no longer offers monetary compensation of any kind.

Intel provided no official post-mortem explaining the policy change. However, security researchers close to the triage operations noted that the program had been paralyzed by thousands of speculative microarchitectural speculation reports, automated fuzzing traces, and unverified AI prompt chains claiming theoretical side-channel leaks. Rather than continuing to spend millions of dollars funding triage teams to review synthetic submissions, Intel chose to dismantle the financial magnet entirely.

When Intel and Google retreat from paying cash for product vulnerability write-ups within weeks of each other, it signals that the voluntary, crowdsourced bug bounty model has crossed its point of economic sustainability.

If paying cash for vulnerability write-ups generates unsustainable noise, what replaces the traditional bug bounty? The emerging consensus across open-source leadership is a structural pivot: stop paying for bug claims, and start paying exclusively for verified, merged code fixes.

In the same update where Google announced the freeze of product vulnerability rewards, the company delivered a pointed recommendation to security researchers: redirect effort toward the Google Patch Rewards Program.

The Patch Rewards initiative represents a diametrically opposed economic framework:

• No Speculative Write-ups: Researchers cannot submit theoretical vulnerabilities, speculative attack trees, or unvalidated reproduction steps to claim a reward.
• Compensation for Pull Requests: Google awards bounties ranging up to 15,000 dollars for merged, production-grade security patches and proactive hardening improvements submitted directly to open-source repositories.
• Memory Safety Focus: To encourage systematic eradication of vulnerability classes, Google provides significant reward multipliers for contributions that transition critical components to memory-safe languages like Rust or implement comprehensive fuzzing harnesses via OSS-Fuzz.

The fundamental genius of the patch reward model lies in its ability to leverage existing software engineering automation to neutralize AI spam:

Vulnerability Report Workflow (Broken by AI):
[Researcher / AI Tool] → [Plausible Bug Claim] → [Human Triage Engineer]
• Cost to Generate: $0.02
• Cost to Triage: $150.00 (Human Time)
• Result: Systemic Denial-of-Service

Patch Reward Workflow (Protected by CI/CD):
[Contributor / AI Tool] → [Pull Request with Patch] → [Automated CI Pipeline]
• CI Pipeline executes 200 build targets, unit tests, and linters automatically.
• Hallucinated code fails compilation instantly; human attention is never consumed.
• Merged Patch → [Human Review only after tests pass] → [Reward Issued]

When a contributor submits a pull request to curl, Go, or the Linux kernel, the submission does not enter a human triage queue in isolation. It immediately enters a continuous integration pipeline. The code is compiled across multiple operating systems, parsed by deterministic static linters, subjected to regression suites, and tested against memory sanitizers.

If an AI tool generates a hallucinated patch containing non-existent APIs, invalid type conversions, or broken memory semantics, the pull request fails CI within three minutes. Human maintainers never read the submission. The automated gatekeeper filters out the synthetic garbage before a single minute of human cognitive bandwidth is wasted.

The retrenchment of Google, Intel, and curl does not mean open-source software is descending into insecurity. Rather, it marks the end of an uncritical, romantic era where software security was outsourced to an unregulated, anonymous global gig economy.

As the industry looks toward 2027 and beyond, the security architecture of the open commons is undergoing four decisive transformations:

First, identity verification and reputation gating will become universal requirements for vulnerability disclosure. Anonymous handles and freshly registered accounts will no longer be permitted to submit unsolicited vulnerability reports with cash expectations. Platforms will require cryptographic identity verification, verified corporate affiliation, or progressive staking models where submitters must establish a track record of valid contributions before their tickets reach human analysts.

Second, the open-source community will establish explicit, enforceable boundaries against unverified synthetic submissions. Projects will update their security policies to state clearly that submitting AI-generated reports without independent human verification constitutes bad-faith disruption, resulting in immediate domain-level bans and public blacklisting.

Third, funding will concentrate around automated, continuous verification infrastructure. Rather than paying bounty hunters to find individual buffer overflows, resources are shifting toward deterministic testing systems like Google's OSS-Fuzz, automated formal verification engines, and compiler-level memory safety enforcement. Eliminating an entire class of vulnerabilities at the language level—such as adopting memory-safe languages for new systems programming—delivers infinitely higher returns on investment than paying bounties on thousands of individual pointer flaws.

Finally, corporate consumers of open-source software must embrace direct maintainer compensation. For twenty years, multitrillion-dollar technology enterprises extracted billions of dollars in economic value from open-source libraries maintained by unpaid volunteers working on weekends. The bug bounty was often an inexpensive public relations surrogate for real responsibility: tossing a few thousand dollars at an external researcher while doing nothing to fund the daily maintenance of the underlying repository.

When Google froze product vulnerability intake on the OSS VRP, it delivered a definitive verdict on the limits of crowdsourcing in an era of synthetic generation. The automated slop that broke the bounty desk was not an accident; it was the inevitable consequence of an economic model that incentivized claims over code. By closing the door on speculative noise and paying for constructive engineering, the software industry can protect the sanity of its maintainers, defend the integrity of open-source infrastructure, and build an internet secured by real engineering rather than automated illusions.

Sources: Google Bug Hunters OSS VRP Rules and Announcements (bughunters.google.com), Daniel Stenberg's curl project disclosures (daniel.haxx.se), Kernel Recipes 2026 Proceedings and LKML telemetry (phoronix.com), Intel Product Security Documentation on Intigriti, and The Verge industry reporting (theverge.com).