Google Cloud raises top bug bounty to USD $250,000

Google Cloud has introduced a new top reward of USD $250,000 in its vulnerability rewards programme for what it calls "Root-in-Cloud" findings.

The tier targets security researchers who can demonstrate full administrative control over arbitrary Google Cloud organisations or projects without prior access or special project setup. Qualifying exploit paths must not rely on leaked, phished or stolen credentials, user interaction, social engineering or an existing foothold in a victim project.

The move lifts the top end of payouts for cloud security research as large technology groups deal with heavier volumes of vulnerability submissions. Automation tools have increased the number of reports sent to Google Cloud's programme, although the number of valid vulnerability reports has remained stable over the past 18 months.

Google Cloud has also set technical rules for validating claims designed to avoid affecting production systems. Researchers seeking the top reward must use a designated service account and provide cryptographic proof of unauthorised access rather than test against customer projects.

Reports showing remote code execution in Google production infrastructure, known internally as Borg, or achieving what Google describes as root-in-prod, will also be reviewed for eligibility under the Root-in-Cloud tier. Researchers must stop probing immediately if they achieve execution in Borg. Escalation, credential extraction and lateral movement are prohibited.

Chris Betz, Chief Information Security Officer at Google Cloud, said the change reflects a shift in how security research is carried out. Google Cloud is trying to encourage work on tenant-isolation bypasses and cross-service logic flaws, which are harder to identify through automated scanning alone.

Michael Cote, Vulnerability Rewards Programme Lead at Google Cloud, said the new tier reflects changes in the research landscape.

"This is a recognition of how the field of security research has changed over the past year. We value quality submissions from anyone, and we've seen that the combination of human creativity and agentic power is much richer than either on its own. While automated scanners generate a high volume of low-impact noise, first-time researchers who pair human intuition with agentic tools are finding, on average, more interesting bugs than novices did two years ago. With the new Root-in-Cloud tier, we want to challenge the community and increasingly reward the complex, high-impact findings - like tenant-isolation bypasses and cross-service logic flaws - that require deep architectural intuition alongside agentic tools, because getting that information is essential to protecting our customers," Cote said.

His comments point to a broader issue for software and cloud providers: more submissions, more noise and more pressure on triage teams. According to Cote, automation has widened access to vulnerability discovery and lowered the barrier to entry for newer researchers, but it has also increased the total number of reports requiring review.

"It has transformed our intake volume, though not in the way many people assume. While the number of valid vulnerability reports submitted to the Google Cloud VRP has remained stable over the last 18 months, the total number of reports has grown tremendously. Automation has helped democratize vulnerability discovery, and the barrier to entry has been rapidly flattening, something even our top researchers noted at Escal8. Because we're seeing more researchers and more first-timers with interesting bugs, that creates pressure on more experienced researchers to move faster and bring more impactful findings - although their experience continues to be a key differentiator in success," Cote said.

Disclosure pressure

Google Cloud also used the announcement to warn about the risks of rushed public disclosure. Cote said pressure to publish first may encourage researchers or security firms to release details of unmitigated flaws before vendors have had time to address them, increasing risk for users.

He pointed to a broader trend in which newly public vulnerability details can be turned into working exploits more quickly. That, in turn, increases the importance of coordinated disclosure and faster remediation once vulnerabilities are made public.

"That shared commitment to making the world more secure is still the heart of this community, which is why the pressure to move faster is something we have to watch closely. As our GTIG colleagues found, the sharpest rise in the number of exploited vulnerabilities comes from n-days, not zero-days. Open source accounts have suggested that threat actors are using LLMs to rapidly turn newly-public vulnerability details into working exploits. When triage teams are already working through a surge in report volume, disclosing an unmitigated vulnerability well ahead of the standard 90-day coordinated disclosure window gives attackers the exact knowledge and time window they need to target customers, Cote said."

"With the influx of new submissions, I worry about a growing pressure to rush to publish. Something that concerns me because we're already seeing early indications of it. Because LLMs lower the barrier to finding bugs in source-available software, researchers worry that waiting to verify risks will allow someone else to be first to publish. Even more concerning, that same competitive pressure can tempt even established security companies to disclose unmitigated vulnerabilities without coordination, and that rush puts our users directly at risk. Project Zero helped establish the industry's 90-plus-30-day responsible disclosure policy, and autonomous detection and exploitation capabilities make following coordinated disclosure more important than ever. In the long run, rushing to be first works against a security company's own self-interest. Novel discoveries may bring temporary visibility, but customers will ultimately choose not to work with organizations that put them and the broader ecosystem at risk," 

For corporate security leaders, Cote said the growth of agent-generated submissions means triage systems must distinguish between plausible but incorrect reports and genuine flaws. He also said remediation timelines should shrink once a vulnerability is public, because automated exploitation is shortening the gap between disclosure and attack.

"First, prepare your vulnerability triage workflows for agent-generated submissions. To keep valid reports from getting stuck in a backlog, security teams need ways to separate plausible-sounding hallucinations from real security risks. Second, compress your remediation timelines once a vulnerability becomes public. Defensive patching and mitigations have to move faster because autonomous technology compresses the time from disclosure to working exploits. Finally, hold your security partners and vendors to high standards of coordinated disclosure. It's important that our industry continues to normalize agentic vulnerability research, but we must do so responsibly. Let's continue to keep user safety at the center of everything we do," Cote said.