DEV Community

DeepSeaX
DeepSeaX

Posted on • Originally published at theinsider-x.com

Your Google Maps API Key Now Has Access to Gemini AI - And You Were Never Told

For years, Google told developers that AIza... API keys were not secrets. Embed them in your JavaScript, ship them in your mobile app, commit them to GitHub — it's fine. They're just Maps keys. That guidance was accurate — until Gemini changed the rules. Now, 2,863 previously harmless API keys can access your Gemini AI data, including uploaded files, cached conversations, and fine-tuning datasets. No warning was ever sent.

What Happened

TruffleSecurity scanned the November 2025 Common Crawl dataset — a ~700 TiB archive of publicly scraped web content — and found 2,863 live Google API keys that could authenticate to the Gemini API. These keys were originally created for non-sensitive services like Google Maps and Firebase, and had been publicly embedded in JavaScript, HTML, and mobile apps following Google's own guidance.
The problem: when the Generative Language API (Gemini) was enabled on those GCP projects — whether by the developer experimenting with AI Studio or by default — every existing API key in that project silently gained Gemini access. No notification. No confirmation dialog. No email.

"What makes this a privilege escalation rather than a misconfiguration is the sequence of events. A developer might have created a Maps API key years ago and embedded it in their website. When the Gemini API was enabled for that project, the public Maps key became a credential for accessing sensitive Gemini endpoints."

The Architectural Flaw

Google uses a single API key format — prefixed with AIza — for all services. The default scope when creating a new key is "Unrestricted", meaning the key works for every API enabled in the project.

The Retroactive Escalation Sequence

  • 2020-2024: Developer creates API key for Google Maps, embeds in public JavaScript following Google's guidance
  • Later: Same GCP project gets Generative Language API (Gemini) enabled — via AI Studio experimentation or default
  • Silently: The public Maps key automatically gains full Gemini API access
  • Never: Developer receives any notification of this scope change

HTTP referrer restrictions — Google's recommended protection for Maps keys — provide zero defense against Gemini API calls. Those calls are made server-side, where referrer headers aren't sent.

CWE Classifications

  • CWE-1188: Insecure Default Initialization of Resource — new keys default to "Unrestricted" scope
  • CWE-269: Improper Privilege Management — retroactive privilege grant without notification

What Attackers Can Do

With a Gemini-enabled API key, an attacker can access two critical endpoints:

EndpointPathData at Risk

Files API/v1beta/files/Uploaded documents, PDFs, images, datasets
Cached Contents API/v1beta/cachedContents/Conversation history, cached LLM context windows

Specific attack capabilities include:

  • Data exfiltration: List and extract uploaded documents, search for embedded secrets
  • Conversation theft: Access cached context from previous Gemini interactions
  • Financial abuse: Generate thousands of dollars in billable charges per day
  • Denial of service: Exhaust API quotas, shutting down the victim's legitimate Gemini usage

Key Validation

# Test if a key has Gemini access
curl -X POST \
  "https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:generateContent" \
  -H "x-goog-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"test"}]}]}'

# HTTP 200 + candidates = Gemini-enabled
# HTTP 400 + "API key not valid" = restricted or invalid
Enter fullscreen mode Exit fullscreen mode

Who Is Affected

The 2,863 confirmed vulnerable keys belonged to:

  • Major financial institutions
  • Security vendors (including at least one security company)
  • Global recruiting firms
  • Google itself — Google's own internal API keys, some deployed since February 2023 (predating Gemini's public launch), were found exploitable against Google's internal Gemini infrastructure

The key format signature is universal:

# Regex patterns for detection
AIzaSy[A-Za-z0-9_-]{33}    # 39 chars total
AIza[A-Za-z0-9_-]{35}      # 39 chars total
Enter fullscreen mode Exit fullscreen mode

Disclosure Timeline

DateEvent

