Loading story…
Aikido Security reported that standard Google Cloud API keys can continue authenticating for up to 23 minutes after deletion, with a median revocation delay of about 16 minutes across 10 tests. The researchers said the gap appears tied to Google’s eventually consistent backend infrastructure, producing inconsistent, region-dependent results in which repeated requests may still reach servers that accept a supposedly deleted key. The behavior was observed not only for Gemini access but also for other Google Cloud APIs including BigQuery and Maps, contradicting Google Cloud interface messaging that deleted keys can no longer be used immediately.
Researchers warned that the post-deletion window could let attackers keep using leaked keys to access enabled services, exfiltrate uploaded files or cached Gemini conversation context, and generate substantial cloud charges, especially where automatic billing tier upgrades raise spending caps during spikes. Aikido said newer Gemini-specific API keys revoked in about a minute and service account keys in roughly five seconds, indicating faster revocation is technically feasible, but Google reportedly classified the delayed revocation as intended behavior and closed the disclosure as "won't fix." The firm advised defenders to treat API key deletion as a 30-minute incident-response process and closely monitor usage after revocation.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
5 events from the most recent confirmed update back to the earliest known activity.
In its public disclosure, Aikido warned that attackers with stolen keys could continue making API calls, incur billing charges, and potentially access Gemini-related data during the post-deletion window. The company advised defenders to treat key deletion as the start of a roughly 30-minute monitoring and incident-response period rather than immediate revocation.
After reporting the delayed revocation behavior, Aikido said Google treated it as intended or known system behavior rather than a security flaw and closed the disclosure as 'won't fix.' Google therefore did not plan a remediation for the standard API key revocation gap described by the researchers.
The researchers reported that other Google credential types revoked much faster, including newer Gemini-specific API keys in about 1 minute and service account keys in about 5 seconds. They concluded the slower revocation of standard API keys is a property of that credential type rather than an unavoidable platform limitation.
Aikido found the delayed revocation behavior was not limited to one service: it affected keys usable with Gemini and other GCP APIs including BigQuery and Maps. Additional testing across Google Cloud regions showed differing success rates after deletion, suggesting regional routing, caching, or backend enforcement differences.
In 10 trials conducted over two days, Aikido Security found that standard Google Cloud API keys continued to authenticate for roughly 8 to 23 minutes after deletion, with a median revocation delay of about 16 minutes. The researchers observed inconsistent post-deletion acceptance, indicating revocation propagates gradually across Google's infrastructure.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
5 references tracked. Mallory keeps watching after this page renders.
cybersecuritynews.com
Open sourcehelpnetsecurity.com
Open sourceaikido.dev
Open sourcetheregister.com
Open sourcedarkreading.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A small three-person software team reported that a **stolen Google Cloud/Gemini API key** was abused to run up **$82,314.44 in charges in roughly 48 hours**, a ~455x spike from their typical **$180/month** spend. The attacker(s) allegedly hammered the **Gemini 3 Pro Image** and **Gemini 3 Pro Text** endpoints, and the victim stated they deleted the compromised key, disabled Gemini APIs, rotated credentials, enabled 2FA, and tightened **IAM** controls while opening a support case. Both reports indicate Google support initially pointed to the cloud **Shared Responsibility Model**, signaling the customer may remain liable for charges tied to compromised credentials. The incident was framed as a cautionary example of how exposed or poorly-scoped API keys can become high-impact AI credentials; one report cited research indicating **thousands of legacy Google API keys** have been found exposed on public websites and warned that default or **“Unrestricted”** API key settings can enable catastrophic cost exposure unless organizations implement guardrails such as billing budgets/caps, API key restrictions (API/IP/referrer scoping), and tighter quota limits.
Jul 3, 2026
Security researchers reported that **previously “non-secret” Google Cloud API keys** (commonly embedded in public client-side code for services like *Google Maps*, YouTube embeds, Firebase, and analytics) can **silently become usable credentials for Gemini (Generative Language API) endpoints** once the Gemini API is enabled in the same Google Cloud project. Truffle Security described this as a **privilege escalation/incorrect privilege assignment** scenario where long-exposed `AIza...` keys—originally treated as project identifiers for billing and API access control—can unexpectedly grant access to **Gemini-related data and capabilities**, including access to private AI resources (e.g., uploaded files/cached context) and **billable inference usage**, without clear developer warning or explicit re-authorization. Truffle Security’s internet-scale scanning (including Common Crawl) identified **~2,800–3,000 exposed keys** across organizations in multiple sectors (and reportedly even from Google), highlighting the practical risk of key harvesting from page source and subsequent abuse. The primary impact described is **data exposure via Gemini API access** and **cost/abuse risk** (attackers potentially generating significant charges by making API calls). Separate from the API-key issue, Google also announced a **Gemini feature update for Google Workspace** that allows Gemini to search Google Chat history (noted as *off by default*), which is a product capability announcement rather than a vulnerability disclosure.
Jun 29, 2026
Tenable Research identified and disclosed three critical vulnerabilities in Google's Gemini AI assistant suite, collectively referred to as the "Gemini Trifecta." These flaws affected three distinct components: Gemini Cloud Assist, Gemini Search Personalization Model, and the Gemini Browsing Tool. The vulnerabilities exposed users to significant privacy and security risks, including the potential for data exfiltration and unauthorized access to sensitive information. In the case of Gemini Cloud Assist, attackers could exploit a prompt injection flaw by embedding malicious prompts within HTTP User-Agent headers sent to Google Cloud services. When Gemini Cloud Assist summarized these logs, the injected prompts could be executed, potentially leading to credential phishing and further compromise of cloud resources. The Search Personalization Model was susceptible to search-injection attacks, where attackers manipulated a user's Chrome search history using JavaScript to inject prompts. This allowed the attacker to control the AI chatbot's behavior and leak the user's saved information and location data. The Gemini Browsing Tool contained an indirect prompt injection vulnerability, enabling attackers to exfiltrate private data by leveraging the tool's internal web page summarization feature. Proof-of-concept demonstrations showed how these vulnerabilities could be exploited in real-world scenarios, with attackers using JavaScript to manipulate browser history and force visits to malicious sites, or injecting logs that would later be summarized by Gemini. All three vulnerabilities were reported to Google and have since been remediated with targeted fixes. The incident highlights the growing risks associated with integrating AI assistants into cloud and enterprise environments, as these tools can become both targets and vehicles for sophisticated attacks. Security researchers emphasized the need for organizations to maintain strict visibility and policy enforcement over AI deployments. The flaws demonstrated that AI models, when given access to sensitive data and external communication capabilities, can be weaponized if not properly secured. The Gemini Trifecta serves as a cautionary example for the broader industry, underscoring the importance of robust security measures in the development and deployment of AI-powered tools. Organizations are urged to review their AI security posture and ensure that similar vulnerabilities are not present in their environments. The rapid remediation by Google mitigated the immediate risks, but the incident has sparked renewed attention on the security challenges unique to AI assistants. As AI adoption accelerates, the need for proactive threat modeling and continuous monitoring of AI systems becomes increasingly critical. The Gemini vulnerabilities illustrate how attackers can exploit the intersection of AI, cloud infrastructure, and user data to achieve their objectives. This event is a reminder that AI security must be prioritized alongside traditional cybersecurity measures to protect users and organizations from emerging threats.
Jun 29, 2026