Gestohlene Google API-Keys verursachen Gemini-Rechnungen von 128.000 Dollar

Eine Rechnung von 82.314 Dollar in 48 Stunden – ein 455-facher Anstieg gegenüber dem normalen Verbrauch – ist der prägnanteste Datenpunkt in dieser Geschichte. Das ist kein falsch konfigurierter Cron-Job und kein außer Kontrolle geratener Test. Das ist ein kleines Team in Mexiko, das beobachtet, wie seine Cloud-Rechnung sich um etwa drei Größenordnungen vervielfacht, weil ein Key, der als sicher zum Einbetten galt, plötzlich als gültige Berechtigung für Gemini-Inferenz genutzt wurde. Das Muster wiederholt sich in drei dokumentierten Vorfällen und 22 Anwendungen – und die architektonische Grundursache liegt bei Google, nicht bei den Entwicklern.

Die Zahlen

Die Schlagzahl beträgt 128.000 Dollar an unerlaubter Gemini API-Nutzung bei einem einzigen japanischen Unternehmen, wie TechRadar berichtete – obwohl dieses Unternehmen IP-Beschränkungen auf Firewall-Ebene eingerichtet hatte. Die IP-Allowlist verhinderte den Missbrauch nicht. Dieses Detail ist wichtiger als der Geldbetrag, denn es zeigt, dass die Angriffsfläche kein Netzwerkproblem ist.

Die beiden anderen Vorfälle zeigen die Bandbreite. Ein Einzelentwickler widerrief den betroffenen Key im ersten Fall innerhalb von Minuten nach der ersten Abrechnungswarnung – dennoch betrug der Schaden 15.400 Dollar, bedingt durch die Verzögerung bei der Google Cloud-Abrechnungserfassung. Das mexikanische Team verzeichnete in 48 Stunden 82.314 Dollar – ein 455-facher Anstieg gegenüber der normalen Nutzungsrate. Drei Datenpunkte, drei verschiedene Reaktionsmuster, und alle drei führten zu vier- bis fünfstelligen Verlusten.

Die Angriffsfläche ist größer als die Fallstudien vermuten lassen. Die Forschung von CloudSEK identifizierte 32 exponierte Google API-Keys in 22 Android-Anwendungen, und diese 22 Apps verfügen zusammen über eine Installationsbasis von mehr als 500 Millionen Nutzern. Zu den betroffenen Apps zählen OYO Hotel Booking, Google Pay for Business, Taobao und ELSA Speak. Bei ELSA Speak bestätigten Forscher, dass sie über die Gemini Files API von Nutzern hochgeladene Audiodateien abrufen konnten – der Schadensradius beschränkt sich also nicht nur auf Abrechnungen, sondern umfasst auch Nutzerdaten.

Zum Vergleich bezüglich der Installationsbasis: 500 Millionen Installationen entsprechen in etwa der Bevölkerung der Europäischen Union und des Vereinigten Königreichs zusammen. Selbst wenn nur ein Bruchteil dieser Installationen aus Regionen stammt, in denen die Keys erfolgreich extrahiert und weitergeleitet werden können, ist der nutzbare Pool an kostenlosen KI-Rechenkapazitäten für Angreifer enorm. Was die Quelle nicht offenbart, ist, wie viele der 32 Keys aktiv missbraucht werden im Vergleich zu solchen, die lediglich auffindbar sind – diese Grenze ist entscheidend: Bei einer Missbrauchsrate von 5 % handelt es sich um einen begrenzten Vorfall; bei 50 % sollten wir mit einer Welle von fünfstelligen Abrechnungsüberraschungen im dritten Quartal rechnen, die noch nicht in Offenlegungsberichten aufgetaucht sind.

Wenn dieses Muster anhält, prognostiziere ich mindestens zwei weitere öffentliche Meldungen über fünfstellige oder höhere unerlaubte Gemini-Rechnungen von namentlich genannten Unternehmen bis Ende Q3 2026.

Was wirklich neu ist

Das neuartige Element hier ist die stille Privilegienerweiterung. Tuhin Bose, der CloudSEK-Forscher, der die Arbeit leitete, formulierte es klar: „Dieses Problem geht nicht auf Entwicklerverschulden zurück; die Implementierungen entsprachen den von Google vorgeschriebenen Richtlinien." Bose beschrieb die Architektur als eine, die nicht-sensible Bezeichner faktisch in Authentifizierungstoken umgewandelt habe und damit eine systemische Schwachstelle in zahlreichen Anwendungen schuf. Diese Formulierung ist es wert, zweimal gelesen zu werden.

