Uit nieuw onderzoek is gebleken dat Google Cloud API-sleutels, die doorgaans worden aangeduid als project-ID’s voor factureringsdoeleinden, kunnen worden misbruikt om zich te authenticeren bij gevoelige Gemini-eindpunten en toegang te krijgen tot privégegevens.
De bevindingen zijn afkomstig van Truffle Security, dat bijna 3.000 API-sleutels van Google (geïdentificeerd met het voorvoegsel ‘AIza’) ontdekte, ingebed in code aan de clientzijde om Google-gerelateerde services zoals ingebedde kaarten op websites aan te bieden.
“Met een geldige sleutel heeft een aanvaller toegang tot geüploade bestanden en gegevens in de cache en kan het LLM-gebruik in rekening worden gebracht op uw account”, zei beveiligingsonderzoeker Joe Leon, terwijl hij de sleutels toevoegde “nu ook te authenticeren bij Gemini, ook al waren ze daar nooit voor bedoeld.”
Het probleem doet zich voor wanneer gebruikers de Gemini API inschakelen op een Google Cloud-project (dat wil zeggen Generative Language API), waardoor de bestaande API-sleutels in dat project, inclusief de sleutels die toegankelijk zijn via de JavaScript-code van de website, heimelijk toegang krijgen tot Gemini-eindpunten zonder enige waarschuwing of kennisgeving.
Hierdoor kan elke aanvaller die websites sloopt dergelijke API-sleutels in handen krijgen en deze gebruiken voor snode doeleinden en quotadiefstal, inclusief toegang tot gevoelige bestanden via de /files en /cachedContents eindpunten, evenals het uitvoeren van Gemini API-aanroepen, wat enorme rekeningen voor de slachtoffers oplevert.
Bovendien ontdekte Truffle Security dat het maken van een nieuwe API-sleutel in Google Cloud standaard ‘Onbeperkt’ is, wat betekent dat deze van toepassing is op elke ingeschakelde API in het project, inclusief Gemini.
“Het resultaat: duizenden API-sleutels die als goedaardige factureringstokens werden ingezet, zijn nu live Gemini-inloggegevens die op het openbare internet staan”, aldus Leon. In totaal zei het bedrijf dat het 2.863 live sleutels had gevonden die toegankelijk waren op het openbare internet, waaronder een website die aan Google is gekoppeld.
De onthulling komt op het moment dat Quokka een soortgelijk rapport publiceerde, waarin meer dan 35.000 unieke Google API-sleutels werden aangetroffen die waren ingebed in de scan van 250.000 Android-apps.
“Naast potentieel kostenmisbruik door geautomatiseerde LLM-verzoeken moeten organisaties ook overwegen hoe AI-ondersteunde eindpunten kunnen interageren met prompts, gegenereerde inhoud of verbonden clouddiensten op manieren die de ontploffingsradius van een gecompromitteerde sleutel vergroten”, aldus het mobiele beveiligingsbedrijf.
“Zelfs als er geen directe klantgegevens toegankelijk zijn, creëert de combinatie van toegang tot gevolgtrekkingen, quotaconsumptie en mogelijke integratie met bredere Google Cloud-bronnen een risicoprofiel dat wezenlijk verschilt van het oorspronkelijke factureringsidentificatiemodel waarop ontwikkelaars vertrouwden.”
Hoewel het gedrag aanvankelijk als bedoeld werd beschouwd, heeft Google sindsdien ingegrepen om het probleem aan te pakken.
“We zijn op de hoogte van dit rapport en hebben met de onderzoekers samengewerkt om het probleem aan te pakken”, vertelde een woordvoerder van Google via e-mail aan The Hacker News. “Het beschermen van de gegevens en infrastructuur van onze gebruikers is onze topprioriteit. We hebben al proactieve maatregelen geïmplementeerd om gelekte API-sleutels die proberen toegang te krijgen tot de Gemini API te detecteren en te blokkeren.”
Het is momenteel niet bekend of dit probleem ooit in het wild is uitgebuit. In een Reddit-bericht dat twee dagen geleden werd gepubliceerd, beweerde een gebruiker echter dat een “gestolen” Google Cloud API-sleutel tussen 11 en 12 februari 2026 $ 82.314,44 aan kosten opleverde, vergeleken met een normale uitgave van $ 180 per maand.
We hebben contact opgenomen met Google voor verder commentaar en we zullen het verhaal bijwerken als we iets horen.
Gebruikers die Google Cloud-projecten hebben opgezet, wordt geadviseerd hun API’s en services te controleren en te verifiëren of API’s met betrekking tot kunstmatige intelligentie (AI) zijn ingeschakeld. Als ze zijn ingeschakeld en openbaar toegankelijk zijn (in JavaScript aan de clientzijde of ingecheckt in een openbare opslagplaats), zorg er dan voor dat de sleutels worden gerouleerd.
“Begin eerst met je oudste sleutels”, zei Truffle Security. “Deze zijn het meest waarschijnlijk publiekelijk ingezet onder de oude richtlijn dat API-sleutels veilig zijn om te delen, en vervolgens met terugwerkende kracht Gemini-rechten verkregen toen iemand in uw team de API inschakelde.”
“Dit is een goed voorbeeld van hoe risico’s dynamisch zijn, en hoe API’s achteraf te veel toestemming kunnen krijgen”, zegt Tim Erlin, beveiligingsstrateeg bij Wallarm, in een verklaring. “Het testen van de beveiliging, het scannen van kwetsbaarheden en andere beoordelingen moeten continu plaatsvinden.”
“API’s zijn vooral lastig omdat veranderingen in hun activiteiten of de gegevens waartoe ze toegang hebben niet noodzakelijkerwijs kwetsbaarheden zijn, maar ze kunnen wel direct het risico vergroten. De adoptie van AI die op deze API’s draait, en het gebruik ervan, versnelt het probleem alleen maar. Het vinden van kwetsbaarheden is niet echt voldoende voor API’s. Organisaties moeten gedrag en gegevenstoegang profileren, afwijkingen identificeren en kwaadwillige activiteiten actief blokkeren.”
