What happened in the April 2026 Firebase Gemini exploit incidents?

Three GCP customers reported attacks in April 2026 with the same pattern: a public Firebase or Maps API key was harvested and used to drive Gemini API calls from outside parties, generating four-figure charges. Case 1: a 5-year GCP customer running a Firebase startup hit €7,000 in Generative Language API charges over a single weekend, never having used Gemini intentionally. Google offered a €2,000 partial waiver with negotiation ongoing. Case 2: a separate developer reported approximately $3,000 in Gemini charges in a few hours on April 27. Budget alerts fired but reached the human after spend was already at four figures. Case 3: a university student running a Places API project saw their bill go from £40 to £1,500 in a single day; after deleting the key, disabling all APIs, and deleting the project, charges continued to grow for another 6 hours due to Maps usage reporting in 24 to 48 hour batches.

How do you lock down a GCP project against Firebase API key abuse?

Four operational moves lock down a project in under an hour. First, disable the Generative Language API on every project that does not actually use Gemini (most exposure comes from projects that have it enabled via quickstarts or Firebase console flows but never call Gemini intentionally). Use `gcloud services list --enabled` to enumerate, then `gcloud services disable generativelanguage.googleapis.com`. Second, restrict every API key by HTTP referrer (web), IP address (server), Android SHA-1 fingerprint, or iOS bundle ID, plus explicitly enumerate the APIs the key is allowed to call. Third, set quota limits on the Generative Language API and budget alerts at $50, $100, and $500 daily thresholds scoped to that service. Fourth, audit and rotate any key that was active before late 2025 since the exposure window opened sometime before November 2025.

How do you restrict a Google API key properly?

The default for a new API key is 'unrestricted', which is the wrong default for any production use case. In the GCP Console under Credentials, two restriction layers apply per key. Application restrictions limit where the key can be used: HTTP referrers (websites) for client-side keys, IP addresses for server-side keys, Android apps with SHA-1 fingerprints for mobile clients, iOS bundle ID for iOS apps. API restrictions explicitly enumerate the APIs the key is allowed to call. For a Firebase web key, this typically includes Identity Toolkit API, Firebase Installations API, Firebase Realtime Database API, and the specific Firebase services your app uses. The Generative Language API should not be on the list unless you are intentionally calling Gemini from the client. The most common error is leaving 'Don't restrict key' selected, which is the default. Change it on every key in every project.

What can you expect from Google support if you get hit by this exploit?

Based on April 2026 incident reports from r/googlecloud, the realistic timeline is one to three weeks for billing-team resolution. First contact: the support agent will acknowledge the issue but may not be deeply familiar with the cross-API permission change; be prepared to link to the Truffle Security writeup as the technical reference. Initial offer: typically 25 to 30 percent of the disputed amount, which is an opening position rather than a final one. Escalation path: ask for the case to be reviewed by the billing team specifically, loop in your account manager if you have one, and reference your project's permission history (no recent changes) as evidence that the exposure was platform-side. Customers reporting this class of exposure during April 2026 reported waivers ranging from partial to roughly 90 percent of the disputed amount after escalation. The first offer is rarely the final one.

How Public Firebase Keys Became Gemini Tokens (And What It Cost Three Companies)

Q: How did Firebase API keys become a Gemini billing vector?

Firebase API keys were designed to be public, identifying the project to Firebase services while authorization happens through IAM, Firebase Security Rules, and App Check. The model worked for years because the key authorized only Firebase APIs (Authentication, Firestore, Realtime Database, Cloud Storage for Firebase, Cloud Functions). A quiet policy change before November 2025 expanded the key's scope to include the Generative Language API. The same key that previously authorized only Firebase services started authorizing paid Gemini API calls if Gemini was active on the project. The change was not announced, the Firebase documentation was not updated, and the console did not surface a warning. Truffle Security disclosed the change to Google's Vulnerability Disclosure Program on 2025-11-21. The exposure compounds because attackers had built scrapers for public Firebase keys long before this change, so a large pre-existing key inventory became immediately exploitable.

Q: Should you rotate Firebase API keys that were active before late 2025?

Yes. The window of exposure runs from when cross-API access to the Generative Language API was first enabled (per public reports, sometime before November 2025) to when you applied lockdown restrictions. Any key that was unrestricted during that window should be considered potentially harvested by the scrapers that have been collecting public Firebase keys for years. Rotate the key, deploy the new key to your client bundle, and revoke the old one. This is a small operational lift but it closes the residual risk that an old key still in the wild can be replayed against your project. If the key was server-side only behind a VPC and never appeared in a client bundle, the rotation priority is lower but still recommended. Keys that appeared in any client-side artifact (web bundle, mobile app, browser extension, public GitHub commit) are higher priority and should rotate immediately.

Three different GCP projects hit unexpected charges in April 2026 ranging from £1,500 to €7,000. The common thread: a Firebase or Maps API key that was public by design got reused for Gemini API calls by an external attacker.

Google has documented Firebase API keys as not-secrets for years. Most production code still treats them that way. But a quiet policy change starting in late 2025 made the same keys usable for the Generative Language API, and the attackers found out before the customers did. If you have Firebase, Maps, or any "public" Google API keys in your client bundle and your project has the Generative Language API enabled, you are exposed.

This article covers what changed (without a notification), the specific incidents from April, and the four operational moves that lock down your project in under an hour. No code rewrite required.

What Changed (Without a Notification)

Firebase API keys were designed to be public. The official Firebase documentation says so explicitly:

> API keys for Firebase services only identify your Firebase project and app to those services. Authorization is handled through Google Cloud IAM permissions, Firebase Security Rules, and Firebase App Check.

That guidance assumes the key has restricted scope. Specifically, that the key only authorizes the Firebase APIs (Authentication, Firestore, Realtime Database, Cloud Storage for Firebase, Cloud Functions for Firebase) and nothing else.

The cross-API access change had been live for some time before Truffle Security disclosed it to Google's Vulnerability Disclosure Program on November 21, 2025; Google's exact enablement date has not been publicly stated. The same key that previously authorized only Firebase services started authorizing Gemini API calls if Gemini was active on the project. The change was not announced. The Firebase documentation was not updated. The console did not surface a warning. The first time most affected customers learned about it was when they got a billing alert with four-figure Gemini charges.

The mechanism is documented in detail by Truffle Security in their public writeup, which is the canonical reference for the technical specifics.

Two facts compound the problem. First, the Generative Language API is enabled by default on many GCP projects (especially those created through the Firebase console after early 2025). Second, attackers built scrapers for public Firebase keys long before this change took effect, so the moment Gemini access was added, a large pre-existing key inventory became immediately exploitable.

The Three Incidents in April 2026

We surfaced these three from public Reddit threads. They are not edge cases.

Case 1: A startup running Firebase, €7,000 in a single weekend

A 5-year GCP customer running a small startup on Firebase noticed a billing alarm Sunday morning. By the time they identified the cause, Generative Language API charges had reached €7,000. They had never used Gemini intentionally. The Firebase API key in their client bundle had been harvested and used to drive Gemini calls from outside parties.

Google support acknowledged the issue and offered a partial waiver of €2,000. Negotiation for the remaining €5,000 was ongoing at the time of the original Reddit post. The technical post-mortem confirmed that the key permissions had not changed since the project was created. The exposure was caused by Google enabling cross-API access, not by anything the customer did.

Case 2: A developer reporting $3,000 in hours on April 27, 2026

A different customer reported essentially the same incident on April 27, 2026. Generative Language API charges of approximately $3,000 in a few hours. Same root cause: Firebase API key harvested, used for Gemini calls, no project-side configuration change at any point. The customer had budget alerts on the project and they fired, but by the time the alert reached a human, the spend was already at four figures.

Case 3: A university student, £1,500 Maps key abused into Gemini

A university student running a small project with the Places API saw their bill go from £40 to £1,500 in a single day. After they deleted the API key, disabled all APIs, disabled billing, and deleted the project, the reported charges continued to grow for another six hours. Google support confirmed the requests did not originate from the user's IP. Same exploitation pattern, applied through a Maps key rather than a Firebase key, with the Generative Language API as the destination.

The continued growth after deletion is a separate billing-aggregation issue: Maps usage is reported in batches, sometimes 24 to 48 hours late, so the spike continues to accrue from already-completed traffic even after the source is shut down.

The student acknowledged in the thread that the key had no HTTP referrer or IP restrictions applied, which is the gap that Move 2 below closes. The exposure was platform-side, the recovery is platform-side, but the preventable layer is the one the customer controls.

With Google's own confirmation that the requests did not come from the user's IP, the case for an adjustment is on solid ground. The Maps Billing team typically takes one to three weeks to review and resolve cases at this scale.

Why Public Keys Are Public By Design (And Why That Was Fine)

The Firebase API key model is sound when applied correctly. It identifies the project, not the user. Authentication for actual user actions happens through Firebase Auth, Firestore Security Rules, App Check, and Cloud Functions IAM. The key by itself cannot read your data.

The model assumed two boundaries:

The key authorizes only Firebase services
The Firebase services have their own authorization layer that the key alone does not satisfy

Both boundaries held for years. The Generative Language API change broke the first one. Once the same key authorizes a paid third-party-style API with no separate authorization layer, the key transitions from identifier to bearer token. And bearer tokens cannot be public.

The cleanest framing of the technical problem comes from a Reddit commenter in one of those threads:

> Firebase standard keys have too much rights per default. Which normally doesn't matter much but with introducing Gemini API there was a very valuable API for others to use. The problem is that the unrestricted API Key can also be used to query Gemini.

That is the entire story in two sentences. The defaults were fine until the API surface they authorized expanded silently.

Four Operational Moves to Lock Down in Under an Hour

If you have any Google API keys in client-side code (web bundles, mobile apps, browser extensions), do these four things in order. Total time is under an hour for a single project, longer if you have many projects to audit.

1. Disable the Generative Language API on Every Project That Doesn't Use Gemini

Most exposure comes from projects that have Gemini enabled but do not actually use it. Common reasons: someone clicked through a quickstart, a third-party tutorial recommended enabling it, the Firebase console enabled it as part of a separate feature.

gcloud services list --enabled --project=your-project-id | grep generativelanguage

If the API is enabled and you are not using it intentionally:

gcloud services disable generativelanguage.googleapis.com --project=your-project-id

Repeat for every project in your organization. This is the single highest-leverage move. It eliminates the attack surface entirely for projects that do not need Gemini.

2. Restrict Every API Key by Referrer, by API, and by IP

For projects that legitimately need Gemini, Firebase, or Maps APIs, restrict every key explicitly. The default for a new key is unrestricted, which is the wrong default for any production use case.

In the GCP console, Credentials, click on each API key:

Application restrictions: HTTP referrers (websites) for client-side keys, IP addresses for server-side keys, Android apps with SHA-1 fingerprints for mobile, iOS bundle ID for iOS apps.
API restrictions: explicitly enumerate the APIs the key is allowed to call. For a Firebase web key, this is typically Identity Toolkit API, Firebase Installations API, Firebase Realtime Database API, and the specific Firebase services your app uses. The Generative Language API should not be on the list unless you are intentionally calling Gemini from the client.

The most common error here is leaving "Don't restrict key" selected. That is the default. Change it.

3. Set Quota Alerts on Generative Language at $50, $100, $500 Daily Thresholds

Even with everything locked down, a defense in depth move is to cap the upside of any potential exposure. Set quota limits and budget alerts on the Generative Language API specifically:

GCP Console → APIs & Services → Generative Language API → Quotas

Set requests-per-day to a value matched to your actual usage plus a small headroom. Then set a billing budget with email alerts at $50, $100, and $500 daily thresholds, scoped to the Generative Language API service filter.

The alerts will not stop the spend, but they will reach you in minutes rather than hours, which is the difference between a £1,500 incident and a £15,000 incident.

For a deeper treatment of GCP-specific budget caps and the limitations of the soft alerts, see our GCP Idle Resources guide.

4. Audit and Rotate Any Key That Was Active Before Late 2025

The window of exposure is from whenever cross-API access was enabled (per public reports, sometime before November 2025) to when you applied the restrictions in steps 1 and 2. Any key that was unrestricted during that window should be considered potentially harvested.

Rotate the key, deploy the new key to your client bundle, and revoke the old one. This is a small operational lift but it closes the residual risk. If the key was not in your bundle (server-side only, behind a VPC) the rotation is lower priority but still recommended.

What to Expect From Google Support If You Get Hit

Based on the three incidents above and other reports from r/googlecloud during April 2026, here is the realistic timeline:

First contact: the support agent will acknowledge the issue but is unlikely to be deeply familiar with the cross-API permission change. Be prepared to link to the Truffle Security writeup as the technical reference.
Initial offer: typically 25 to 30 percent of the disputed amount. This is an opening position, not a final one.
Escalation path: ask for the case to be reviewed by the billing team specifically. If you have an account manager, loop them in. Reference your project's permission history (no recent changes) as evidence that the exposure was platform-side.
Typical resolution time: one to three weeks for the billing team to apply credits or waive charges.

Customers reporting this class of exposure on r/googlecloud during April 2026 have reported waivers ranging from partial to roughly 90 percent of the disputed amount after escalation, with at least one thread commenter citing prior cases at that range. The first offer is rarely the final one.

If you are mid-incident and the spike is still growing, separately confirm that the API key is rotated and the API is disabled, then document the timeline for the case ticket.

The Pattern This Reveals About Cloud Security Defaults

This incident is not just about Firebase or Gemini. It points at a structural problem with how cloud providers manage permission scope changes for existing resources.

The Firebase API key model held for years because the scope was stable. When Google extended the scope to include the Generative Language API, the change happened to existing keys retroactively. Anyone who had built a security model around the previous scope inherited an expansion they did not request.

Similar patterns will recur as cloud providers continue to bundle new APIs into existing service categories. The defensive position is to assume any "public" or "browser-safe" API key has a non-zero chance of becoming a bearer token in a future scope expansion, and to apply the four moves above as a baseline regardless of whether you currently use the affected API.

For broader cloud cost protection patterns, see our AI Agents for Cloud Costs article. The four lockdown moves above are how you prevent a spike like this in the first place. Billing-data anomaly detection is how you size the spike, confirm the impact, and track the recovery once the billing export lands the next day. The two layers are complementary.

Tracking AI and ML Costs Across Clouds for the broader pattern of AI billing landing in unexpected places
GCP Idle Resources Guide for budget caps, quota limits, and the gap between soft and hard spend controls
AI Agents for Cloud Costs for anomaly detection that catches exposure as the billing data lands
Truffle Security writeup for the technical specifics

Want the billing-data anomaly detection layer that confirms a spike like this the moment your billing data lands? Brain Agents AI runs Cost Scout (LLM-narrated anomaly alerts), Savings Advisor (recommendations to recover), and the Weekly Briefing (executive digest) across GCP, AWS, and Azure on FOCUS-normalized billing data. Real-time event detection is on the roadmap; today, when your billing export lands, we have already understood the anomaly and surfaced the recovery path.