Das Einbetten von API-Keys für Maps oder Firebase in clientseitigen Android-Code ist seit einem Jahrzehnt gängige Praxis. Googles eigene Dokumentation hat diese Keys historisch als wenig sensible Bezeichner behandelt, da sie auf spezifische, meist schreibgeschützte oder ratenbegrenzte Dienste beschränkt waren. Kartenkacheln werden geladen, Firebase-Konfigurationen werden gelesen, das Leben geht weiter. Der implizite Vertrag lautete: Das sind öffentliche Bezeichner mit Einschränkungen, keine Bearer-Token.

Dieser Vertrag brach, als dieselben Keys auf Projektebene plötzlich Live-Zugriff auf Gemini ermöglichten. Entwickler, die Apps im Jahr 2022 oder 2023 veröffentlichten, haben sich nicht für ein KI-Abrechnungsrisiko entschieden, und es gibt in der Quelle keinen Hinweis darauf, dass Google Benachrichtigungen oder Opt-in-Aufforderungen verschickt hat, als die Erweiterung erfolgte. Die Zugangsdaten in 22 Produktions-Apps wurden still und heimlich zu etwas Mächtigerem als dem, wofür ihre Autoren sich angemeldet hatten – und die Apps liefern diese Keys weiterhin durch Update-Zyklen aus. Die Schwachstelle kann sich durch App-Updates hindurch fortsetzen, was bedeutet, dass ein Entwickler, der den Key in Version 4.2 ausgetauscht hat, noch immer Installationen von 4.1 hat, die Gemini-Anfragen erzeugen.

Zum Vergleich mit der üblichen Erzählung über Credential-Leaks: Ein Entwickler committet einen AWS-Zugriffsschlüssel auf GitHub, GitGuardian markiert ihn innerhalb von Minuten, AWS widerruft ihn automatisch, der Gesamtschaden ist begrenzt. Dieser Workflow setzt voraus, dass das geleakte Credential immer sensibel war. Hier war das Credential zum Zeitpunkt des Verlusts nicht sensibel. Es wurde rückwirkend sensibel – und kein Erkennungssystem hat auf diesen Übergang geachtet. Die Quelle verrät nicht, ob Google interne Telemetriedaten hat, die ungewöhnliche Gemini-Aufrufmuster von Keys erkennen, die historisch nur Maps- oder Firebase-Endpunkte angesprochen haben – was die offensichtliche Kontrolle wäre, nach der man fragen sollte.

Überprüfbare Prognose: Wenn Google in den nächsten 90 Tagen einen Fix ausliefert, ist zu erwarten, dass dieser die Form einer obligatorischen Trennung auf Projektebene zwischen Legacy-Service-Keys und Gemini-Zugriff annimmt, mit einem expliziten Opt-in-Prozess. Falls nicht, sind bis Q4 Sammelklagen betroffener Entwickler zu erwarten.

Was für Performance-Marketing bereits eingepreist ist

Für Teams, die bezahlte Nutzerakquise betreiben, lautet die relevante Frage, wie sich dies auf die Wirtschaftlichkeit des mobilen App-Traffics auswirkt. App-Install-Kampagnen über die Google Ads API basieren auf Conversion-Daten, die von SDKs zurückfließen, die häufig denselben Projektbereich mit der von CloudSEK untersuchten API-Key-Oberfläche teilen. Der Markt hat das SDK-seitige Credential-Risiko für die Anzeigenmessung bereits eingepreist – deshalb sind serverseitige Conversion-APIs und aggregiertes Reporting seit 2022 die Entwicklungsrichtung. Was nicht eingepreist ist, ist die Vorstellung, dass die SDK-Keys selbst für Kostenangriffe gegen den Publisher eingesetzt werden können – nicht nur zur Datenexfiltration.

