Eine kritische Schwachstelle in Googles Cloud-Infrastruktur zeigt, wie schnell sich Sicherheitsannahmen ändern können: Über 2.800 öffentliche API-Keys, manche seit Jahren im Einsatz, gewähren plötzlich unautorisierten Zugriff auf Gemini AI-Endpoints – inklusive privater Dateien, gecachter Daten und unbegrenzter Billing-Rechte.
Das Problem: Alte Regeln, neue Privilegien
Über ein Jahrzehnt lang lautete Googles offizielle Empfehlung: API-Keys im Format AIza... sind keine Secrets und können bedenkenlos in Client-seitigem HTML und JavaScript eingebettet werden. Firebase-Dokumentation bezeichnete sie explizit als "nicht geheim", Google Maps forderte Entwickler auf, Keys direkt in Webseiten zu kopieren.
Diese Keys waren als Projekt-Identifikatoren für Billing konzipiert, nicht als Authentifizierungs-Credentials. Doch diese Anleitung ist heute gefährlich veraltet.
Die Privilege Escalation: Wenn die Gemini API (Generative Language API) auf einem Google Cloud-Projekt aktiviert wird, erhalten alle existierenden API-Keys in diesem Projekt sofort Zugriff auf sensitive Gemini-Endpoints – ohne Warnung, ohne Bestätigungsdialog, ohne E-Mail-Benachrichtigung an den Entwickler.
Ein Key, der vor drei Jahren deployed wurde, um eine Maps-Integration zu rendern, kann über Nacht zum Live-Credential mit Zugriff auf hochgeladene AI-Dateien, gecachte Kontexte und abrechnungsfähige Inference-Services werden.
2.863 vulnerable Keys im offenen Netz
Forscher von Truffle Security durchsuchten das Common Crawl-Dataset vom November 2025 – ein 700 TiB großes Archiv öffentlich gescrapeter Web-Inhalte – und identifizierten 2.863 live Google API-Keys, die für diesen Angriffsvektor anfällig sind.
Betroffene Organisationen:
- Major Financial Institutions
- Security-Firmen
- Globale Recruiting-Unternehmen
- Google selbst – mindestens ein Key auf einer Google-Produktwebsite, deployed seit Februar 2023 (vor Gemini), hatte plötzlich vollen Gemini-Zugriff
Der Angriff benötigt null Infrastruktur-Zugriff: Ein Angreifer besucht eine öffentliche Website, extrahiert den AIza...-Key aus dem Seitenquelltext und fragt direkt die Gemini API ab:
curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"
Eine erfolgreiche Antwort (200 OK) gewährt Zugriff auf:
1. Private Daten:
/files/und/cachedContents/-Endpoints können hochgeladene Datasets, Dokumente und gespeicherte AI-Kontexte offenlegen
2. Financial Damage:
- Angreifer können Gemini API-Quotas erschöpfen
- Tausende Dollar täglicher Charges auf das Billing-Konto des Opfers generieren
3. Service-Disruption:
- Quota-Exhaustion kann Gemini-basierte Services komplett lahmlegen
Warum das eine Privilege Escalation ist
Das Sicherheitsproblem liegt in der Reihenfolge der Ereignisse:
- Entwickler folgt Googles Anleitung und platziert Maps API-Key in öffentlichem JavaScript
- Monate/Jahre später aktiviert ein anderes Team-Mitglied die Gemini API auf demselben Cloud-Projekt
- Der öffentliche Key erhält sofort Zugriff auf sensitive Gemini-Endpoints
- Der ursprüngliche Entwickler wird nie benachrichtigt
Diese Konstellation erfüllt zwei anerkannte Schwachstellen-Kategorien:
- CWE-1188: Insecure Default Initialization
- CWE-269: Incorrect Privilege Assignment
Google Cloud-API-Keys sind standardmäßig auf "Unrestricted" gesetzt – sie können jeden enabled API im Projekt zugreifen, einschließlich Gemini, ab dem Moment der Erstellung.
Googles Reaktion: Remediation in Arbeit
Google hat einen Remediation-Roadmap skizziert:
Geplante Fixes:
- Scoped Defaults für AI Studio-Keys (nur Gemini-Zugriff per Default)
- Automated Blocking geleakter Keys, die "in the wild" entdeckt werden
- Proactive Notifications an Entwickler bei identifizierten exponierten Keys
Allerdings: Die Root-Cause-Behebung war zum Disclosure-Datum noch in Arbeit. Keine Bestätigung eines vollständigen architektonischen Fixes liegt vor.
Was Entwickler sofort tun sollten
Jede Organisation, die Google Cloud-Services nutzt – Maps, Firebase, YouTube Data API oder andere – sollte jetzt handeln:
1. Audit aller GCP-Projekte:
- Navigiere zu APIs & Services > Enabled APIs
- Prüfe auf "Generative Language API" in jedem Projekt
2. API-Key-Konfigurationen inspizieren:
- Flag alle unrestricted Keys
- Flag Keys mit explizitem "Generative Language API"-Permission
3. Verifiziere: Keine Keys sind public:
- Durchsuche Client-side JavaScript
- Prüfe public Repositories
- Scanne CI/CD-Pipelines nach
AIza...-Strings
4. Rotiere alle exponierten Keys sofort:
- Priorisiere ältere Keys, deployed unter der alten "Keys sind safe to share"-Guidance
5. Nutze TruffleHog für Scanning:
trufflehog filesystem /path/to/your/code --only-verified
Erkennt live, verifizierte Gemini-zugängliche Keys in Codebasen.
Investment-Perspektive: Strukturelles AI-Sicherheitsrisiko
Dieser Vorfall zeigt ein strukturelles Problem, das weit über Google hinausgeht: Wenn AI-Capabilities auf existierende Plattformen aufgesetzt werden, erweitert sich die Attack Surface für Legacy-Credentials in Weisen, die ursprünglich niemand antizipierte.
Für Alphabet ($GOOGL):
- Reputationsrisiko: Betroffene inkludieren Major Financial Institutions und Security-Firmen
- Trust-Erosion: "API Keys sind safe to share" war offizielle Guidance – jetzt gefährlich veraltet
- Compliance-Risiko: Unbemerkter Zugriff auf private Daten, potenzielle GDPR/DSA-Implikationen
Breiterer Trend: Das Muster – öffentliche Identifiers gewinnen plötzlich sensitive AI-Privilegien – ist unwahrscheinlich unique zu Google. Jede Plattform, die AI-Features auf Legacy-Infrastruktur bolted, faces similar risks.
Investment-Implikation:
- Cybersecurity Pure-Plays profitieren: Secrets Management (HashiCorp/VLTW, CyberArk/CYBR), API Security (Salt Security), Code Scanning (GitHub/MSFT, GitLab/GTLB)
- Hyperscaler unter Druck: Azure, AWS, Google Cloud müssen AI-Sicherheit nachbessern – Capex-Belastung
- Enterprise Trust-Frage: Wer sichert AI-Endpoints besser? Proprietäre Lösungen (Microsoft, Google) vs. Open-Source-Kontrolle?
Fazit: Die Kehrseite des AI-Booms
Gemini, Claude, GPT – die generative AI-Welle treibt Revenue-Growth bei den Hyperscalern. Doch diese Sicherheitslücke zeigt: Geschwindigkeit schlägt Sicherheit.
Googles alte "Keys aren't secrets"-Guidance kollidiert mit der neuen Realität hochsensibler AI-Endpoints. 2.863 vulnerable Keys, darunter Googles eigene, sind das Symptom eines breiteren Problems: Legacy-Infrastruktur + AI = unvorhergesehene Risiken.
Für Investoren bedeutet das: Cybersecurity-Pure-Plays bleiben strukturelle Gewinner. Für Entwickler: Audit now, rotate fast, restrict by default.
Quellen:
- Truffle Security: "Google API Keys weren't secrets, but then Gemini changed the rules"
- Cyber Security News, 27.02.2026
- CWE-1188, CWE-269 (MITRE)
