Google has suspended product vulnerability reporting under its flagship Open Source Software Vulnerability Rewards Program (OSS VRP), citing an unsustainable surge in automated, artificial-intelligence-generated submissions that yielded high volumes of invalid and fabricated vulnerability claims. The operational freeze took effect on October 1, 2026, with Google’s security division confirming it will hold submissions through at least the first quarter of 2027 while it overhauls the program’s intake framework.
The suspension exposes a growing crisis within cybersecurity crowdsourcing: generative AI models have made generating professional-looking, multi-page vulnerability reports nearly frictionless, incentivizing opportunistic bounty hunters to flood triage queues with synthetic claims. Instead of discovering zero-day vulnerabilities, open-source maintainers and Google engineers found themselves spending hundreds of work hours disproving synthetic hallucinations—code snippets that referenced non-existent execution paths, fabricated memory corruption vectors, and speculative exploits that failed basic execution tests.
Key Takeaways
- Operational Pause Date: Google officially halted new product vulnerability intake under the OSS VRP on October 1, 2026, promising an update on the program’s operational restructuring in Q1 2027.
- Root Cause Identified: A dramatic rise in low-effort, automated, large language model (LLM)-generated vulnerability reports, the vast majority of which proved to be invalid, speculative, or outright hallucinations.
- Specific Gating Scope: The freeze applies specifically to general open-source product vulnerability reports. Supply chain security disclosures submitted under the OSS VRP remain open, and Google Cloud VRP continues to accept product bugs directly affecting Cloud-managed repositories.
- Maintainer Exhaustion: The sheer volume of synthetic submissions depleted triage engineering bandwidth, shifting developer hours away from reviewing legitimate vulnerabilities and maintaining critical public software.
- Wider Industry Trend: Google’s decision mirrors a broader industry retreat; semiconductor giant Intel also recently froze its bug bounty program under similar automated triage pressures, signaling that the traditional open-door vulnerability submission model is breaking down under asymmetric AI generation.
The Anatomy of “AI Slop” in Vulnerability Disclosure
Bug bounty programs historically functioned on economic alignment: ethical security researchers invested specialized manual labor to identify subtle edge cases, reverse-engineer binaries, or audit complex codebases in exchange for monetary payouts. The cost of producing a report was high, naturally filtering out trivial submissions.
Generative AI inverted this economic barrier:
TRADITIONAL VULNERABILITY REPORTING (Manual)
[ Skilled Researcher ] ──(Dozens of Hours of Auditing)──> [ Verified PoC ] ──> [ Human Triage ]
(High Signal)
MODERN AI SLOP VECTOR (Asymmetric / Automated)
┌───────────────────────┐
│ Automated LLM Scraper │ ──(Runs scripts across 1,000s of repos)──┐
└───────────────────────┘ │
▼
┌───────────────────────┐ [ 10,000 Auto-Drafted ]
│ Prompt Templates: │ ──(Generates plausible markdown)──> [ "Vulnerability" ] ──> [ Overwhelmed Reviewers ]
│ "Find critical bugs" │ [ Reports ] (Near-Zero Signal,
└───────────────────────┘ Paralyzing Triage)
Amateur bounty hunters and automated bots began passing entire open-source code repositories into large language models with generic prompts instructing the model to “identify critical remote code execution (RCE) flaws” or format submissions into authoritative Common Vulnerability Scoring System (CVSS) templates.
This dynamic generates three primary categories of triage noise:
- Hallucinated Execution Paths: Models frequently misinterpret asynchronous function calls or mock test fixtures as production memory-leak vulnerabilities, constructing elaborate theoretical attack narratives around code that is never exposed to external user input.
- Fabricated Proofs of Concept (PoCs): LLMs regularly invent terminal commands, synthetic API responses, and altered payloads that appear convincing in markdown format but fail completely when run in controlled sandboxes.
- Speculative Static Analysis Spam: Scrapers flag standard programming patterns—such as unvalidated string concatenation in internal logging routines—as “high-severity injection flaws,” demanding monetary bounties without verifying whether the attack surface is reachable.
Because responsible security management requires engineers to treat every report with diligence until proven benign, verifying a single synthetic 10-page report often took triage teams 30 to 90 minutes. When multiplied by hundreds of submissions a week, the review process ground to a halt.
Google’s Gated Response: What Is Frozen and What Remains Active
In an official advisory published on its security rewards portal and social channels, Google clarified that the suspension is surgical rather than an abandonment of open-source security rewards:
| Program / Sub-Track | Current Operational Status | Operational Scope & Policies |
| OSS VRP (Product Bugs) | FROZEN (Oct 1, 2026 – Q1 2027) | Suspended for all new open-source product vulnerability filings; existing submissions filed before Oct 1 remain in process. |
| OSS VRP (Supply Chain Track) | ACTIVE | Continues accepting submissions focused on CI/CD pipelines, package registry tampering, and build-infrastructure security. |
| Google Cloud VRP | ACTIVE | Accepts product vulnerability reports tied to Google Cloud repositories that directly impact Cloud enterprise infrastructure. |
| Android / Chrome / Core VRP | ACTIVE | Flagship proprietary bounties operate under standard review tracks, governed by established platform identity verifications. |
The company emphasized that maintainers should not bear the emotional and logistical burden of arbitrating automated synthetic noise: “We are taking this time to re-evaluate our intake and evaluation processes to ensure our reviewers’ time is spent on impactful security research,” Google’s security team noted.
A Broader Industry Crisis: The Tragedy of the Security Commons
Google’s operational freeze reflects an existential challenge confronting crowdsourced security. In September 2026, chip manufacturing leader Intel temporarily paused its bug bounty program—which offered critical payouts reaching up to $100,000 per exploit—under similar automated volume pressures.
Across major platforms like HackerOne and Bugcrowd, independent triage teams have documented a 300% to 500% surge in low-quality submissions over the preceding 18 months, directly correlating with the release of increasingly sophisticated coding models.
THE ASYMMETRY OF SYNTHETIC CYBERSECURITY
GENERATION COST: ~₹10 ($0.12) in API compute
• An automated bot runs 50 prompt variants against open repositories.
• Spits out 50 formatted markdown bug reports claiming "Remote Code Execution."
TRIAGE COST: ~₹8,000 ($100+) in senior engineering labor
• Senior maintainer must pull code, spin up an isolated test container.
• Inspect execution paths, confirm inputs are sanitized by upstream libraries.
• Write an exhaustive dismissal explaining why the LLM's logic was hallucinated.
NET RESULT: Asymmetric exhaustion of open-source human capital.
For corporate programs backed by multi-trillion-dollar entities like Alphabet, the issue is primarily an allocation of engineering labor. But for open-source maintainers—many of whom work unpaid or on modest foundation stipends—the flood of synthetic reports causes severe operational burnout. When maintainers are inundated with aggressive, automated demands for bounty payouts on fictitious flaws, many opt out of public security disclosure channels entirely.
Restructuring for Q1 2027: How Bug Bounties Must Adapt
Google’s scheduled review in the first quarter of 2027 is expected to establish new operational benchmarks for how tech companies accept outside vulnerability disclosures in the post-generative AI era. Industry analysts point to several architectural reforms likely to emerge:
- Mandatory Containerized Exploits (Executable PoCs): Requiring submitters to provide a fully reproducible Docker container or continuous integration (CI) test case that actively triggers the vulnerability. A claim without an executable trigger would be automatically rejected by pre-triage bots.
- Reputation-Gated Intake: Restricting public vulnerability submissions to researchers with established track records on platforms like GitHub, OpenSSF, or verified security registries. New or anonymous submitters would be forced through stricter rate limits.
- Economic Staking or Anti-Spam Penalties: Implementing mechanisms where submitters stake reputation points—or nominal refundable processing fees—that are forfeited if an automated submission is determined to be non-actionable synthetic spam.
- AI-Driven Pre-Triage Classifiers: Deploying fine-tuned models to act as automated defensive filters, screening incoming reports for hallucinated variable names and ungrounded execution paths before a human engineer ever sees the ticket.
What Remains Uncertain
While Google’s pause provides immediate breathing room for its engineering teams, several key questions remain unanswered ahead of the 2027 review:
- The Fate of Independent Researchers: Will aggressive anti-spam measures inadvertently erect barriers that lock out genuine, junior security researchers from emerging economies—such as India, Nigeria, and Vietnam—who rely on bug bounties for their livelihood?
- Unreported Zero-Days: With the open-source front door temporarily shut, does the risk increase that genuine vulnerabilities will go unnoticed, or worse, end up sold on underground exploit markets where payouts are guaranteed?
- Open-Source Maintainer Protection: Can Google develop a shared triage toolkit that can be open-sourced to external Linux Foundation and Apache projects, which suffer from the exact same synthetic spam but lack Google’s enterprise resources to build internal defenses?
What Happens Next
Between October 2026 and March 2027, security researchers discovering potential vulnerabilities in Google-managed open-source codebases must redirect their disclosures through secondary channels, such as the Google Cloud VRP or the supply-chain security tracks, provided the criteria match.
The industry will treat Google’s upcoming Q1 2027 platform redesign as a test case. If the world’s leading search and AI company cannot build an intake system capable of separating synthetic noise from genuine security research, the era of open, crowdsourced public bug bounties may permanently shift toward closed, invitation-only security research rings.
Frequently Asked Questions
What is the Google Open Source Software Vulnerability Rewards Program (OSS VRP)?
The OSS VRP is a dedicated bug bounty program established by Google to reward independent security researchers who discover and responsibly disclose security flaws in Google’s open-source projects (such as Bazel, Angular, Golang, and related dependencies).
Why did Google pause the OSS VRP?
Google paused the program on October 1, 2026, due to an influx of low-quality, automated bug reports generated by artificial intelligence. Most of these reports contained hallucinated flaws, fabricated code execution paths, and invalid proofs of concept that overwhelmed human engineers and maintainers.
When will the program reopen?
Google has not guaranteed a full reopening in its original form, but announced it will complete a comprehensive operational review and provide an official update during the first quarter of 2027.
Are all Google bug bounty programs shut down?
No. The freeze is strictly confined to general product vulnerability submissions under the Open Source Software VRP. Flagship reward programs—including the Google Cloud VRP, Android VRP, Chrome VRP, and the OSS Supply Chain track—remain fully operational.
Get the day’s top stories in your inbox
One concise email. No spam, unsubscribe anytime.



