Kritische Google-Cloud-Lücke: Warum Mandantentrennung eine Vertrauensfrage bleibt
BRANDNEU · veröffentlicht am 14.07.2026
Öffentliche Bekanntgabe: 13.07.2026
Behebung durch Google: 10.05.2026
Kritische Schwachstelle in drei Google-Cloud-Diensten
Google hat am 13. Juli 2026 eine kritische Sicherheitslücke in den Repository-Funktionen von BigQuery, Dataform und Colab Enterprise veröffentlicht. Die Schwachstelle wird unter der Kennung CVE-2026-14934 geführt und ist im Google Cloud Security Bulletin GCP-2026-047 dokumentiert.
Nach Angaben von Google fehlte bei der Erstellung eines Repositorys eine erforderliche Berechtigungsprüfung. Ein bereits authentifizierter Angreifer hätte dadurch möglicherweise seine vorhandenen Rechte ausweiten und ein Repository aus der Umgebung eines anderen Cloud-Kunden übernehmen können. Google bewertet die Schwachstelle als kritisch. Die von Google gemeldete Bewertung nach CVSS 4.0 liegt bei 9,4 von maximal 10 Punkten.
Der Angreifer musste bereits über ein gültiges Benutzerkonto verfügen. Die Gefahr bestand jedoch darin, dass aus einem begrenzten Zugang ein Zugriff auf Ressourcen eines anderen Google-Cloud-Mandanten werden konnte.
Nach den Angaben im CVE-Datensatz waren Versionen der betroffenen Dienste zwischen Oktober 2025 und dem 10. Mai 2026 verwundbar. Google schloss die Lücke am 10. Mai. Öffentlich bekannt gemacht wurde sie erst am 13. Juli 2026. Kunden müssen laut Google weder Updates installieren noch Einstellungen verändern, da die Schutzmaßnahmen zentral in allen betroffenen Diensten ausgerollt wurden.
Was ist mit einem Repository gemeint?
Der Begriff Repository wird häufig mit Plattformen wie GitHub oder GitLab verbunden. Im vorliegenden Fall geht es jedoch um Repository-Funktionen innerhalb von Google Cloud.
BigQuery-Repositorys dienen unter anderem dazu, SQL-Abfragen, Notebooks und weitere Dateien für die Datenanalyse zu verwalten. Sie bieten eine Versionsverwaltung, gemeinsame Arbeitsbereiche und die Möglichkeit, Änderungen zurückzuverfolgen. Die Repositorys können entweder die integrierten Git-Funktionen von Google verwenden oder mit einem externen Git-Repository verbunden werden.
Dataform wird genutzt, um Datenverarbeitungen und Transformationen vor allem auf Grundlage von SQL zu entwickeln und zu automatisieren. Definitionen von Tabellen, Abhängigkeiten, Datenprüfungen und weitere Bestandteile einer Datenpipeline können dabei gemeinsam in einem Repository liegen.
Colab Enterprise ist eine von Google verwaltete Notebook-Umgebung für Datenanalyse, Programmierung und künstliche Intelligenz. In solchen Notebooks können Programmcode, erklärende Texte, Abfragen und deren Ergebnisse miteinander verbunden werden.
Die Sicherheitsmeldung betrifft damit nicht Gmail, Google Drive oder gewöhnliche Dokumente in Google Workspace. Betroffen waren ausdrücklich die Repository-Funktionen von BigQuery, Dataform und Colab Enterprise.
Warum eine Repository-Übernahme gefährlich sein kann
Ein Repository enthält nicht zwangsläufig die eigentlichen Unternehmensdaten. Trotzdem kann es für einen Angreifer äußerst wertvoll sein.
Darin können SQL-Abfragen, Datenmodelle, Namen von Datenbanken und Tabellen, technische Konfigurationen, Automatisierungsabläufe oder Hinweise auf weitere Cloud-Ressourcen gespeichert sein. In Entwicklungsumgebungen finden sich außerdem gelegentlich Zugangsdaten, API-Schlüssel oder andere Geheimnisse, obwohl diese dort grundsätzlich nicht abgelegt werden sollten.
Wer ein Repository kontrolliert, könnte möglicherweise vorhandene Dateien lesen, Entwicklungslogik verändern oder schädliche Änderungen vorbereiten. Abhängig von den angebundenen Diensten und den vergebenen Berechtigungen könnte eine manipulierte Datenverarbeitung später auch Auswirkungen auf Tabellen, Berichte oder automatisierte Abläufe haben.
Die CVSS-Bewertung von 9,4 berücksichtigt hohe mögliche Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit sowohl innerhalb der betroffenen Umgebung als auch auf nachgelagerte Systeme. Das bedeutet allerdings nicht, dass Google eine tatsächliche Übernahme oder einen konkreten Datendiebstahl bestätigt hat. Es beschreibt das technisch mögliche Schadenspotenzial der Schwachstelle.
Mandantentrennung ist eine unsichtbare Sicherheitsgrenze
Bei einem öffentlichen Cloud-Dienst teilen sich zahlreiche Unternehmen die technische Plattform des Anbieters. Ihre Projekte, Benutzer und Daten sollen durch eine konsequente Mandantentrennung voneinander isoliert bleiben.
Für den Kunden ist diese Grenze kaum sichtbar. Er kann seine eigenen Benutzerkonten schützen, Mehrfaktor-Authentifizierung einsetzen und Berechtigungen sparsam vergeben. Ob der Cloud-Dienst bei jeder internen Anfrage tatsächlich kontrolliert, zu welchem Kunden eine Ressource gehört, kann er jedoch nicht selbst überprüfen.
Ein Unternehmen kann seine eigene Rechteverwaltung korrekt eingerichtet haben und trotzdem von einem Fehler in der Berechtigungsprüfung des Cloud-Anbieters betroffen sein.
Genau darin liegt die Bedeutung von CVE-2026-14934. Der Angriff hätte nicht einfach nur eine zu großzügig vergebene Kundenberechtigung ausgenutzt. Die Schwachstelle befand sich in der Plattform und hätte möglicherweise die eigentlich vorgesehene Trennung zwischen unterschiedlichen Cloud-Mandanten überwinden können.
Das ist kein ausschließliches Google-Problem. Vergleichbare Risiken bestehen grundsätzlich bei allen gemeinsam genutzten Cloud-Plattformen. Je mehr technische Aufgaben ein Anbieter übernimmt, desto stärker müssen Kunden darauf vertrauen, dass dessen interne Berechtigungsprüfungen, Protokollierung und Sicherheitsprozesse funktionieren.
Warum die zentrale Reparatur zugleich ein Vorteil ist
Die Meldung zeigt nicht nur einen Nachteil verwalteter Cloud-Dienste. Sie macht auch deren praktischen Vorteil sichtbar.
Google konnte die Lücke zentral schließen, ohne dass Kunden Softwarepakete installieren, Server neu starten oder einzelne Systeme aktualisieren mussten. Laut Google sind alle erforderlichen Schutzmaßnahmen bereits in den betroffenen Produkten und Diensten aktiv.
Bei einer selbst betriebenen Anwendung müsste das Unternehmen oder sein IT-Dienstleister zunächst von der Schwachstelle erfahren, die betroffenen Installationen identifizieren und anschließend den Patch einspielen. Verzögerungen bei Updates könnten die verwundbare Zeit erheblich verlängern.
Die Cloud nimmt dem Kunden die technische Aktualisierung ab. Gleichzeitig nimmt sie ihm aber auch die Kontrolle darüber, wann eine Schwachstelle erkannt, behoben und öffentlich gemacht wird.
Die Lücke wurde am 10. Mai 2026 geschlossen, aber erst am 13. Juli öffentlich beschrieben. Für Kunden bedeutet dies, dass sie während dieses Zeitraums zwar bereits geschützt waren, von der vorherigen Gefährdung ihrer Umgebung aber noch nichts wussten.
Müssen Google-Cloud-Kunden jetzt etwas unternehmen?
Ein Update oder eine besondere Konfigurationsänderung ist nach Angaben von Google nicht notwendig. Unternehmen, die BigQuery, Dataform oder Colab Enterprise einsetzen, sollten die Meldung trotzdem nicht einfach abhaken.
Sinnvoll ist eine nachträgliche Prüfung der Cloud-Protokolle für den Zeitraum von Oktober 2025 bis zum 10. Mai 2026. Dabei sollten insbesondere unerwartete Repository-Erstellungen, Änderungen an Repositorys, neue Berechtigungen und Aktivitäten unbekannter oder ungewöhnlicher Benutzerkonten betrachtet werden.
Dataform protokolliert die Erstellung eines Repositorys beispielsweise als administrative Aktivität unter der Methode CreateRepository. Auch Änderungen an Berechtigungen über SetIamPolicy, Aktualisierungen von Repositorys und weitere administrative Vorgänge können über die Audit-Protokolle ausgewertet werden. Google empfiehlt für die Untersuchung von IAM-Änderungen ebenfalls die Suche nach Einträgen mit der Methode SetIamPolicy.
Keine Updatepflicht bedeutet nicht automatisch, dass eine nachträgliche Kontrolle wertlos ist. Der Anbieter hat die technische Ursache behoben – die Bewertung der eigenen Protokolle und Daten bleibt Aufgabe des Unternehmens.
Wer die betroffenen Dienste nicht verwendet, ist von dieser konkreten Schwachstelle nicht betroffen. Unternehmen sollten deshalb zunächst klären, ob BigQuery-Repositorys, Dataform oder Colab Enterprise in eigenen Projekten, durch externe Entwickler oder durch beauftragte Daten- und KI-Dienstleister eingesetzt werden.
Zugangsdaten gehören nicht in Repositorys
Ein Repository sollte grundsätzlich so behandelt werden, als könnte sein Inhalt eines Tages versehentlich freigegeben oder durch eine Sicherheitslücke eingesehen werden.
Passwörter, API-Schlüssel, private Schlüssel und andere Zugangsdaten gehören deshalb nicht direkt in SQL-Dateien, Notebooks oder Konfigurationsdateien. Stattdessen sollten zentrale Geheimnisverwaltungen verwendet und Zugriffsrechte auf das notwendige Minimum begrenzt werden.
Bei angebundenen externen Git-Repositorys empfiehlt Google unter anderem die Verwendung eines eigenen technischen Kontos, dessen Zugriff auf die tatsächlich benötigten Repositorys beschränkt wird. Google weist außerdem darauf hin, dass bestimmte private Schlüssel oder Zugriffstoken innerhalb eines Projekts von mehreren entsprechend berechtigten Nutzern verwendet werden können.
Falls ein Unternehmen feststellt, dass Zugangsdaten unverschlüsselt in einem betroffenen Repository gespeichert waren und verdächtige Zugriffe nicht ausgeschlossen werden können, sollten diese Zugangsdaten ausgetauscht werden. Ein pauschaler Austausch sämtlicher Schlüssel ist aufgrund der Meldung allein jedoch nicht von Google vorgeschrieben.
Was kleine Unternehmen daraus lernen können
Viele kleine Unternehmen werden BigQuery, Dataform oder Colab Enterprise nicht unmittelbar einsetzen. Die Dienste können aber indirekt durch Softwareanbieter, Agenturen, externe Datenanalysten oder KI-Dienstleister genutzt werden.
Deshalb reicht es bei der Auswahl eines Cloud-Dienstleisters nicht aus, nur nach dem Standort des Rechenzentrums und dem Preis zu fragen. Unternehmen sollten auch wissen, welche Unterauftragnehmer und Plattformdienste eingesetzt werden, wo Protokolle verfügbar sind und wer im Sicherheitsfall für deren Auswertung zuständig ist.
Eine sinnvolle Cloud-Berechtigungsprüfung betrachtet nicht nur einzelne Benutzerkonten. Sie untersucht auch technische Konten, angebundene Anwendungen, externe Git-Verbindungen, vererbte Rollen und die Frage, welche Person administrative Änderungen nachvollziehen kann.
Cloud-Sicherheit besteht nicht nur aus einem sicheren Passwort. Sie benötigt nachvollziehbare Berechtigungen, auswertbare Protokolle, eine Klassifizierung der gespeicherten Informationen und einen Plan für den Ausfall oder Wechsel eines Anbieters.
Eine Exit-Strategie ist keine sofortige Flucht aus der Cloud
Die aktuelle Schwachstelle ist kein Beleg dafür, dass Unternehmen Google Cloud überstürzt verlassen sollten. Sie ist aber ein guter Anlass, die eigene Abhängigkeit realistisch zu bewerten.
Eine Exit-Strategie beschreibt, wie Daten, Repositorys, Konfigurationen und Entwicklungslogik exportiert und in eine andere Umgebung übertragen werden könnten. Dazu gehören dokumentierte Datenformate, unabhängige Sicherungen, bekannte Schnittstellen und das Wissen darüber, welche Bestandteile ausschließlich innerhalb des Cloud-Dienstes funktionieren.
Bei Repositorys ist eine zusätzliche Version in einem unabhängig kontrollierten Git-System besonders wertvoll. Eine solche Kopie schützt nicht automatisch vor allen Angriffen, reduziert aber das Risiko, dass Quelltexte und Entwicklungsstände nur innerhalb eines einzigen Anbieters verfügbar sind.
Eine Exit-Strategie bedeutet deshalb nicht, dass der Anbieter unmittelbar gewechselt werden muss. Sie sorgt dafür, dass ein Wechsel technisch und wirtschaftlich überhaupt möglich bleibt.
Cloud-Sicherheit bleibt geteilte Verantwortung
CVE-2026-14934 zeigt die Grenzen des bekannten Prinzips der geteilten Verantwortung.
Unternehmen bleiben für ihre Benutzerkonten, Rollen, gespeicherten Inhalte und die Auswertung ihrer Protokolle verantwortlich. Der Cloud-Anbieter trägt dagegen die Verantwortung für die Sicherheit der Plattform, ihrer internen Programmlogik und der Trennung zwischen verschiedenen Kunden.
In diesem Fall lag der Fehler auf der Seite des Anbieters und konnte auch nur dort behoben werden. Google hat die Lücke zentral geschlossen, bevor sie öffentlich bekannt gemacht wurde. Das schnelle und kundenunabhängige Ausrollen der Schutzmaßnahmen ist eine Stärke verwalteter Dienste. Die fehlende Einsicht in den Zeitpunkt der Entdeckung und in die internen Plattformprozesse bleibt gleichzeitig eine Abhängigkeit.
Die entscheidende Frage lautet deshalb nicht, ob Cloud-Dienste grundsätzlich sicher oder unsicher sind. Unternehmen müssen wissen, welche Risiken sie selbst kontrollieren können – und an welchen Stellen sie vollständig auf die Sicherheitsarchitektur ihres Anbieters vertrauen müssen.
Fazit
Die kritische Google-Cloud-Lücke ermöglichte möglicherweise eine Rechteausweitung über die Grenze verschiedener Kundenumgebungen hinweg. Betroffen waren Repository-Funktionen in BigQuery, Dataform und Colab Enterprise. Google schloss die Schwachstelle bereits am 10. Mai 2026 und veröffentlichte die Details am 13. Juli. Aktuell müssen Kunden weder Updates installieren noch Einstellungen verändern.
Unternehmen, die die betroffenen Dienste einsetzen, sollten dennoch ihre Audit-Protokolle prüfen, gespeicherte Zugangsdaten kontrollieren und ihre Berechtigungsstruktur nachvollziehen. Gleichzeitig lohnt sich die grundsätzliche Frage, ob wichtige Repositorys, Konfigurationen und Entwicklungsstände auch unabhängig vom jeweiligen Cloud-Anbieter gesichert werden.
Denn Mandantentrennung ist für den Kunden kaum sichtbar. Ob sie zuverlässig funktioniert, bleibt am Ende eine Vertrauensfrage.
Mehr aus dieser Kategorie
Dieses Bild ist AI generated. 
Dieses Bild ist AI generated. 
Dieses Bild ist AI generated. 
Dieses Bild ist AI generated. 
Dieses Bild ist AI generated.