Researchers with Truffle Security are warning that old and seemingly benign Google API keys might now be weaponized by threat actors after gaining Gemini AI authorization permissions, in a destructive attack that could target a victim’s wallet.
Threat actors might be able to access private data with these keys, and they could readily abuse these permissions to rack up thousands of dollars worth of Gemini API calls on behalf of the victim. Many of these Google API keys have been sitting exposed in public JavaScript code for years at popular websites, with the researchers finding at least one key from 2023 that was exploitable in this way.
Old Google API keys suddenly (and quietly) gained Gemini authorization permissions
The Google API keys are used by services such as Maps, YouTube and Firebase and were largely placed before Gemini AI existed. The researchers found about 3,000 vulnerable keys while scanning a number of large and prominent organizations, including some embedded in Google’s own pages. A follow-up report by security firm Quokka 35,000 exposed Google API keys after scanning some 250,000 apps. Code repositories are also another very likely source of exposed keys, though the two reports did not specifically address this possibility.
The central issue is that when Gemini AI was introduced, Google quietly made numerous already-issued keys a retroactive means of authenticating the AI service for billing purposes. If one of these keys is exposed in a webpage’s source code, an attacker could copy it and then begin making Gemini API calls on the victim’s dime. A threat actor determined to max out calls could run up a bill into the thousands of dollars per day.
In terms of data theft, the attackers would also be able to plumb the /files/ and /cachedContents/ endpoints for exposed documents and datasets. Anything stored via the Gemini AI API could potentially be exposed in this way by simply asking the AI agent to hand it over. Avi Hein, Sr. Product Marketing Manager at Checkmarx, expands on why organizations might be caught short by this sort of vulnerability: “This research exposes a risk that goes beyond a single misconfigured key. It’s fundamentally an API attack surface visibility problem. Organizations are embedding credentials into their code that they don’t fully understand and discovering the exposure after the fact.”
“A robust application security program needs to do three things well: (1) maintain a complete, continuously updated inventory of every API in use, (2) detect secrets and credentials hardcoded into source code before they reach production, (3) and consolidate findings across static analysis, dynamic testing, and API discovery into a single prioritized view. When those capabilities work in isolation, gaps appear. Those gaps are exactly what attackers exploit. The Google Cloud exposure is a perfect example: the key was there, in the code, but no one connected the dots between what it was supposed to do and what it was actually capable of. Organizations that consolidate their AppSec tooling get that connected picture,” recommended Hein.
Google has said that it is aware of the report and is working to address the issue by blocking leaked API keys, sending proactive notifications to owners when exposed keys are detected, and issuing AI Studio keys that default to Gemini-only scope going forward. The researchers say that they disclosed the vulnerability to Google back on November 25, but met with initial pushback about addressing it as the company labeled it as “intended behavior.”
Gemini AI oversight among numerous new AI-enabled vulnerabilities
It is unclear if the Google API keys were ever actually exploited in the wild, but the report calls to mind a story that went viral across social media platforms in recent days. A Gemini AI user claimed that their usual spend of $180 per month suddenly ballooned to $82,314.44 in about one day after an API key was stolen. While it remains unclear if this vulnerability is tied to that incident, it illustrates the scope and speed of damage that can be done by a threat actor.
The story is one of numerous involving unexpected vulnerabilities in recent months, since “agentic AI” has become the hot trend and people have expanded both their personal and work use of these services (and the permissions they grant to make decisions on their behalf). Much of the internet in general to date was simply not designed for the possibility of AI browsing it with permissions and capabilities equivalent to those of a regular human user, and this has led to some retroactive unexpected vulnerabilities. Another recent example comes from OpenClaw, older versions of which can be hijacked by some relatively simple malicious JavaScript embedded in any webpage. The AI agent’s gateway is treated as a trusted local asset, something that allows for a basic WebSocket connection from a webpage to be able to engage in limitless password guessing until it is cracked. WebSocket is normally not a problem in this fashion for regular web browsing, but clearly did not anticipate this type of AI access when it first came available almost 20 years ago.
In terms of remediating the Gemini AI vulnerability, the researchers suggest checking Google Cloud Platform first to see if the “Generative Language API” is enabled. If it is, all Google API keys present with Gemini access (those that either list the Generative Language API or have an “unrestricted” warning icon present) should be audited for potential appearances in some sort of publicly accessible code. Needless to say, any exposed keys should be rotated immediately. The researchers also promote their own “TruffleHog” tool (an open source project) as a means of assisting in sniffing out exposed keys of this sort.