Die Implikation für das Performance-Marketing ist konkret. Wer eine durch Anzeigen monetarisierte mobile App betreibt und Firebase- oder Maps-Keys gemäß Googles Empfehlungen einbettet, trägt nun in seiner Einheitswirtschaftlichkeit ein Restrisiko, das unkorreliert mit dem eigenen Traffic ist. Ein einziger Angreifer, der das Gemini-Kontingent leert, kann die monatlichen Werbeausgaben übersteigen, wie der japanische Fall zeigt: 128.000 Dollar sind ein bedeutender Teil des jährlichen Nutzerakquise-Budgets einer mittelgroßen App. CFOs, die LTV gegen CAC modellieren, haben dies nicht eingepreist, weil dieser Angriffsvektor bis vor Kurzem in seiner aktuellen Form nicht existierte.

Was bereits eingepreist ist: die allgemeine Fragilität clientseitiger Credentials, die Notwendigkeit serverseitiger Proxys für teure API-Aufrufe und die Annahme, dass jeder in einem APK enthaltene Key aufzählbar ist. Reife Teams haben sensible Operationen seit Jahren hinter eigene Backends verlagert. Was wirklich überraschend ist: Das Befolgen von Googles dokumentierter Best Practice hat die Schwachstelle erst erzeugt – was bedeutet, dass die übliche Sicherheitsantwort „Lest die Dokumentation sorgfältiger" hier nicht greift.

Die Gegenposition

Die Konsensmeinung wird sein, dass Google das beheben muss und die Entwickler schuldlos sind. Ich würde der Hälfte davon widersprechen. Ja, die Architekturentscheidung, Legacy-Keys ohne Opt-in zu erweitern, liegt bei Google, und Bose hat recht, dass die Implementierungen konform waren. Aber die tiefere Lehre, die die Branche immer wieder verweigert zu verinnerlichen, lautet: Jedes Credential, das in einem Client-Binary ausgeliefert wird, ist ein Credential, das man der Öffentlichkeit übergeben hat. Die Klassifizierung des Anbieters als „sensibel" oder „nicht sensibel" ist eine Gefälligkeit, keine Garantie – denn der Anbieter kann jederzeit ohne Ihre Beteiligung neu klassifizieren.

Client-eingebettete Keys unabhängig von der Bezeichnung in der Dokumentation als Bearer-Token zu behandeln, ist die einzig vertretbare Haltung. Die Teams, die teure Operationen hinter eigenen authentifizierten Backends platziert haben, wurden von diesem Vorfall nicht getroffen und werden auch von der nächsten Variante nicht getroffen. Die Gegenposition lautet: Dieser Vorfall hat weniger mit Gemini zu tun und mehr mit einem wiederkehrenden Versäumnis, für anbieterseitige Richtlinienänderungen zu architekturieren. Erwarten Sie, dass mindestens ein weiterer Cloud-Anbieter dieses Muster innerhalb von 18 Monaten wiederholt – wahrscheinlich mit einem anderen KI-Dienst auf einer zuvor risikoarmen Key-Klasse.

Wichtige Erkenntnisse

• Drei dokumentierte Vorfälle führten zu Verlusten von 15.400 $, 82.314 $ und 128.000 $, wobei der mexikanische Fall einen 455-fachen Anstieg gegenüber dem Basiswert in 48 Stunden darstellt. IP-Beschränkungen auf Firewall-Ebene verhinderten den japanischen Verlust nicht.
• 32 exponierte Keys in 22 Android-Apps mit insgesamt über 500 Mio. Installationen, darunter OYO, Google Pay for Business, Taobao und ELSA Speak, bei der Nutzer-Audiodateien über die Gemini Files API zugänglich waren.
• Die Grundursache ist architektonisch: Keys, die für Maps oder Firebase ausgestellt wurden, erhielten stillschweigend Gemini-Zugriff ohne Benachrichtigung oder Opt-in und wurden so von öffentlichen Bezeichnern zu Authentifizierungstoken.
• Die Verzögerung bei der Google Cloud-Abrechnungserfassung bedeutet, dass selbst eine sofortige Sperrung den Verlust nicht begrenzt. Der Einzelentwickler sperrte innerhalb von Minuten und schuldete dennoch 15.400 $.
• Offene Frage mit überprüfbarer Grenze: Die Quelle gibt nicht preis, wie viele der 32 Keys aktiv missbraucht werden. Liegt die Rate über 25 %, ist mit einer Welle öffentlicher fünfstelliger oder höherer Abrechnungsmeldungen von namentlich genannten Unternehmen bis Ende Q3 2026 zu rechnen.