Google API-Schlüssel als ungewollte Gemini-Zugangsdaten

IT-Sicherheitsforscher haben rund 2.800 aktiv nutzbare Google API-Schlüssel im öffentlichen Internet aufgedeckt, die ursprünglich für Kartendienste oder Firebase gedacht waren und nun uneingeschränkten Zugriff auf die Gemini-KI ermöglichen — ohne dass die betroffenen Entwickler je darüber informiert wurden.

Vom harmlosen Identifikator zur Authentifizierungslücke

Über mehr als ein Jahrzehnt hat Google Entwicklern ausdrücklich empfohlen, API-Schlüssel im Format AIza... bedenkenlos in clientseitigen Code einzubetten. Diese Schlüssel galten als reine Projektkennungen für Abrechnungszwecke — vergleichbar mit einer öffentlichen Kundennummer. Entsprechend finden sie sich bis heute in Millionen öffentlicher Websites, JavaScript-Bundles und mobiler Apps.

Mit der Einführung der Gemini-API hat sich dieses Modell grundlegend gewandelt. Wird die Generative Language API in einem Google Cloud-Projekt aktiviert, erhalten sämtliche bestehenden API-Schlüssel dieses Projekts automatisch Zugriff auf die entsprechenden Endpunkte — darunter auch jene Schlüssel, die seit Jahren öffentlich zugänglich sind. Eine Benachrichtigung der Projektinhaber erfolgt dabei nicht, eine Bestätigung wird nicht eingeholt.

Grafik Quelle: Truffle Security

Ablauf der Rechteerweiterung

Das Muster lässt sich in drei Schritten beschreiben: Ein Entwickler erstellt vor Jahren einen Schlüssel für Google Maps und bettet ihn nach damals geltenden Richtlinien in den Quellcode einer Website ein. Zu einem späteren Zeitpunkt aktiviert ein Teammitglied im selben Projekt die Gemini-API — etwa für einen internen Prototyp. Ab diesem Moment verfügt der öffentlich einsehbare Schlüssel stillschweigend über Zugriff auf die KI-Plattform. Der ursprüngliche Entwickler wurde zu keinem Zeitpunkt informiert.

Sicherheitsexperten bezeichnen diesen Mechanismus als Privilegieneskalation (CWE-269), ergänzt durch eine unsichere Standardkonfiguration (CWE-1188): Neue API-Schlüssel in der Google Cloud Console werden standardmäßig auf „Uneingeschränkt“ gesetzt, was bedeutet, dass sie sofort für alle im Projekt aktivierten APIs gültig sind — einschließlich Gemini.

Was Angreifer mit einem solchen Schlüssel tun können

Der Aufwand für einen Missbrauch ist gering. Ein Angreifer ruft die betroffene Website auf, extrahiert den im Quellcode sichtbaren Schlüssel und sendet eine Anfrage an den Gemini-API-Endpunkt. Erhält er eine Erfolgsantwort (HTTP 200), stehen ihm mehrere Angriffsvektoren offen.

Über die Endpunkte /files/ und /cachedContents/ lassen sich hochgeladene Dokumente, Datensätze und zwischengespeicherte Kontexte abrufen, die der Projektinhaber über die Gemini-API abgelegt hat. Darüber hinaus kann die API-Nutzung auf Kosten des Opferkontos ausgeführt werden — je nach Modell und Kontextumfang sind dabei Beträge im vierstelligen Bereich pro Tag möglich. Schließlich besteht die Möglichkeit, das verfügbare Kontingent vollständig zu erschöpfen und so legitime KI-gestützte Dienste des betroffenen Unternehmens lahmzulegen.

Scan des Common Crawl: 2.863 aktive Schlüssel identifiziert

Um das tatsächliche Ausmaß des Problems einzuschätzen, durchsuchten Sicherheitsforscher den Common Crawl-Datensatz vom November 2025 — ein rund 700 Terabyte umfassendes Archiv öffentlich indexierter Webseiten. Das Ergebnis: 2.863 aktive Google API-Schlüssel, die für die beschriebene Rechteerweiterung anfällig sind.

Unter den betroffenen Organisationen befinden sich nach Angaben der Forscher große Finanzinstitute, Sicherheitsunternehmen und Personalvermittler — sowie Google selbst. Einer der analysierten Schlüssel war in den Quellcode einer öffentlichen Google-Produktwebsite eingebettet und nachweislich seit mindestens Februar 2023 aktiv, also noch vor Existenz der Gemini-API. Tests zeigten, dass dieser Schlüssel vollständigen Zugriff auf die Gemini-Endpunkte gewährt.

