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

Gemini API
, ,
1

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.

2

Attaching the key supporting evidence as referenced in the original post.

  1. 30-day API request baseline vs. attack spike
    This shows the Gemini API request count for project `colavo-ae9bd` over the 30 days preceding the incident. The baseline is effectively zero — consistent with our statement that the Generative Language API was never integrated into our codebase. The single vertical spike on April 18, 2026 is the entirety of the unauthorized usage.

GeminiAPI이상레포트_colavo-ae9bd_overview_30days_copy
GeminiAPI이상레포트_colavo-ae9bd_overview_30days_copy1920×962 213 KB

3

2.API Keys list — auto-created Google Service keys with no restrictions appliedNote that all of the auto-created Google Service keys from 2016–2018 (iOS, Android, Browser, Server) show the same empty `Restrictions` field — none of them received the May 2024 auto-restriction that Google’s documentation states should have been applied

colavo-ae9bd_API_Keys copy
colavo-ae9bd_API_Keys copy2433×769 93.6 KB

4

3. Attack timeline and credential breakdownThe credential_id column clearly shows the abuse was concentrated on `apikey:3` — the auto-provisioned Android key — across multiple regions (us-south1, us-central1, europe-west1, asia-east1) and multiple methods

GeminiAPI이상레포트_colavo-ae9bd_260418_오후12시부터폭증_오후9시35분피크
GeminiAPI이상레포트_colavo-ae9bd_260418_오후12시부터폭증_오후9시35분피크1920×961 185 KB

5

@Logan_Kilpatrick — your guidance on the €54k case was invaluable to that team. Since our root cause is structurally similar, we would deeply appreciate any direction you could offer.

6

Interesting—our Firebase project has also been active since 2016, and we recently received an unexpected charge of $13,000 USD. We have submitted a support ticket to Firebase. The support team indicated that the charge may have resulted from unauthorized usage due to a leaked API token. The case has now been escalated to the Cloud support team and is still under investigation.

Meanwhile, the next billing cycle is approaching. If this unexpected charge cannot be resolved or waived, we may be forced to terminate all services and end our 10-year partnership with Google.

We hope to recover from this situation and rebuild our business moving forward, even if it means doing so without Google. Good luck to everyone facing similar issues.

7

@Adam_Hook — thank you for sharing this. Same 2016-vintage Firebase project, same support pattern, same billing cycle pressure on our end too. The alignment in timeline and scope is striking.

One detail that may be worth a look on your side: Google’s documented May 2024 auto-restriction policy was supposed to retroactively secure legacy Firebase-provisioned keys, but in our case it was never applied — the API restrictions field remained blank in the Cloud Console. Sharing in case it’s relevant to your situation as well.

Wishing you the best path forward. Will share how ours resolves; please do the same if you can.

8

@junghyun_colavo Thank you investigating and documenting the incident.

We suffered from the same in April. Our Firebase auth is setup in 2023 and we got £2700 bill for Gemini usage in a single day, while our average monthly GCP bill is ~£10 and never use Gemini in that project.

9

Hey @Libo — sorry to hear that. The shape sounds similar to ours on the surface (Firebase-provisioned key, sudden Gemini spike on a project that never used it), though every case has its own specifics.

Two quick checks would tell us whether it’s the same root cause:

  1. In Cloud Console → APIs & Services → Credentials, was the abused key auto-provisioned by Firebase, and is the “API restrictions” field empty (—)? In our case, these legacy keys were labeled as “auto-created by Google Service.”

  2. Per Firebase docs, unrestricted auto-provisioned keys created before May 2024 should have been auto-restricted to Firebase-only APIs starting May 2024. Did that policy actually apply to your key, or was it left unrestricted like ours?

Happy to compare notes — feel free to DM.

10

We’re in a very similar situation ourselves and really feel for what your team is going through.

We sincerely hope your case gets the attention it deserves and reaches a fair resolution. Wishing you and your team the best.

11

Hi, @zanbezi Thank you for your support — and we’re sorry your team is going through something similar.
We’ll keep sharing updates, and we hope both of our teams can reach a fair resolution.
Let’s stay in touch and support each other.

12

So, what happened next?
So, how did the subsequent process go?

13

@square

Update (May 23, 2026):
Still pending. Through our reseller, We were informed today that Google’s RCA (Root Cause Analysis) is currently analyzing the case — We are still awaiting their findings.

Will share more once the updates.