Previously Harmless Google API keys Now Expose Gemini AI Data
Summary:
For over a decade, Google told developers that standard Google Cloud API keys (the familiar “AIza…” format used for services like Maps and Firebase) were not secrets and were safe to embed in client-side code. That guidance made sense when the keys functioned primarily as project identifiers for billing and could be loosely restricted by referer controls.
However, when the Gemini (Generative Language) API was introduced, those same keys automatically became valid authentication credentials for accessing sensitive Gemini endpoints if the API was enabled on the project.
Developers were not warned that enabling Gemini would retroactively expand the privileges of existing keys. As a result, API keys originally embedded in public websites for harmless use cases could suddenly grant access to private uploaded files, cached data, and billable AI services.
Security Officer Comments:
Researchers scanned the November 2025 Common Crawl dataset and identified 2,863 live Google API keys exposed on public websites that could access Gemini endpoints, affecting organizations ranging from financial institutions to Google itself. With a scraped key, an attacker could query Gemini APIs, retrieve potentially sensitive stored content, exhaust quotas, or generate significant usage charges, all without breaching the victim’s infrastructure.
After the issue was reported, Google reclassified the issue as a privilege-escalation bug, began restricting exposed keys, expanded leaked-key detection, and outlined plans for safer defaults and proactive notifications. While mitigation efforts are underway, the incident highlights how legacy key architecture and insecure defaults can quietly transform public identifiers into high-impact credentials.
Suggested Corrections:
https://www.bleepingcomputer.com/ne...ss-google-api-keys-now-expose-gemini-ai-data/
For over a decade, Google told developers that standard Google Cloud API keys (the familiar “AIza…” format used for services like Maps and Firebase) were not secrets and were safe to embed in client-side code. That guidance made sense when the keys functioned primarily as project identifiers for billing and could be loosely restricted by referer controls.
However, when the Gemini (Generative Language) API was introduced, those same keys automatically became valid authentication credentials for accessing sensitive Gemini endpoints if the API was enabled on the project.
Developers were not warned that enabling Gemini would retroactively expand the privileges of existing keys. As a result, API keys originally embedded in public websites for harmless use cases could suddenly grant access to private uploaded files, cached data, and billable AI services.
Security Officer Comments:
Researchers scanned the November 2025 Common Crawl dataset and identified 2,863 live Google API keys exposed on public websites that could access Gemini endpoints, affecting organizations ranging from financial institutions to Google itself. With a scraped key, an attacker could query Gemini APIs, retrieve potentially sensitive stored content, exhaust quotas, or generate significant usage charges, all without breaching the victim’s infrastructure.
After the issue was reported, Google reclassified the issue as a privilege-escalation bug, began restricting exposed keys, expanded leaked-key detection, and outlined plans for safer defaults and proactive notifications. While mitigation efforts are underway, the incident highlights how legacy key architecture and insecure defaults can quietly transform public identifiers into high-impact credentials.
Suggested Corrections:
- Audit all GCP projects : Navigate to APIs & Services > Enabled APIs and check for the “Generative Language API” across every project
- Inspect API key configurations: Flag any unrestricted keys or keys that explicitly permit the Generative Language API
- Verify no keys are public: Search client-side JavaScript, public repositories, and CI/CD pipelines for any exposed AIza... strings
- Rotate all exposed keys immediately: Prioritize older keys deployed under the previous “keys are safe to share” guidance
- Use TruffleHog for scanning : Run trufflehog filesystem /path/to/your/code --only-verified to detect live, verified Gemini-accessible keys in codebases
https://www.bleepingcomputer.com/ne...ss-google-api-keys-now-expose-gemini-ai-data/