Your Google Maps Key Is Now a Gemini Credential - And Google Knew for Months

For over a decade, Google told developers their API keys were not secrets. Firebase documentation said so explicitly. Google Maps guides instructed them to paste keys directly into client-side HTML. Millions of websites did exactly that.

Then Google launched Gemini. And every one of those public keys quietly became a backdoor into private AI endpoints - with no notification, no confirmation dialog, and no warning of any kind.

What Truffle Security Found

Security researchers at Truffle Security scanned the November 2025 Common Crawl dataset - a roughly 700-terabyte archive of publicly scraped web pages - and identified 2,863 live Google API keys that now authenticate to Gemini AI endpoints despite being deployed in public-facing code.

The victims are not small-time developers running side projects. Truffle's scan turned up keys belonging to major financial institutions, security companies, global recruiting firms, and - in a detail that borders on parody - Google itself. An internally deployed key on a Google product website had gained full Gemini access without any developer intervention.

"You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed. Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential."

How the escalation works

The mechanism is deceptively simple. Google API keys (formatted as AIza... strings) are project-scoped, not service-scoped. When anyone on a Google Cloud project enables the Generative Language API - the service that powers Gemini - every existing API key in that project silently inherits access to Gemini endpoints. No new key is issued. No permission prompt appears. No email is sent.

This means a key created in 2019 for embedding a Google Map on a restaurant website can, years later, start authenticating requests to Gemini's sensitive endpoints. An attacker with one of those public keys can hit endpoints like:

GET https://generativelanguage.googleapis.com/v1beta/files?key=AIza...
GET https://generativelanguage.googleapis.com/v1beta/cachedContents?key=AIza...

These endpoints expose uploaded datasets, documents, cached context, and anything else the project owner stored through the Gemini API.

Close-up of a developer working at a terminal with code on screen With a compromised API key, an attacker can query Gemini endpoints, access uploaded files, and rack up charges - all without the project owner knowing.

What an attacker can do

With a compromised key, the attack surface is sizable:

Access uploaded files - documents, datasets, and any content pushed through the Gemini API
Read cached content - context windows and stored data from Gemini sessions
Run up charges - depending on the model and context window, a threat actor maxing out API calls could produce thousands of dollars in charges per day on a single victim account
Reach connected services - in some configurations, keys can touch Drive, Mail, Calendar, and enterprise systems connected to the same project

The core design flaw is that Google uses a single API key format for two fundamentally different purposes: public identification and sensitive authentication. What used to be a billing identifier is now a password, and the old ones are already scattered across the open web.

The Disclosure Timeline

The timeline of Google's response reveals how slowly the company moved despite the severity of the issue.

Nov 21, 2025 - Truffle Security submits the report to Google's Vulnerability Disclosure Program.

Nov 25, 2025 - Google responds that the behavior is "intended." Case nearly closed.

Dec 1, 2025 - Truffle provides examples from Google's own infrastructure, including keys on Google product websites that had silently gained Gemini access. Google's internal teams take notice.

Dec 2, 2025 - Google reclassifies the report from "Customer Issue" to "Bug," upgrades severity, and requests the full list of 2,863 exposed keys. Truffle provides it.

Dec 12, 2025 - Google shares a remediation plan: an internal pipeline to discover leaked keys, restrictions on exposed keys accessing Gemini, and a commitment to fix the root cause before the 90-day disclosure window closes.

Jan 13, 2026 - Google classifies the vulnerability as "Single-Service Privilege Escalation, READ" (Tier 1).

Feb 2, 2026 - Google confirms the team is still working on the root-cause fix.

Feb 19, 2026 - The 90-day disclosure window expires. The root-cause fix is still in progress.

Feb 26, 2026 - Truffle publishes their findings.

What Google Says - And What It Does Not

Google's official statement reads: "Protecting our users' data and infrastructure is our top priority. We have already implemented proactive measures to detect and block leaked API keys that attempt to access the Gemini API."

The company says new AI Studio keys will default to Gemini-only scope, leaked keys will be blocked from Gemini access, and proactive notifications will go out when leaks are detected.

What remains unclear is whether Google has notified all 2,863 affected project owners individually. The company hasn't confirmed a plan to do so. Many organizations with older, publicly deployed API keys may still be exposed and have no idea.

This isn't the first time AI tooling has introduced unexpected security surfaces. As we documented in our coverage of vibe-coded applications shipping with dozens of vulnerabilities, the speed of AI integration routinely outpaces the security review process. The pattern is familiar from the Claude Code RCE vulnerabilities we reported on earlier - AI capabilities bolted onto existing infrastructure without rethinking the trust model underneath.

A security padlock icon on a screen representing API credential protection Google's own documentation classified API keys as non-sensitive for over a decade. Gemini changed the rules without changing the guidance.

Why This Is Worse Than a Typical API Leak

Most API key leaks are the developer's fault. You accidentally push a key to a public repository, you get burned, you rotate it. Lesson learned. This is different.

These developers followed Google's own security guidance. They embedded keys exactly where Google told them to. The keys were explicitly documented as non-sensitive. The privilege escalation happened retroactively - not because the developers did something wrong, but because Google changed what those keys could do without telling anyone.

For organizations running Gemini 3.1 Pro or any Gemini API integration - including those using AI-powered cybersecurity platforms - the implications are immediate. Any team that enabled the Generative Language API on a project with pre-existing public keys may be exposed right now.

Server racks in a data center with blinking status lights The 2,863 exposed keys span cloud projects at banks, security vendors, recruiters, and Google itself.

What You Should Do

Audit every Google Cloud project for the Generative Language API - if it is enabled, check all API keys for unrestricted access or explicit Gemini permissions
Rotate any publicly exposed keys immediately - even if they were "just" Maps or Firebase keys
Apply API key restrictions - scope keys to specific services and IP ranges
Monitor GCP billing for unusual spikes that could point to unauthorized Gemini usage
Review third-party app permissions - any application using your project's API keys could be a vector

The broader lesson is worth repeating. When an AI company bolts a powerful new capability onto existing infrastructure without resetting the security assumptions that infrastructure was built on, every downstream user inherits the risk. Google spent a decade building a trust model around API keys being safe to expose. Gemini broke that model overnight. And it took the company three months to even acknowledge it was a problem.

Sources: