Old Google API Keys Now Open Gemini, Draining Cloud Bills

Note: This post was written by Claude Opus 4.7. The following is a synthesis of TruffleSecurity’s vulnerability disclosure, official Google statements, and reporting from The Register, The Hacker News, and TechRadar, plus victim accounts on Reddit.

A team of three developers in Mexico woke up on Friday, February 13, 2026, to a Google Cloud bill of $82,314.44. They had been spending about $180 a month. Over the prior 48 hours an attacker had found a Google API key in their public website code and used it to make Gemini API calls until the charges cleared eighty-two thousand dollars. “I am in a state of shock and panic right now,” the founder wrote on Reddit. “If Google attempts to enforce even a third of this amount, our company goes bankrupt.”

The attacker did not break into anything. The key was a Maps or Firebase identifier — the kind Google had spent more than a decade calling not a secret. The change that made the bill possible came from Google itself.

What Google said for a decade

Firebase’s security checklist, still live, includes a section titled “API keys are not secrets” — explaining that Firebase keys “only identify your Firebase project and app to those services” and that authorization is handled via Cloud IAM, Firebase Security Rules, and App Check. Google Maps documentation has long told developers to paste keys directly into HTML. YouTube embed keys appear in millions of public web pages.

Those keys were designed as project billing identifiers, not credentials. The architectural guarantee was simple: a public Maps key cannot read your private data and cannot generate meaningful charges against unrelated services.

That guarantee no longer holds.

What changed when Gemini was enabled

When a developer enables the Generative Language API — the API behind Gemini — on a Google Cloud project, every existing API key in that project silently gains access to Gemini endpoints. No notification, no warning, no opt-in.

TruffleSecurity researcher Joe Leon, who disclosed the issue to Google’s VDP on November 21, 2025, demonstrated the change with a one-line shell command: a key that previously returned 403 Forbidden against generativelanguage.googleapis.com now returns 200 OK, granting access to /files and /cachedContents (where Gemini holds uploaded datasets and cached context) and to billable LLM inference.

“With a valid key, an attacker can access uploaded files, cached data, and charge LLM-usage to your account,” Leon wrote.

TruffleSecurity scanned the November 2025 Common Crawl dataset — roughly 700 TiB of public web content — and identified 2,863 live, exposed Google API keys with Gemini access. The affected list, Leon noted, included financial institutions, security companies, global recruiting firms, and Google itself.

What it cost

The Mexican team’s $82,314 bill was not the largest. A Japanese company saw an unauthorized Gemini bill that began at $44,000 and grew to roughly $128,000 even after the API was paused. An Australian AI consultant with a $7 budget received a charge of $18,392. A solo developer who revoked the compromised key within minutes still saw $15,400 land. A small startup on the Reddit thread that prompted this post took about €7,000 in Gemini charges before catching the alarm on a Sunday morning.

The pattern is consistent: the exposed key sits in public JavaScript or an Android app for legitimate Maps or Firebase use; the owner enables Gemini on the project; an attacker scrapes the key, hits the Gemini endpoint at machine speed, and the bill arrives within hours.

What Google has fixed, and what it hasn’t

Google’s response — initially marked “Intended Behavior” on November 25, then reclassified as a bug on December 1 once researchers presented evidence drawn from Google’s own keys — has been partial. A spokesperson told The Hacker News: “We are aware of this report and have worked with the researchers to address the issue. Protecting our users’ data and infrastructure is our top priority. We have already implemented proactive measures to detect and block leaked API keys that attempt to access the Gemini API.”

In practice: keys created through AI Studio now default to Gemini-only scope, leaked keys discovered in public sources are programmatically blocked from Gemini, and proactive notifications are being deployed. Google has also rolled out prepaid credits and tighter spending controls for the Gemini API itself.

The root cause has not been fixed. Existing keys still inherit new API scopes silently when their parent project enables a new service. Leon’s broader observation: “the pattern we uncovered here (public identifiers quietly gaining sensitive privileges) isn’t unique to Google” — a structural risk in any cloud platform where one identifier authorizes multiple services that can be added behind it.

What to do this week

For any GCP project that uses Firebase, Maps, YouTube, or any API key embedded in public code or a mobile app:

In the Cloud Console, check whether the Generative Language API is enabled. If you didn’t enable it intentionally, disable it.
Review every API key under Credentials. Any unrestricted key, or any key listing Generative Language API among its allowed services, is a rotation candidate.
Confirm those keys aren’t in public JavaScript, GitHub repos, mobile-app binaries, or any other internet-exposed location. If any are, rotate.
Tighten API and HTTP-referrer restrictions on remaining keys.
Set budget alerts at amounts you can absorb if a key is compromised on a Friday night.

The Firebase line that “API keys are not secrets” is now operationally false on any project where Gemini has ever been enabled. Until Google fixes the root cause, treat every Google API key as if it grants whatever scope its project has — and may grant whatever scope it gets next.

What Google said for a decade

What changed when Gemini was enabled

What it cost

What Google has fixed, and what it hasn’t

What to do this week

Sources

Security Scorecard