Offenlegung und Reaktion von Google

Die Forscher meldeten die Schwachstelle am 21. November 2025 über Googles Vulnerability Disclosure Program (VDP). Die initiale Einschätzung des Unternehmens lautete, es handele sich um beabsichtigtes Verhalten. Erst nachdem konkrete Beispiele aus Googles eigener Infrastruktur vorgelegt wurden, gewann das Thema intern an Gewicht.

Am 2. Dezember 2025 stufte Google den Bericht von einem „Kundenproblem“ zu einem „Fehler“ um, erhöhte den Schweregrad und bat um die vollständige Liste der 2.863 betroffenen Schlüssel. Am 13. Januar 2026 wurde die Schwachstelle als „Single-Service Privilege Escalation, READ“ (Tier 1) klassifiziert. Google bestätigte zudem eine interne Pipeline zur Erkennung kompromittierter Schlüssel sowie Maßnahmen, um deren Zugriff auf die Gemini-API einzuschränken.

Geplante Maßnahmen seitens Google

Google hat öffentlich dokumentiert, welche strukturellen Änderungen geplant sind. Neue Schlüssel, die über AI Studio erstellt werden, sollen standardmäßig ausschließlich für Gemini verwendbar sein, um unbeabsichtigte dienstübergreifende Nutzung zu verhindern. Schlüssel, die als kompromittiert eingestuft werden, sollen automatisch blockiert werden. Darüber hinaus soll eine proaktive Benachrichtigung eingeführt werden, sobald ein geleakter Schlüssel identifiziert wird.

Ob Google bestehende, potenziell betroffene Schlüssel rückwirkend überprüft und die jeweiligen Projektinhaber benachrichtigt, ist nach aktuellem Stand noch offen.

Empfohlene Maßnahmen für Entwickler und Sicherheitsteams

Wer Google Cloud oder damit verbundene Dienste wie Maps, Firebase oder YouTube einsetzt, sollte zunächst prüfen, ob die Generative Language API in den eigenen Projekten aktiviert ist. Dies lässt sich in der GCP-Konsole unter „APIs & Services“ > „Enabled APIs & Services“ überprüfen.

Im nächsten Schritt sollten alle API-Schlüssel im Bereich „APIs & Services“ > „Credentials“ kontrolliert werden. Schlüssel ohne Einschränkungen sowie Schlüssel, die die Generative Language API explizit auflisten, besitzen Gemini-Zugriff. Ältere Schlüssel verdienen dabei besondere Aufmerksamkeit, da sie mit hoher Wahrscheinlichkeit noch unter der früheren Empfehlung zur öffentlichen Einbettung erstellt wurden.

Öffentlich zugängliche Schlüssel mit Gemini-Zugriff sollten umgehend rotiert werden. Zur automatisierten Erkennung empfehlen die Forscher den Einsatz von TruffleHog, das nicht nur auf den Schlüsseltyp prüft, sondern auch verifiziert, ob ein gefundener Schlüssel tatsächlich aktiv und Gemini-fähig ist.

Strukturelles Problem mit Signalwirkung

Der Fall veranschaulicht ein architektonisches Muster, das über Google hinaus relevant ist: Wenn KI-Funktionen nachträglich in bestehende Plattformen integriert werden, können Authentifizierungsmodelle, die für ein anderes Sicherheitsniveau konzipiert wurden, zu einer erweiterten Angriffsfläche werden — ohne dass Entwickler oder Sicherheitsteams dies bemerken. Das Kernproblem liegt dabei nicht im individuellen Fehlverhalten einzelner Entwickler, sondern in der Architekturentscheidung, ein einziges Schlüsselformat für grundlegend unterschiedliche Sicherheitskontexte zu verwenden.

„Die in diesem Beitrag veröffentlichten Informationen wurden sorgfältig recherchiert. Dennoch übernehmen wir keine Gewähr für Vollständigkeit oder absolute Richtigkeit. Die Inhalte dienen der allgemeinen Orientierung und ersetzen keine fachkundige Beratung. Für etwaige Fehler, Auslassungen oder Folgen aus der Nutzung der Informationen übernimmt die Redaktion keine Haftung. Trotz sorgfältiger Prüfung können vereinzelt unbeabsichtigte Fehler oder Ungenauigkeiten, etwa bei Übersetzungen, auftreten.“

Auch interessant:

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky

Folgen Sie uns auf Mastodon

Hamsterrad Rebell – Cyber Talk