Summary:
Google Cloud API keys (identifiable by the AIza... prefix), which have traditionally been designed and documented as safe to embed in public client-side code for services like Maps and Firebase, are inadvertently functioning as highly privileged authentication credentials for Google’s Gemini AI. When a developer enables the Generative Language API (Gemini) on a Google Cloud Platform (GCP) project, any existing unrestricted API keys in that project silently inherit access to sensitive Gemini endpoints. This implicit trust upgrade allows threat actors to scrape publicly exposed keys—originally deployed as benign project identifiers—and abuse them to access private organizational datasets, incur massive LLM-usage bills, and exhaust API quotas. Truffle Security identified 2,863 live, vulnerable keys in the wild, impacting major financial institutions, security companies, and even Google itself. This issue represents a widespread and easily exploitable privilege escalation risk, highlighting the growing attack surface introduced as legacy cloud architectures integrate with modern AI services.

Security Officer Comments:
The architecture of this threat revolves around two specific Common Weakness Enumerations: Insecure Default Posture (CWE-1188) and Incorrect Privilege Assignment (CWE-269). Google Cloud relies on a single key format for both public identification (Publishable Keys) and sensitive authentication (Secret Keys). Because the GCP API panel defaults to generating keys in an "Unrestricted" state, a key created years ago for a benign website map widget is architecturally wide open. When an internal developer enables the Generative Language API for a prototype, the system retroactively applies sensitive privileges to those existing, publicly deployed keys. This breaks the principle of least privilege and eliminates key separation, creating an Implicit Trust Upgrade.

Exploiting this vulnerability is trivial and requires no complex tooling. Because the key natively trusts the request, no authentication bypass is required. An attacker simply appends the compromised key to a Gemini endpoint URL. By querying the /v1beta/files or /v1beta/cachedContents endpoints, attackers can retrieve uploaded datasets, private organizational documents, and cached LLM context. Depending on the model and context window being abused, an attacker maxing out API calls could generate thousands of dollars in fraudulent charges per day on a single victim account or entirely shut down the organization's AI services via quota exhaustion.

To gauge the scale of the exposure, Truffle Security analyzed the November 2025 Common Crawl dataset—a ~700 TiB archive of scraped HTML, JavaScript, and CSS. The scan identified 2,863 live Google API keys vulnerable to this exact privilege escalation vector. The victimology spans major financial institutions, global recruiting firms, security vendors, and Google's internal engineering teams. One demonstrated proof-of-concept involved a Google product key publicly deployed since at least February 2023, well before Gemini existed, which successfully returned a 200 OK response when hitting the Gemini /models endpoint.

Suggested Corrections:
If you use Google Cloud (or any of its services like Maps, Firebase, YouTube, etc), the first thing to do is figure out whether you're exposed. Here's how.

Step 1: Check every GCP project for the Generative Language API.
Go to the GCP console, navigate to APIs & Services > Enabled APIs & Services, and look for the "Generative Language API." Do this for every project in your organization. If it's not enabled, you're not affected by this specific issue.

Step 2: If the Generative Language API is enabled, audit your API keys.
Navigate to APIs & Services > Credentials. Check each API key's configuration. You're looking for two types of keys. Either configuration allows the key to access Gemini:

• Keys that have a warning icon, meaning they are set to unrestricted
• Keys that explicitly list the Generative Language API in their allowed services

Step 3: Verify none of those keys are public.
This is the critical step. If a key with Gemini access is embedded in client-side JavaScript, checked into a public repository, or otherwise exposed on the internet, you have a problem. Start with your oldest keys first. Those are the most likely to have been deployed publicly under the old guidance that API keys are safe to share, and then retroactively gained Gemini privileges when someone on your team enabled the API. If you find an exposed key, rotate it.

Link(s):
https://thehackernews.com/2026/02/thousands-of-public-google-cloud-api.html

https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules