2 Sources
2 Sources
[1]
Thousands of Public Google Cloud API Keys Exposed with Gemini Access After API Enablement
New research has found that Google Cloud API keys, typically designated as project identifiers for billing purposes, could be abused to authenticate to sensitive Gemini endpoints and access private data. The findings come from Truffle Security, which discovered nearly 3,000 Google API keys (identified by the prefix "AIza") embedded in client-side code to provide Google-related services like embedded maps on websites. "With a valid key, an attacker can access uploaded files, cached data, and charge LLM-usage to your account," security researcher Joe Leon said, adding the keys "now also authenticate to Gemini even though they were never intended for it." The problem occurs when users enable the Gemini API on a Google Cloud project (i.e., Generative Language API), causing the existing API keys in that project, including those accessible via the website JavaScript code, to gain surreptitious access to Gemini endpoints without any warning or notice. This effectively allows any attacker who scrapes websites to get hold of such API keys and use them for nefarious purposes and quota theft, including accessing sensitive files via the /files and /cachedContents endpoints, as well as making Gemini API calls, racking up huge bills for the victims. In addition, Truffle Security found that creating a new API key in Google Cloud defaults to "Unrestricted," meaning it's applicable for every enabled API in the project, including Gemini. "The result: thousands of API keys that were deployed as benign billing tokens are now live Gemini credentials sitting on the public internet," Leon said. In all, the company said it found 2,863 live keys accessible on the public internet, including a website associated with Google. The disclosure comes as Quokka published a similar report, finding over 35,000 unique Google API keys embedded in its scan of 250,000 Android apps. "Beyond potential cost abuse through automated LLM requests, organizations must also consider how AI-enabled endpoints might interact with prompts, generated content, or connected cloud services in ways that expand the blast radius of a compromised key," the mobile security company said. "Even if no direct customer data is accessible, the combination of inference access, quota consumption, and possible integration with broader Google Cloud resources creates a risk profile that is materially different from the original billing-identifier model developers relied upon." Although the behavior was initially deemed intended, Google has since stepped in to address the problem. "We are aware of this report and have worked with the researchers to address the issue," A Google spokesperson told The Hacker News via email. "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." It's currently not known if this issue was ever exploited in the wild. However, in a Reddit post published two days ago, a user claimed a "stolen" Google Cloud API Key resulted in $82,314.44 in charges between February 11 and 12, 2026, up from a regular spend of $180 per month. We have reached out to Google for further comment, and we will update the story if we hear back. Users who have set up Google Cloud projects are advised to check their APIs and services, and verify if artificial intelligence (AI)-related APIs are enabled. If they are enabled and publicly accessible (either in client-side JavaScript or checked into a public repository), make sure the keys are rotated. "Start with your oldest keys first," Truffle Security said. "Those are the most likely to have been deployed publicly under the old guidance that API keys are safe to share, and then retroactively gained Gemini privileges when someone on your team enabled the API." "This is a great example of how risk is dynamic, and how APIs can be over-permissioned after the fact," Tim Erlin, security strategist at Wallarm, said in a statement. "Security testing, vulnerability scanning, and other assessments must be continuous." "APIs are tricky in particular because changes in their operations or the data they can access aren't necessarily vulnerabilities, but they can directly increase risk. The adoption of AI running on these APIs, and using them, only accelerates the problem. Finding vulnerabilities isn't really enough for APIs. Organizations have to profile behavior and data access, identifying anomalies and actively blocking malicious activity."
[2]
Generative AI Rollout Exposes Hidden Risk in Google Cloud API Keys
Generative AI Rollout Transforms Harmless Google API Keys Into Critical Cloud Security Vulnerability A quiet change in how Google's cloud services interact has opened an unexpected security gap, putting thousands of organisations at risk of data exposure and mounting AI bills. Security researchers have found that publicly visible Google API keys, once considered low risk, can now be used to access Gemini AI if the generative AI service is enabled in the same cloud project. Nearly 3,000 such keys are estimated to be active across websites and public code repositories, including those linked to financial institutions, technology firms, and recruitment platforms. For years, developers embedded these keys in apps and webpages for services like Maps or Firebase, relying on Google's guidance that they were not sensitive credentials. That assumption no longer holds.
Share
Share
Copy Link
Security researchers discovered nearly 3,000 Google Cloud API keys embedded in public websites that now authenticate to Gemini AI endpoints without warning. The issue emerged when enabling the Generative AI rollout on existing projects retroactively granted sensitive permissions to keys once considered harmless billing tokens, exposing organizations to quota theft and unexpected AI billing.

