Unexpected $67k+ Gemini API spike in 19 hours — 2016 Firebase-provisioned Android key not covered by Google's May 2024 auto-restriction policy

4 min read Original article ↗

Hello Google Cloud Community and Gemini API Team,

We are a small startup based in South Korea facing a devastating Gemini API charge of approximately USD 67,000+ accrued in 19 hours on a project that has never used the Gemini API in production (colavo-ae9bd). I am posting here in parallel with our billing dispute (which has already been denied at the first level and is now being escalated to the FSR team via our Korean reseller), as similar cases in this forum — most notably @zanbezi’s €54k case and @Pablo_Ariel_Fahnle’s $4,368 case — have received helpful guidance from Google staff.

Background

  • Project: colavo-ae9bd, created in 2016.

  • Gemini API usage: Zero. The Generative Language API was never integrated into our codebase.

  • Compromised credential: An Android API key auto-provisioned by Firebase / Google Cloud at project creation in 2016 (UID: 3 in our key list). This key was used continuously and legitimately for our production Android app’s Firebase services for nearly a decade without incident, exactly as Google’s documentation described its intended use at the time.

What happened

Between April 18, 2026 ~02:25 KST and April 19, 2026 ~09:00 KST (~19 hours), the project was hit by a coordinated botnet attack against the Gemini API:

  • Peak traffic: 931 requests/second

  • Origin: primarily Dallas (us-south1) — a region where we operate zero infrastructure

  • Geographic distribution: five regions including us-central1, europe-west1, asia-east1, asia-southeast1

  • Credential used: the 2016 Firebase-provisioned Android key (UID: 3) described above

  • API methods called: google.ai.generativelanguage.v1beta.GenerativeService.GenerateContent and related Generative Language API methods — none of which exist anywhere in our codebase

  • Total charges: ~USD 67,000+

Root cause — Google’s May 2024 auto-restriction policy was never applied to our key

Per Google’s official Firebase documentation:

“Starting in May 2024, all existing API keys that Firebase provisioned automatically and that are unrestricted are restricted to the Firebase-related API list…”

Our key meets every condition of this policy:

  1. It was auto-provisioned by Firebase/Google Cloud (not created by us)

  2. It existed before May 2024 (created in 2016)

  3. It was unrestricted

However, this automated restriction was never applied to our key. The “API restrictions” field remained blank (-) in the Cloud Console — we have screenshots confirming this state immediately before and after the attack. As a result, an Android key that should have been limited to Firebase APIs was able to call the Generative Language API at scale.

This is consistent with the broader systemic issue disclosed by Truffle Security in February 2026 — that historically Google API keys were documented as non-secret client-side identifiers, and the security model only changed retroactively when Gemini was added to the surface.

Detection & remediation

  • Immediately disabled the Generative Language API on the affected project

  • Applied API restrictions to the leaked key

  • Began an emergency app update to rotate the credential (live production app — could not simply delete the key)

  • Filed a billing dispute through GCP Support

First-level support response

The Account & Security team’s first-level response (Case under Billing Account 01B278-XXXXXX-XXXXXX, full ID available to Google staff on request) explicitly confirmed compromise:

“Our systems identified that your Google Cloud Platform project colavo-ae9bd may have been compromised and used for AI Studio. However, we regret to inform you that we are unable to make adjustments to these particular charges.”

We respectfully find this position difficult to reconcile: Google’s own systems identified the project as compromised, the credential abused was one Google itself provisioned, and a Google policy that should have automatically restricted that credential was not applied — yet the financial responsibility is being assigned entirely to us.

The case has now been escalated to the FSR team through our reseller.

Evidence available

  • Cloud Monitoring graphs showing the flat baseline vs. the 19-hour spike, broken down by credential_id

  • SKU-level cost breakdown showing 100% of unauthorized usage on Gemini API Image

  • Console screenshots showing the unrestricted state of the auto-provisioned key

  • Regional traffic distribution and per-second request volume

What we’re asking

  1. Could Google staff monitoring this forum help coordinate a review between the FSR escalation and the security team, given that this case turns specifically on the non-application of the May 2024 auto-restriction policy to a legacy Firebase-provisioned key?

  2. Confirmation of any additional evidence the team would find useful.

If this charge is enforced as-is, our startup faces immediate insolvency. Any guidance, escalation support, or direction on next steps from the community and Google staff would be deeply appreciated.

Thank you for your time and consideration.