Websites leak Google API keys. Apps leak Google API keys. Even code repositories are full of them. What used to be a nuisance is now letting attackers access your Gemini and sensitive data, security researchers warn.
Truffle Security discovered that old Google API keys, previously used in other projects as harmless identifiers, can turn into a serious risk after the Gemini API is enabled.
“Existing API keys in that project (including the ones sitting in public JavaScript on your website) can silently gain access to sensitive Gemini endpoints. No warning. No confirmation dialog. No email notification,” the report by Truffle Security reads.
A Google API key is tied to the developer’s account and is multipurpose – this special identifier lets apps access Google services, such as Maps, Firebase, and others.
Before Gemini, this API key wasn't considered to be a sensitive credential, but the rules changed with Gemini.
“Google spent over a decade telling developers that Google API keys are not secrets. But that's no longer true: Gemini accepts the same keys to access your private data,” the researchers warn.
For the attacker, the exploit is trivial. Hackers can grab any of the thousands of exposed keys and quickly check whether they give access to Gemini AI. If it works, the attacker can access private data and use the AI assistant as their own, racking up the bill for the original customer.
“The /files/ and /cachedContents/ endpoints can contain uploaded datasets, documents, and cached context. Anything the project owner stored through the Gemini API is accessible,” the researchers at Truffle Security warn.
“Gemini API usage isn't free. Depending on the model and context window, a threat actor maxing out API calls could generate thousands of dollars in charges per day on a single victim account.”
Google acknowledges the issue.
“We are aware of this report and have worked with the researchers to address the issue. 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,” a Google spokesperson told Cybernews.
Thousands of keys exposed
The researchers also ran a quick scan for exposed live keys on the publicly scraped websites.
“We identified 2,863 live Google API keys vulnerable to this privilege-escalation vector,” they noted.
The potential victims include major financial institutions, security companies, recruiting firms, and even Google itself.
“We provided Google with concrete examples from their own infrastructure to demonstrate the issue. One of the keys we tested was embedded in the page source of a Google product's public-facing website,” the report reads.
This specific key was deployed before the Gemini API existed and was previously used solely as a public project identifier. Without any developer intervention, the key had silently gained full access to the sensitive API.
Even at the time of writing, Google’s support pages treat API keys as non-secret.
“API keys for Firebase services are not secret,” Google’s support page reads.
“You do not need to treat API keys for Firebase services as secrets, and you can safely embed them in client code.”
Google is working on the issue
The researchers claim they disclosed the vulnerability to Google on the 21st of November last year. The tech giant initially pushed back, claiming that this behaviour was intended. However, later Google admitted the bug and classified it as “Single-Service Privilege Escalation, READ.”
The public report was published before deploying an actual fix, after the 90-day disclosure window ended. Researchers say that initial triage was “frustrating,” but Google’s team looked at the issue seriously after they provided concrete evidence from Google’s own infrastructure.
According to the report, Google expanded the leaked-credential detection pipeline to cover the reported keys, proactively protecting exposed Google customers.
“They also committed to fixing the root cause, though we haven’t seen a concrete outcome yet.”
However, Google’s public roadmap suggests that new keys created through AI Studio only default to Gemini-only access, preventing unintended cross-service usage.
“We are defaulting to blocking API keys that are leaked and used with the Gemini API, helping prevent abuse of cost and your application data,” the document reads.
Google also plans to communicate proactively when it identifies leaked keys. However, researchers believe the tech giant should retroactively audit existing keys to identify which are affected and notify project owners.
Cybernews previously reported that Google API keys are one of the most commonly exposed secrets in apps. Websites leak thousands of such keys. They’re also prevalent among millions of secrets spilled on GitHub and other repositories.
How to protect your Gemini?
Truffle Security recommends that all developers check each Google Cloud Platform project to see whether the Generative Language API is enabled. This can be found in the GCP console by navigating to APIs & Services > Enabled APIs & Services, and looking for the “Generative Language API.”
If this API is enabled, each API key configuration should be audited. Keys with a warning icon (unrestricted) or that explicitly list the Generative Language API allow Gemini access.
“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,” the researchers warn.
“If you find an exposed key, rotate it.”
They suggest starting with the oldest keys first, which are most likely to have been deployed publicly under the old guidance.
Gemini access can be exposed completely inadvertently.
“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. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill. Nobody told you,” the researchers concluded, describing a potential scenario.
Updated on February 27th [12:10 p.m. GMT] with a comment from Google.
Unlock more exclusive Cybernews content on YouTube.
Your email address will not be published. Required fields are markedmarked