A critical API security flaw has emerged from Google's Generative AI rollout, transforming thousands of public Google Cloud API keys into potential entry points for unauthorized access. Security firm Truffle Security discovered nearly 3,000 live Google API keys embedded in client-side code across websites that can now authenticate to Gemini AI endpoints, despite never being intended for such use
1
. These keys, identifiable by their AIza prefix, were originally deployed as billing tokens for services like embedded maps and Firebase, with Google's guidance indicating they posed minimal security risk when exposed publicly.The vulnerability surfaces when users enable the Generative Language API on a Google Cloud project. This API enablement causes existing API keys in that project to gain surreptitious access to Gemini AI endpoints without any warning or notice to developers
1
. Security researcher Joe Leon from Truffle Security explained that with a valid key, attackers can access uploaded files, cached data, and charge LLM usage to victim accounts. The problem extends beyond Gemini AI—Quokka's separate analysis of 250,000 Android apps uncovered over 35,000 unique Google API keys embedded in mobile applications, demonstrating the scale of public exposure across different platforms1
.The security gap allows attackers who scrape websites to harvest these exposed keys and exploit them for quota theft and data breaches. Malicious actors can access sensitive information via the /files and /cachedContents endpoints, make unauthorized API calls to Gemini, and rack up substantial unexpected AI billing charges for victims
1
. One Reddit user reported that a compromised Google Cloud API key resulted in $82,314.44 in charges between February 11 and 12, 2026—a dramatic spike from their regular monthly spend of $1801
.Compounding the issue, Truffle Security found that creating a new API key in Google Cloud defaults to "Unrestricted" status, meaning it applies to every enabled API in the project, including Gemini AI
1
. This default configuration transforms what developers believed were harmless billing tokens into live Gemini credentials sitting on the public internet. The affected keys span code repositories and websites linked to financial institutions, technology firms, and recruitment platforms—even including a site associated with Google itself2
.While Google initially deemed this behavior as intended functionality, the company has since acknowledged the severity and implemented countermeasures. A Google spokesperson confirmed they worked with researchers to address the issue, stating: "We have already implemented proactive measures to detect and block leaked API keys that attempt to access the Gemini API"
1
. The company emphasized that protecting user data and infrastructure remains their top priority, though it remains unclear whether this vulnerability was actively exploited in the wild before detection systems were deployed.Related Stories
Security experts stress that organizations using cloud services need to audit their Google Cloud project configurations urgently. Users should verify whether AI-related APIs are enabled in their projects and check if API keys are publicly accessible in client-side JavaScript or public repositories
1
. Truffle Security recommends starting with the oldest keys first, as these were most likely deployed under previous guidance that API keys were safe to share publicly, then retroactively gained Gemini privileges when teams enabled the API.Tim Erlin, security strategist at Wallarm, noted this case illustrates how risk profiles evolve dynamically: "APIs can be over-permissioned after the fact. Security testing, vulnerability scanning, and other assessments must be continuous"
1
. He emphasized that finding vulnerabilities isn't enough for API security—organizations must profile behavior and data access, identify anomalies, and actively block malicious activity. The combination of inference access, quota consumption, and possible integration with broader Google Cloud resources creates a materially different risk profile from the original billing-identifier model developers relied upon.Summarized by
Navi
[1]
[2]
30 Sept 2025•Technology

31 Jan 2025•Technology

30 Jul 2025•Technology

1
Business and Economy

2
Technology

3
Policy and Regulation
