Thought Leadership
Hacker nutzen gestohlene Google-Cloud-Keys für teure KI-Berechnungen. Automatisierte Limit-Anpassungen führen bei Kunden zu Schäden im fünfstelligen Bereich.
Mehrere Kunden von Google Cloud berichten aktuell über einen Missbrauch ihrer API-Schlüssel durch externe Akteure. Die entwendeten Zugangsdaten wurden laut Betroffenen dazu verwendet, rechenintensive Aufgaben in den Bereichen Bild- und Videogenerierung durchzuführen. Dabei kamen vor allem die hochpreisigen Modelle Nano Banana und Veo 3 zum Einsatz. Die resultierenden Rechnungen belaufen sich teilweise auf fünfstellige US-Dollar-Beträge, während die betroffenen Unternehmen und Entwickler nun um Rückerstattungen kämpfen. Google weist die Verantwortung von sich und verweist auf eine unsachgemäße Handhabung der Sicherheitsvorkehrungen durch die Nutzer.
Gefahren durch öffentlich exponierte Front-End-Schlüssel
Der Ursprung der Problematik liegt nach Einschätzung von Sicherheitsforschern in einer Architekturänderung, die bereits vor längerer Zeit vorgenommen wurde. Ursprünglich wurden API-Schlüssel für Dienste wie Google Maps häufig direkt im Front-End von Webseiten eingebunden. Dies entsprach den offiziellen Dokumentationen von Google, um Widgets wie Umgebungskarten auf Webseiten von Cafés oder Dienstleistern anzuzeigen. Diese Schlüssel sind systembedingt für jeden Besucher der Webseite im Quellcode sichtbar.
Joe Leon, ein Bedrohungsforscher bei Truffle Security Co., warnt bereits seit Anfang des Jahres davor, dass diese ehemals harmlosen Maps-Schlüssel ein neues Gefahrenpotenzial bergen. Google ermöglichte es, dass dieselben API-Schlüssel, die für Kartenfunktionen erstellt wurden, auch für den Zugriff auf leistungsstarke Gemini-Modelle genutzt werden können. Wenn eine Organisation innerhalb eines Projekts die Gemini-API aktiviert, wird der bereits öffentlich genutzte Maps-Schlüssel automatisch zum Generalschlüssel für teure KI-Infrastruktur. Analysen von Millionen Webseiten ergaben, dass tausende dieser Schlüssel, erkennbar am Präfix AIZA, weiterhin ungeschützt im Netz stehen und nun gezielt von Bot-Netzen abgegriffen werden, um KI-Workloads auf fremde Kosten zu betreiben.
Systematische Hochstufung der Ausgabenlimits ohne Rücksprache
Ein besonders kontroverser Punkt in der aktuellen Debatte ist das automatisierte Kontingentsystem von Google Cloud. Viele betroffene Entwickler gaben an, feste Budgetdeckel (Spending Caps) eingerichtet zu haben, die beispielsweise bei 250 US-Dollar lagen. Dennoch wurden ihre Kreditkarten mit Beträgen von über 10.000 US-Dollar belastet. Google bestätigte gegenüber Medienvertretern, dass das System die Limits automatisch anheben kann, um eine Unterbrechung der Dienste bei steigender Nutzung zu verhindern.
Seit einer Richtlinienänderung im März 2026 stuft Google Konten basierend auf ihrem Alter und ihrem bisherigen Zahlungsverlauf in verschiedene Tiers ein. Sobald ein Nutzer über die gesamte Lebensdauer des Kontos mehr als 1.000 US-Dollar ausgegeben hat und das Konto älter als 30 Tage ist, erfolgt ein automatisches Upgrade auf Tier 3. In dieser Stufe werden die Ausgabengrenzen auf Beträge zwischen 20.000 und 100.000 US-Dollar angehoben. Google begründet dies damit, Kunden einen reibungslosen Skalierungsprozess bei wachsender Nutzung zu ermöglichen. Für Opfer von API-Diebstählen bedeutet dies jedoch, dass ihre Sicherheitsmechanismen genau in dem Moment versagen, in dem ein Angreifer die Nutzung künstlich in die Höhe treibt. Das System interpretiert den plötzlichen Anstieg durch Hacker-Aktivitäten als legitimes Wachstum und erhöht das Kreditlimit entsprechend.
Kritische Zeitlücke bei der Überwachung von Echtzeitkosten
Betroffene Nutzer wie der Softwareentwickler Isuru Fonseka berichten zudem von erheblichen Hürden bei der Schadensbegrenzung. Fonseka wurde durch seine Bank über verdächtige Transaktionen informiert, konnte jedoch im Google Cloud Dashboard zunächst keine Details zu den laufenden Kosten einsehen. Laut Google kann es bis zu 36 Stunden dauern, bis Verbrauchsdaten für Techniker und Kunden in der Konsole vollständig sichtbar sind. In dieser Zeitspanne können automatisierte Skripte der Angreifer tausende Anfragen pro Minute generieren, ohne dass der Kontoinhaber die genaue Quelle oder den Umfang der Kosten identifizieren kann.
In einem dokumentierten Fall stiegen die Kosten für einen Kunden innerhalb von nur fünf Minuten um weitere 5.000 US-Dollar, während dieser versuchte, die Quelle des Datenabflusses manuell zu identifizieren. Da die Angreifer Modelle wie Veo 3 zur Videoproduktion nutzen, entstehen pro Sekunde generiertem Material enorme Kosten, die sofort vom hinterlegten Zahlungsmittel abgebucht werden. Google gab an, dass die Zeitspanne von 36 Stunden für die Datenbereitstellung dem Industriestandard entspreche, räumte jedoch ein, dass dies für Kunden in akuten Betrugssituationen die Abwehr erschwere.
Wirtschaftlicher Druck durch drohende Deaktivierung von Diensten
Die betroffenen Unternehmen befinden sich in einer schwierigen Verhandlungsposition. Viele weigern sich, die Rechnungen für den unbefugten Zugriff zu bezahlen, fürchten aber die Konsequenzen einer Rückbuchung über das Kreditkarteninstitut. Da die Geschäftsmodelle vieler Firmen auf Google Cloud Infrastruktur oder spezifischen Google APIs basieren, würde eine Sperrung des Kontos aufgrund von Zahlungsstreitigkeiten den sofortigen Stillstand der eigenen Anwendung bedeuten.
Rod Danan, CEO der Plattform Prentus, erklärte, dass die Abhängigkeit von den Google Maps APIs ihn daran hindere, die Transaktion als betrügerisch zu melden. Ein Verlust des Kontos wäre für sein Unternehmen existenzbedrohend. Google hat in mehreren Fällen Rückerstattungen mit der Begründung abgelehnt, dass keine Anzeichen für einen technischen Fehler in der Google-Infrastruktur vorlägen, sondern die Schlüssel durch die Nutzer selbst im Quellcode exponiert worden seien. Die Kunden tragen somit das finanzielle Risiko für die Sicherheitsarchitektur ihrer eigenen Webseiten.
Erforderliche Restriktionen für Entwickler bei Google Cloud
Google betont, dass es sich um ein branchenweites Problem handle, das nicht spezifisch für ihre Plattform sei. Das Unternehmen empfiehlt Kunden dringend, für verschiedene Dienste unterschiedliche API-Schlüssel zu verwenden. Zudem sollten für browserbasierte Schlüssel zwingend technische Einschränkungen wie HTTP-Referrer, IP-Adressbeschränkungen oder Android-App-IDs hinterlegt werden. Ohne diese Restriktionen kann jeder, der in den Besitz des Schlüssels gelangt, diesen von einem beliebigen Standort aus für jeden verfügbaren Dienst nutzen.
Inzwischen hat Google reagiert und vergibt für neue Gemini-Anbindungen Schlüssel mit dem Präfix AQ, um eine Verwechslung mit alten Maps-Schlüsseln zu vermeiden. Zudem ist es bei neu erstellten Schlüsseln nicht mehr möglich, gleichzeitig Zugriff auf Maps und Gemini innerhalb eines Schlüssels zu gewähren. Für Bestandskunden mit älteren Konfigurationen bleibt das Risiko jedoch bestehen, sofern sie ihre Sicherheitseinstellungen nicht manuell an die neuen Gegebenheiten anpassen. Der Fall verdeutlicht die Notwendigkeit einer strikten Trennung zwischen öffentlichen Front-End-Funktionen und kostspieligen Back-End-KI-Diensten.
