[HackerNotes Ep. 159] Maximizing Bounties on Google Cloud VRP

Digging into the Google Cloud VRP to get the best of it

Author

Aituglo ‎
January 29, 2026

Hacker TL;DR

  • Google Cloud VRP rewards based on "privilege escalation delta" - the gap between starting access and ending impact determines payout

  • Service account impersonation is a consistent high-value attack pattern across GCP products. Default service accounts with elevated privileges are prime targets

  • Report quality directly affects bounty: a 1.2x multiplier is available for exceptional reports, while poor quality triggers downgrade

  • Tier 1 products (Cloud Storage, GKE) pay maximum bounties, but Tier 3 products can still yield $50K+ payouts when chained properly

Join Justin at Zero Trust World in March!
Get $200 off registration with Code: ZTWCTBB26

Google Cloud VRP Structure

Google Cloud VRP operates separately from the main Google VRP, though it inherited much of the foundational process. The program launched internally in July 2024 and went public at the Malaga live hacking event in October 2024. The scope covers several hundred cloud products with varying tier classifications.

The rewards table uses a severity classification system:

S0 - Cross-tenant impact with no permissions required. "No rights to the organization" is the key qualifier, being logged into Google doesn't matter if there's no relationship to the target org. Minimum S0 payout is $7,500.

S1 - Authenticated attacks within a project or organization, subdivided by impact:

  • S1a: Complete project takeover / full administrative control

  • S1c: Multi-service privilege escalation

  • S1f: Single-service privilege escalation (least severe S1 category)

S2 - Lower impact issues that still warrant fixing. This includes metadata leaks, non-customer data exposure, and issues where exploitation is possible but impact is limited.

C0/C1 - Client-side vulnerabilities. C0 covers JavaScript execution (XSS with demonstrable impact), while C1 is a catch-all for other client-side issues. These are relatively rare in Cloud VRP submissions.

The tiering system (Tier 1, 2, 3A, 3B) multiplies against severity. Tier classification uses an internal algorithm factoring revenue, user count, API call volume, and cross-product integration. Cloud Storage is Tier 1 because it's both heavily used directly and integrated into other GCP products. Acquisitions start at IT3a and typically move to higher tiers roughly three years post-acquisition.

You can see the full reward table here: Reward Table

A gift from Google to us

Mention Critical Thinking Bug Bounty Podcast in any rewarded (cash or credit) VRP report submission before the end of April to receive bonus swag!

How to get the best out of the Google VRP program

Privilege Escalation Delta

Google internally uses "privilege escalation delta" as a core rewards metric. The delta measures the gap between starting permissions and ending access.

Starting with viewer access and ending with viewer access on another product = low delta. Starting with viewer access and achieving full project takeover = high delta.

Reports should explicitly document:

  • Starting permissions (exact role, scope)

  • Ending permissions (what you can now access/control)

  • Data types accessible after exploitation

Downgrades and Upgrades

Downgrades:

Prior Access - If the attack requires uncommon starting permissions, payout decreases.

User Interaction - Applies only when interaction goes "beyond normal usage of the affected product." If a ticketing system requires someone to click a ticket, and clicking triggers the exploit, that's expected workflow, not a downgrade scenario. But if the victim must navigate to an unusual location or enable a hidden setting, expect a reduction.

Exploitability - If only 100 customers operate in the specific state required for exploitation, the payout will be lower than if 100,000 customers are vulnerable. Google uses internal metrics to estimate affected customer population.

Uncommon Configuration - Different from exploitability. This applies when the victim's setup requires enabling features or extensions that most customers don't use. Documentation matters here: if Google's own docs recommend the configuration, cite them to counter a potential downgrade. Stack Overflow answers or popular tutorials showing the configuration can also help.

And please, stop using AI to write your reports.

Upgrades:

Novelty - Genuinely new attack patterns that Google hasn't seen.

Report Quality - A 1.2x multiplier is available for exceptional reports. The quality matrix evaluates:

  • Clear impact description

  • Effective reproduction steps

  • Root cause analysis

  • Concise technical writing

The 0.8x downgrade triggers when reports lack these elements. Google explicitly prefers concise reports over 20-page research papers. If the full research exists, include it as an attachment but keep the main report focused on what, how, and why.

Writing reports in your native language is acceptable, Google prefers that over AI-translated text that may obscure technical details.

Report Routing and Appeals

Reports are initially routed by a Level 0 triager who only determines whether the bug is Cloud-related. Cloud bugs go to the Cloud queue regardless of specifics. The Cloud panel then reviews and may route elsewhere if the issue fits better under Abuse VRP or another program.

The panel consists of security engineers, including former bug bounty researchers who actively participate in programs. Panel meetings run 60 minutes with roughly 15 bugs reviewed. Simple cases take under a minute; complex ones may exceed four minutes and get deferred.

If a report is rewarded under a different VRP and you believe Cloud should have evaluated it:

  1. Post a comment on the bug requesting re-evaluation

  2. Explicitly state which Cloud table category you believe applies

  3. Request the bug be sent to Cloud VRP panel

Product Configuration Best Practices

Cloud products require significant setup before meaningful testing. Use Terraform with Google's sample configurations to spin up instances matching common customer deployments. GKE is particularly difficult to configure correctly from scratch.

Following official documentation for setup serves dual purposes:

  1. Reduces "uncommon configuration" downgrade risk

  2. Ensures testing reflects actual customer environments

Google added a specific downgrade for "wacky configurations that we've never seen before." Even if a bug is technically valid, exploiting a configuration no real customer uses limits payout.

We do subs at $25, $10, and $5, premium subscribers get access to:

– Hackalongs: live bug bounty hacking on real programs, VODs available
– Live data streams, exploits, tools, scripts & un-redacted bug reports

Some possible bugs

Impact Demonstration for XSS

XSS on GCP console can chain to RCE on customer instances via Cloud Shell. But you have to demonstrate it. Client-side findings get categorized based on proven impact, not theoretical maximum. An XSS with a working Cloud Shell RCE POC rates higher than an XSS that merely claims the same potential.

Delivery mechanism quality also affects rating. A scenario requiring the victim to have GCP open in one tab, Gmail in another, and clicking an emailed link is weaker than exploiting an internal GCP ticketing flow where the victim is guaranteed to have appropriate permissions.

Interesting patterns found

The June 2025 Bug Swat event paid out $1.6M across 160+ reports in a five-week submission window. The highest-value findings exploited service account impersonation chains.

The pattern identifies default service accounts with elevated privileges, finds impersonation paths, and chains across services. At the Bug Swat, one researcher (Jakub Domeracki) found a missing link that elevated the impact for ~10 previously submitted reports. Multiple researchers had identified impersonation paths but couldn't prove meaningful privilege escalation. Jakup demonstrated that one specific service account could be used to impersonate a much higher-privileged account. Once proven, Google retroactively rewarded everyone who had partial chains, each with unique starting points but now demonstrably leading to real impact.

When submitting service account impersonation bugs, map the full chain. If impact seems limited, dig for the next hop.

Quick shoutout to our friend Harley Kimball (feature on ep. 133): he’s dropping a Bug Bounty Resource Guide for 2026 with some solid stuff for anyone who wants a curated list of things to read, tools to use, etc. -of course we're featured in it! =)

If you're interested, check it out here:
https://getdisclosed.com/bug-bounty-resources-2026

That's it for the week, keep hacking!

Resources