A critical privilege escalation vulnerability affecting Google Cloud API keys specifically how legacy public-facing keys now silently grant unauthorized access to Google’s Gemini AI endpoints, exposing private files, cached data, and billable AI usage to attackers.

For over a decade, Google explicitly instructed developers to embed API keys formatted as AIza... strings directly into client-side HTML and JavaScript.

Firebase’s official security checklist stated that API keys are not secrets, and Google Maps documentation directed developers to paste keys publicly into web pages. These keys were designed as project identifiers for billing, not as authentication credentials. That guidance is now dangerously outdated.

When the Gemini API (Generative Language API) is enabled on a Google Cloud project, every existing API key in that project silently inherits access to sensitive Gemini endpoints — with no warning, no confirmation dialog, and no email notification to the developer.

A key deployed three years ago to render a Maps embed can overnight become a live credential capable of accessing uploaded AI files, cached context, and billable inference services.

Researchers at Truffle Security have found out why this situation is a privilege escalation and not just a simple misconfiguration. The key factor is the order of events. A developer followed Google’s guidelines by placing a Maps API key in public JavaScript. Later, another team member activated the Gemini API on the same cloud project.

The public key immediately gained access to sensitive Gemini endpoints, and the original developer was never notified.

The vulnerability roots lie in two recognized weaknesses: CWE-1188 (Insecure Default Initialization) and CWE-269 (Incorrect Privilege Assignment). By default, new API keys in Google Cloud are set to “Unrestricted,” meaning they can access every enabled API in the project from the moment of creation, including Gemini.