Full Report
Google Cloud uses a single API key format for public identification and sensitive authentication. Google Maps, Firebase, and similar services were okay to embed directly on the page. This was acceptable because it was part of the design. The keys were designed for billing and restricted on the frontend via HTTP referer allowlisting so this was alright. Gemini uses the same API keys (public API) as the existing project. So, by using a public API key that's been on a website for years, it's now possible to access information about that project's Gemini usage. this retroactive privilege expansion is not good in practice. The defaults are that an API key is valid for ALL services on the project and not scoped down. An attacker can access private data, such as the files and cached contents. They can also increase your bill. The authors found 2.8K keys, including several of Google's own keys that were vulnerable to this attack. So, what was Google's response? Initially, they said this was a customer issue, until they showed Google doing this wrong. To fix this, they added scoped defaults within the AI studio, API keys that are leaked are automatically blocked. Additionally, there's proactive notification to identify which teams would be vulnerable. Response to this is hard... You don't want to brick anybody's website, but you also don't want them to lose data. Hmmmm. A great find! This is a classic example of threat models changing in a large ecosystem without understanding the results. Great work!
Analysis Summary
# Vulnerability: Retroactive Privilege Expansion of Public Google API Keys to Gemini Endpoints
## CVE Details
- CVE ID: Not specified in the source material. Research ongoing.
- CVSS Score: Not specified in the source material. Severity inferred as **High** due to potential data compromise and billing impact.
- CWE: CWE-269 (Improper Privilege Assignment), CWE-1188 (Improper Default for New Objects)
## Affected Systems
- Products: Google Cloud Platform (GCP) API Keys, Google Maps API, Firebase API, Gemini API (Generative Language API).
- Versions: Any GCP project where an existing API key (used for public services like Maps) is present in client-side code, and the Gemini API is subsequently enabled on that **same project**.
- Configurations: The default configuration for newly created API keys ("Unrestricted") inheriting access to all enabled APIs, including Gemini, without developer notification.
## Vulnerability Description
Google Cloud has historically treated specific API keys (like those used for Google Maps or Firebase, often embedded client-side) as public identifiers for billing purposes, not sensitive secrets. When the Gemini API is enabled on a GCP project, existing, publicly exposed API keys automatically gain credentials to access sensitive Gemini endpoints—including the ability to read uploaded files and cached contents—due to insecure, project-wide default scoping. This represents a **retroactive privilege expansion**, transforming previously benign, public keys into elevated authentication mechanisms without user warning or consent.
## Exploitation
- Status: Proof of Concept (PoC) available (demonstrated via `curl` command accessing Gemini endpoints). Not explicitly stated as exploited in the wild against end-users, but the vulnerability was demonstrated internally at Google.
- Complexity: **Low**. The attacker only needs to scrape the publicly available API key from client-side source code and issue standard API calls to the Generative Language endpoints.
- Attack Vector: **Network** (Remote via simple web scraping).
## Impact
- Confidentiality: **High**. Attackers can access private data, including uploaded files and cached content associated with the Gemini usage of the project.
- Integrity: **Medium/High**. Attackers can potentially manipulate usage patterns, leading to unauthorized billing charges.
- Availability: **Low/Medium**. Primary impact is not availability, but the risk of service abuse leading to increased costs.
## Remediation
### Patches
Google's immediate response included architectural changes within the AI Studio environment:
* **Scoped Defaults:** New API keys created via the AI studio default to being scoped, rather than "Unrestricted."
* **Automatic Blocking:** Leaked API keys are now subject to automatic blocking mechanisms targeting Gemini access.
### Workarounds
For existing, public keys that were inadvertently granted Gemini access:
1. **Restrict by API Service:** Manually edit existing API keys within GCP and explicitly disable the Generative Language API for the exposed keys.
2. **Key Rotation:** Generate entirely new API keys for public-facing services (like Maps) and update all client-side implementations. Once confirmed operational, delete the compromised, publicly exposed keys.
3. **Proactive Notification:** Users identified as vulnerable (those with pre-existing public keys and the Gemini API enabled) should receive proactive notifications from Google Cloud.
## Detection
- **Indicators of Compromise (IoCs):** Unusual or high volumes of API calls directed to Gemini endpoints (`generativelanguage.googleapis.com`) originating from unexpected geographical locations or user agents, correlating with known exposed API keys.
- **Detection Methods and Tools:** Employ secret scanning tools (like TruffleHog) to identify known exposed API key patterns (`AIza...`) that have associated Gemini API calls in logs. Review GCP Audit Logs for unexpected access to the Gemini services utilizing keys known to be embedded in public client-side code.
## References
- Vendor Advisory/Blog: Truffle Security Blog (Indirect reference via external analysis).
- Relevant Links:
* trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules
* firebase.google.com/support/guides/security-checklist#api-keys-not-secret (Historical context on key safety)
* developers.google.com/maps/documentation/javascript/get-api-key?setupProd=configure#make_request (Historical context on key usage)