- Google hat seit mehr als 10 Jahren erklärt, API-Schlüssel seien keine Geheimnisse und könnten gefahrlos offengelegt werden – doch seit der Aktivierung der Gemini API wurde derselbe Schlüssel zu einem sensiblen Authentifizierungsmittel
- Bereits vorhandene öffentliche Schlüssel, die in Google Maps, Firebase usw. verwendet wurden, erhielten automatisch Berechtigungen für den Zugriff auf die Gemini API, wodurch mit offengelegten Schlüsseln Zugriff auf persönliche Daten und kostenpflichtige Abrechnungen möglich wurde
- Truffle Security bestätigte, dass 2.863 aktiv genutzte Google-API-Schlüssel im Internet offengelegt sind; darunter befinden sich teilweise auch Schlüssel von Google-eigenen Diensten
- Google hat das Problem anerkannt und führt derzeit Sperrung geleakter Schlüssel, Gemini-spezifische Standardeinstellungen und Benachrichtigungen bei Offenlegung ein, doch eine rückwirkende Prüfung bestehender Schlüssel ist noch nicht abgeschlossen
- Der Vorfall zeigt das Risiko einer Berechtigungsausweitung bestehender Zugangsdaten durch die Integration von AI-Funktionen; Entwickler sollten daher umgehend prüfen, ob die Gemini API aktiviert ist und ob Schlüssel offengelegt wurden
Kernproblem
- Google Cloud verwendet eine einheitliche API-Schlüsselstruktur im Format
AIza..., die gleichzeitig zwei Zwecke erfüllt: öffentliche Identifikation und sensible Authentifizierung
- Früher erklärte Google Entwicklern ausdrücklich, es sei sicher, API-Schlüssel direkt in Client-Code einzubetten
- Auch in der Firebase-Sicherheits-Checkliste hieß es: „API-Schlüssel sind kein Geheimnis“
- Sobald jedoch die Gemini API aktiviert wird, erhalten alle bestehenden API-Schlüssel eines Projekts automatisch Zugriff auf Gemini-Endpunkte
- Die Berechtigungen werden ohne Warnung, Bestätigungsschritt oder E-Mail-Benachrichtigung erweitert
- Daraus ergeben sich zwei Probleme
- Rückwirkende Berechtigungsausweitung (Retroactive Privilege Expansion): Früher offengelegte Maps-Schlüssel werden zu Zugangsdaten für Gemini
- Unsichere Standardwerte (Insecure Defaults): Beim Erstellen neuer Schlüssel ist die Voreinstellung „Unrestricted“, wodurch Zugriff auf alle APIs einschließlich Gemini möglich ist
- Damit werden letztlich Tausende für Abrechnung gedachte Tokens zu echten Authentifizierungsdaten, die im Internet offengelegt sind
Mögliche Angriffsszenarien
- Angreifer können einen
AIza...-Schlüssel aus dem Quellcode einer Website kopieren und mit einer einfachen curl-Anfrage auf die Gemini API zugreifen
- Angreifer können dadurch
- auf nicht öffentliche Daten zugreifen (
/files/, /cachedContents/-Endpunkte)
- Kosten über die Gemini API verursachen
- durch Ausschöpfen von Quotas einen Dienstausfall herbeiführen
- Dafür müssen sie nicht in die Infrastruktur des Opfers eindringen, sondern lediglich Schlüssel von öffentlichen Webseiten extrahieren
Ausmaß der offengelegten Schlüssel
- Truffle Security analysierte den Common-Crawl-Datensatz vom November 2025 (ca. 700 TiB) und fand 2.863 aktive Google-API-Schlüssel
- Diese Schlüssel wurden ursprünglich für öffentliche Dienste wie Google Maps verwendet, verfügten aber über Berechtigungen für den Gemini-API-Zugriff
- Zu den Betroffenen zählen Finanzinstitute, Sicherheitsunternehmen, globale Recruiting-Firmen und sogar Google selbst
- Auch Google war also demselben strukturellen Risiko ausgesetzt
Fall eines internen Google-Schlüssels
- Truffle Security demonstrierte den Zugriff auf die Gemini API mit einem Schlüssel aus dem öffentlich zugänglichen Quellcode einer Google-Produktwebsite
- Dieser Schlüssel war bereits vor Februar 2023 öffentlich, ursprünglich nur zur einfachen Projektidentifikation gedacht
- Ein Aufruf des Endpunkts
/models lieferte eine erfolgreiche Antwort (200 OK) und bestätigte damit den Zugriff auf sensible APIs
- Damit zeigt sich ein Fall, in dem ein früher harmloser Schlüssel ohne Eingriff der Entwickler sensible Berechtigungen erhielt
Zeitleiste von Meldung und Reaktion
- 21. November 2025: Meldung an Googles VDP
- 25. November: Google bewertet das Verhalten zunächst als „beabsichtigt“
- 1.–2. Dezember: Nachdem Truffle Security den Fall eines internen Google-Schlüssels vorlegte, klassifizierte Google das Problem als Bug neu und stufte die Schwere höher ein
- 12. Dezember: Google begann mit der Erweiterung der Pipeline zur Erkennung geleakter Schlüssel und Maßnahmen zur Einschränkung des Gemini-Zugriffs
- 13. Januar 2026: Google stufte die Schwachstelle als „Single-Service Privilege Escalation (READ)“ ein
- 2. Februar: Es wurde bestätigt, dass Arbeiten an der Behebung der Grundursache laufen
Folgemaßnahmen von Google
- Google kündigte in offiziellen Dokumenten die folgenden Pläne zur Sicherheitsverbesserung an
- Scoped defaults: Neue in AI Studio erstellte Schlüssel erlauben standardmäßig nur Gemini-spezifischen Zugriff
- Leaked key blocking: Automatische Sperrung des Gemini-API-Zugriffs für geleakte Schlüssel
- Proactive notification: Sofortige Benachrichtigung der Nutzer bei Erkennung offengelegter Schlüssel
- Einige Verbesserungen werden bereits umgesetzt, doch eine rückwirkende Prüfung vorhandener offengelegter Schlüssel und die Benachrichtigung der Nutzer sind noch nicht abgeschlossen
Leitfaden zur Prüfung für Entwickler
- Schritt 1: In allen GCP-Projekten prüfen, ob die Generative Language API aktiviert ist
- Schritt 2: Falls aktiviert, in den API-Schlüsseleinstellungen Schlüssel mit „Unrestricted“ oder mit Gemini-Zugriff identifizieren
- Schritt 3: Prüfen, ob diese Schlüssel in öffentlichem Code oder auf Webseiten enthalten sind
- Offengelegte Schlüssel sollten sofort rotiert werden
- Bonus: Mit dem Tool TruffleHog lassen sich aktiv genutzte Schlüssel mit Gemini-Zugriff automatisch erkennen
- Beispielbefehl:
trufflehog filesystem /path/to/your/code --only-verified
Fazit
- Der Vorfall zeigt das strukturelle Risiko, dass bisher öffentliche Zugangsdaten durch das Hinzufügen von AI-Funktionen sensible Berechtigungen erhalten
- Google hat das Problem erkannt und reagiert, doch die Bedeutung sicherer Standardwerte und einer getrennten Schlüsselarchitektur wird dadurch erneut deutlich
- Entwickler und Unternehmen sollten umgehend prüfen, ob die Gemini API aktiviert ist und ob Schlüssel offengelegt wurden
1 Kommentare
Hacker-News-Kommentare
Die Dokumentation von Google AI Studio empfiehlt, Apps über einen offenen Proxy bereitzustellen
Diese Vorgehensweise vermittelt fälschlich den Eindruck, der API-Schlüssel sei sicher, weil er hinter dem Proxy liegt, tatsächlich ermöglicht sie aber Missbrauch bei der AI-Abrechnung
Selbst Apps ganz ohne AI-Funktionen sind Hochkostenmodellen ausgesetzt, wenn der Schlüsselumfang nicht manuell eingeschränkt wird
Solche verwundbaren Apps lassen sich allein über Google-, Twitter- und Hacker-News-Suchen leicht finden
Eine dazugehörige Analyse ist in diesem Beitrag zusammengefasst
Google sagt zwar, dass geleakte Schlüssel blockiert werden, aber ursprünglich wurden diese Schlüssel gar nicht als Geheimnisse behandelt
Ideal wäre gewesen, allen vor der Einführung von Gemini erstellten Schlüsseln den Zugriff auf Gemini zu verwehren
Wenn das Leak-Erkennungssystem Fehlalarme produziert, besteht zudem das Risiko, dass auch legitime Gemini-Schlüssel blockiert werden
Zumindest müssten die Berechtigungen für die Generative Language API von allen bestehenden Schlüsseln entfernt werden, aber selbst das wäre keine vollständige Lösung
Am Ende könnte es nötig sein, diese Berechtigung pauschal von allen Schlüsseln zu entfernen
Das würde unzählige Anwendungen kaputtmachen und ist wohl ein Grund, warum Google das Problem nicht eingestehen will
Noch gravierender ist, dass die Schlüssel sogar zwischengespeicherte Kontexte und hochgeladene Daten offenlegen
Es wurde festgestellt, dass in alten Android-Images hartkodierte Google-Schlüssel tatsächlich mit Gemini verwendet werden konnten
Einige waren bereits von vielen Leuten in Gebrauch und deshalb rate-limitiert, aber manche funktionierten weiterhin
Vor etwa zwei Monaten wurden diese Schlüssel offenbar als geleakt eingestuft und sämtlich deaktiviert
Vor langer Zeit erstellte Schlüssel waren ursprünglich nur für eingeschränkte Dienste wie Firebase oder Firestore gedacht
Nach der Einführung von Gemini wurde der Gemini-Zugriff für bestehende Schlüssel jedoch automatisch aktiviert, was Missbrauch stark erleichterte
Öffentliche Schlüssel in APK-Dateien wurden damit praktisch direkt zu Zugangsschlüsseln für Gemini
Wenn etwa Entwickler X einen Schlüssel für Maps erstellt und ein anderer Entwickler Y im selben Projekt Gemini aktiviert,
erhält Xs Schlüssel Zugriffsrechte auf Gemini
Deshalb sollte man Projektwiederverwendung vermeiden und getrennte GCP-Projekte pro Dienst einsetzen
Es bleibt fraglich, warum ein so offensichtlicher Sicherheitsfehler nicht schon vorher entdeckt wurde
Selbst bei einem Großkonzern wie Google sollte es dafür standardisierte Tests oder Spezifikationen geben
Je größer und komplexer eine Organisation wird, desto mehr solcher blinden Flecken in der Aufsicht entstehen eher noch
aber sie waren weiterhin nur auf Aufgaben wie das Umkehren eines Binärbaums fixiert
Dieser Vorfall erinnert an frühere Fälle des Missbrauchs von SSN (Sozialversicherungsnummern)
Ursprünglich war das nur eine einfache Identifikationsnummer, doch irgendwann wurde sie als Authentifizierungsschlüssel verwendet, wodurch das Problem eskalierte
Es ist dieselbe Struktur, bei der etwas schnell und billig umgesetzt wird und die Kosten am Ende auf die Nutzer abgewälzt werden
Es wirkt, als habe Google das Problem noch immer nicht vollständig gelöst
Es war ein großer Fehler, der durch den überhasteten Start von Gemini entstanden ist,
und zur Behebung müssten bestehende Schlüssel deaktiviert werden, was Kunden-Workflows massiv beeinträchtigen könnte
Auch für Google ist das ein äußerst schädlicher Imageschaden
Es handelt sich um eine Art Problem der nachträglichen Ausweitung von Berechtigungen (Retroactive Privilege Expansion)
Wenn jemand früher einen alten Maps-Schlüssel öffentlich auf einer Website eingebunden hat und später ein anderer Entwickler im Team Gemini aktiviert,
wird dieser öffentliche Schlüssel sofort zu einer Zugangsberechtigung für Gemini
Dadurch kann letztlich jeder mit diesem Schlüssel auf Datei-Uploads oder Cache-Daten zugreifen
Nutzer, die gemäß der alten Dokumentation öffentliche Schlüssel verwendet haben, tragen nun den Schaden
Ein Angreifer kann einen solchen Schlüssel stehlen und einen Abrechnungs-Schock verursachen
Einfach erklärt wurden tausende bestehende API-Schlüssel plötzlich von bloßen Abrechnungstokens zu
direkten Gemini-Zugangsdaten
Ein Maps-API-Schlüssel war ursprünglich dafür gedacht, Nutzern Kartendienste bereitzustellen, während die Abrechnung über meine Karte läuft
Das Problem ist, dass solche Schlüssel nun auch auf Gemini zugreifen können
Man hätte separate interne Projekte zur Trennung der Schlüssel anlegen müssen,
stattdessen wurde zur schnellen Bereitstellung einfach LLM-generierter Code übernommen und bei Problemen Google die Schuld gegeben
Auch frühere Forschung des Sicherheitsunternehmens, das dieses Problem analysiert hat, war beeindruckend
So haben sie etwa mit dem Beitrag “Anyone can Access Deleted and Private Repository Data on GitHub” eine Schwachstelle offengelegt, die Zugriff auf gelöschte GitHub-Repository-Daten ermöglichte
Auch diesmal war ihre Analyse sehr hilfreich