Google paid a record $17.1M in bug bounties in 2025, and started paying for AI flaws
Google's VRP paid over $17M to 747 researchers in 2025, up 40%+, with a $250K top award, a standalone AI VRP and OSV-SCALIBR rewards. What changed for hunters.
Google's Vulnerability Reward Program (VRP) paid out more than $17 million in 2025, a record and an increase of over 40% on 2024. The money went to 747 researchers. Besides the headline figure, the year marked a shift in what Google is paying for: AI features now have their own reward program, and open-source tooling is getting dedicated bounties. Both matter if you build on Google platforms or hunt bugs yourself.
What happened
In its 2025 year-in-review, Google said the VRP awarded over $17 million (shown as $17.1 million) to 747 researchers. The largest single reward was $250,000. Since the program launched in 2010, Google says it has paid out $81.6 million.
BleepingComputer reported a breakdown by program from Google's 2025 results:
- Android and Google Devices Security Reward Program: over $2.9 million.
- Chrome VRP: $3,716,750 to more than 100 reporters.
- Cloud VRP (its first full year): $3,574,399 to 143 researchers.
Google also ran live "bugSWAT" hacking events. These included an AI-focused event in Tokyo (70+ reports, over $400,000), a Cloud event in Sunnyvale (130 reports, $1.6 million), and events in Las Vegas and Mexico.
Several program changes stood out in 2025:
- A standalone AI VRP, split out of the Abuse VRP, covering security and abuse issues in Google's AI products.
- New Chrome VRP categories for bugs in Chrome's AI features.
- An OSV-SCALIBR patch rewards program that pays for new plugins for Google's open-source software composition and vulnerability scanning library.
For comparison, Google paid nearly $12 million to 660 researchers in 2024.
Who is affected
- Security researchers and bug hunters, who have more in-scope surface, especially AI features and Google Cloud.
- Teams building on Chrome, Android and Google Cloud, whose platforms get a large amount of external testing. Many of the bugs fixed affect shared components such as V8, Skia and the Android kernel that other software also relies on.
- Open-source maintainers in the dependency-scanning ecosystem, through the OSV-SCALIBR rewards.
What it means for developers and engineering teams
Bug bounty totals are a rough signal of where vendors expect risk. Two trends stand out.
First, AI features are now treated as normal attack surface. Google giving AI its own VRP, with defined categories for issues such as prompt injection that leads to data exfiltration or unauthorised actions, makes "the model did something it shouldn't" a reportable, payable security bug rather than a quality complaint. If you ship LLM features, use the same framing: define what counts as a security failure (for example, an indirect prompt injection that triggers a tool call, or a cross-user data leak) and test for it.
Second, Cloud payouts almost matching Chrome's reflects how many critical bugs now sit in multi-tenant control planes and IAM logic rather than in memory-unsafe client code. Researchers are spending time on authorisation boundaries, which is where SaaS backends also tend to be weak.
For smaller companies the takeaway is not to copy Google's budget. It is that a clear scope, fast triage and published rules attract useful reports. A security.txt file and a vulnerability disclosure policy cost almost nothing.
There is also a supply-chain angle. Many high-value Chrome and Android reports land in shared open-source components such as V8, Skia, ANGLE, the Linux kernel and media codecs. A fix there flows downstream to every project that vendors those components, but only after the downstream project ships an update. Bounty-driven discoveries in Google products often become patch obligations for teams that never heard of the original report, which is why tracking upstream security releases matters as much as tracking your direct dependencies.
What to do now
- Publish a disclosure channel: add
/.well-known/security.txtwith a contact address and policy URL so researchers can reach you. - Write down AI-specific security criteria for your LLM features (prompt injection, data leakage between users, unsafe tool calls) and add them to your test plans.
- Keep Chrome-based and Android dependencies current. Many VRP fixes ship in Chromium and AOSP components that Electron, CEF and WebView-based apps bundle.
- Try OSV tooling: run
osv-scanneragainst your lockfiles in CI to catch known-vulnerable dependencies. - If you hunt bugs, read the AI VRP and Cloud VRP rules for scope and severity tables before you start testing.
Related on TechLogHub
- PromptBrake, security testing for LLM-powered API endpoints
- Depna, a dependency vulnerability scanner