Your Google Maps API Key Might Now Be a Gemini Credential — Here's What Happened

TL;DR

Google API keys deployed years ago for Maps and Firebase now silently authenticate to Gemini endpoints. Over 2,800 live keys were found exposed on the public internet. If you have public Google API keys, you need to audit and restrict them immediately.

What Changed?

For over a decade, Google told developers the same thing: API keys are not secrets. Firebase's own documentation says so. Google Maps instructs you to paste them directly into HTML.

That advice just aged very badly.

Truffle Security recently discovered that when you enable the Gemini API (Generative Language API) on a Google Cloud project, every existing API key in that project — including the ones sitting in your public JavaScript — silently gains access to sensitive Gemini endpoints.

No warning. No confirmation dialog. No email notification.

The Numbers

• 2,863 live API keys found on the public internet via Common Crawl
• Keys belonged to financial institutions, security companies, recruiting firms — and Google itself
• 35,000+ keys found embedded in Android apps (Quokka research)

Why This Matters

The attack is trivial:

1. Visit any website using Google Maps embed
2. View page source → copy the AIza... key
3. Hit the Gemini API with that key
4. Get a 200 OK instead of 403 Forbidden

From there, an attacker can:

• Access private data — uploaded files, cached datasets, documents
• Run up your bill — thousands of dollars/day in Gemini API charges
• Exhaust your quotas — shutting down legitimate services

The Root Cause

Two CWEs at play:

The key went from a public billing identifier to a sensitive authentication credential — and nobody told the developers who deployed it years ago.

Not an Isolated Issue

This isn't the only Google Cloud AI security concern this month. CVE-2026-2472 disclosed a stored XSS vulnerability in the Vertex AI Python SDK (google-cloud-aiplatform versions 1.98.0 → 1.130.x), allowing unauthenticated attackers to execute arbitrary JavaScript in Jupyter/Colab environments via poisoned model evaluation results.

→ View CVE-2026-2472 details on VulnTracker

Together, these findings paint a clear picture: AI tooling is expanding the attack surface faster than teams can track.

What You Should Do Right Now

1. Audit your Google Cloud API keys

• List all keys: gcloud services api-keys list
• Check which APIs each key can access
• Look for any keys with "Unrestricted" scope

2. Restrict your keys

• Limit each key to specific APIs (e.g., Maps only)
• Add application restrictions (HTTP referrer, IP)
• Never use the same key for public services and sensitive APIs

3. Check if Gemini API is enabled on your projects

• If you don't need it, disable it
• If you do, create a separate, restricted key for Gemini

4. Rotate old keys

• Any key embedded in client-side code before Gemini was enabled should be rotated
• Create new keys with proper restrictions

5. Monitor your exposure

• Track vulnerabilities affecting your stack automatically
• Set up VulnTracker to get alerted when new CVEs affect Google Cloud products you use

The Bigger Lesson

Google's own engineering teams couldn't avoid this trap. If the vendor can't get it right, expecting every developer to navigate it correctly is unrealistic.

The AI era is creating security risks that don't fit neatly into traditional vulnerability categories. API keys that were safe for a decade suddenly aren't. SDKs that handle data visualization suddenly execute arbitrary code.

The only defense is staying ahead of the curve — and that means automated, continuous monitoring of the tools and services you depend on.

References

• Truffle Security Research
• The Hacker News Coverage
• Quokka Mobile Security Research
• CVE-2026-2472 on VulnTracker

Track Google Cloud vulnerabilities and get notified of updates:
View CVE-2026-2472 on VulnTracker →