Feb 2023Earliest confirmed exposed Google-owned key deployed (Internet Archive verified)
Nov 2025TruffleSecurity scans November Common Crawl; identifies 2,863 vulnerable keys
Nov 21, 2025Report submitted to Google Vulnerability Disclosure Program
Nov 25, 2025Google initially classifies as "intended" / "Customer Issue"
Dec 1, 2025TruffleSecurity shows Google's own keys are vulnerable; issue gains traction
Dec 2, 2025Google reclassifies to "Bug"; severity upgraded
Dec 12, 2025Google shares remediation plan; requests full list of 2,863 keys
Jan 13, 2026Google classifies as "Single-Service Privilege Escalation, READ" (Tier 1)
Feb 19, 202690-day disclosure window closes
Feb 26, 2026Public disclosure by TruffleSecurity

Google's Response

Google committed to three remediation actions:

  • New AI Studio keys will default to Gemini-only scope — breaking the dual-use problem for new keys
  • Leaked API keys will be blocked from Gemini access — Google expanded its internal leaked-credential pipeline to cover the reported keys
  • Proactive notifications will be sent to developers when key leaks are detected

As of the February 26 disclosure, the root-cause fix (preventing unrestricted default scope) was still in progress.

Detection & Hunting

For Security Teams

  • Audit all GCP API keys: Check Cloud Console -> APIs & Services -> Credentials for keys with "Unrestricted" scope
  • Check Generative Language API: If enabled on projects with public-facing keys, those keys have Gemini access
  • Scan source code: Search for AIza prefix in JavaScript bundles, HTML, mobile apps, GitHub repos, CI/CD configs
  • Monitor billing: Unexpected "Generative Language API" charges indicate unauthorized Gemini usage

DLP/SIEM Rules

# Variable names to watch in code scanning
GEMINI_API_KEY
GOOGLE_API_KEY
gemini_api_key
apiKey

# Scan targets
- JavaScript bundles (*.js, *.min.js)
- HTML source files
- .env files
- CI/CD pipeline configs
- Mobile app binaries (APK/IPA decompiled)
Enter fullscreen mode Exit fullscreen mode

SIEM Detection

# Alert on unexpected Gemini API calls
# Monitor for generativelanguage.googleapis.com requests
# from IPs outside your organization

# GCP Audit Log query (Cloud Logging)
resource.type="audited_resource"
protoPayload.serviceName="generativelanguage.googleapis.com"
protoPayload.authenticationInfo.principalEmail=""
Enter fullscreen mode Exit fullscreen mode

MITRE ATT&CK Mapping

IDTechniqueUsage

T1552.004Unsecured Credentials: Private KeysAPI keys found in public web content
T1078.004Valid Accounts: Cloud AccountsLegitimate API keys used for unauthorized Gemini access
T1530Data from Cloud StorageAccessing uploaded files via Files API
T1119Automated CollectionScanning Common Crawl for exposed keys at scale
T1496Resource HijackingGenerating billable charges on victim accounts

Immediate Remediation Steps

  • Rotate all previously public keys — any key that has ever appeared in JavaScript, HTML, a mobile app, or a public repo should be considered compromised
  • Restrict key scope — lock each key to only the specific APIs it needs (Maps, Places, etc.); never use "Unrestricted"
  • Apply both referrer AND API restrictions — referrer restrictions alone don't protect against server-side Gemini calls
  • Disable Generative Language API on projects that don't need it — removes Gemini access from all keys in that project
  • Run TruffleHog against your repos and JavaScript bundles to find exposed AIza... keys
  • Enable billing alerts — set thresholds for Generative Language API to catch unauthorized usage early

Conclusion

This isn't a typical API key leak. The fundamental issue is a retroactive privilege escalation — keys that were created as non-secrets silently became secrets when Gemini entered the picture. Google's "Unrestricted" default scope, combined with zero notification of scope changes, created a class of vulnerability that affects anyone who followed Google's own guidance about API key security.
The lesson extends beyond Google: as AI services get bolted onto existing cloud platforms, previously safe credentials may silently gain access to sensitive AI endpoints. Audit your API keys now — especially if they were created before the AI era.

Sources: TruffleSecurity Research | BleepingComputer | Cybernews | The Stack
Need help auditing your API keys and cloud security posture? Request a free penetration test — currently in open beta.

Top comments (0)