Wie gefährlich war die Lücke in Azure Cosmos DB?

Ein einzelner Signaturschlüssel in Azure Cosmos DB genügte, um den Primärschlüssel jedes Kundenkontos abzurufen, über Regionen, Mandanten und Schnittstellen hinweg. Microsoft hat die Kette unterbrochen und verlangt von Kunden keine Maßnahme. Von der Lücke wussten Kunden 252 Tage lang nichts, und handeln konnten sie in dieser Zeit auch nicht.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Am 20. November 2025 meldeten Forscher des Sicherheitsanbieters Wiz eine Fehlerkette in Azure Cosmos DB an Microsoft, zwei Tage später sperrte eine Notabhilfe den Einstiegspunkt. Der Umbau der Architektur zog sich bis Juli 2026 hin. Öffentlich gemacht haben die Forscher den Befund erst am 30. Juli 2026, unter dem Namen CosmosEscape.

Das Wichtigste in Kürze

Eine präparierte Gremlin-Abfrage brach aus der Sandbox des Datenbank-Gateways aus.
Der dort abgegriffene Signaturschlüssel lieferte den Primärschlüssel jedes Cosmos-DB-Kontos, unabhängig von Region, Mandant und Schnittstelle.
Netzwerkisolierte Konten blieben ebenfalls erreichbar, weil das Gateway die Isolierung selbst durchsetzt.
Microsoft fand keine Spuren einer Ausnutzung außerhalb der Forschungsarbeit und hat den Generalschlüssel inzwischen abgeschafft.

Wie kam eine Datenbankabfrage an den Generalschlüssel?

Hakenleiste mit 12 Haken; am Haken 11 ein Schlüssel mit orangem Anhänger und beschriftetem Etikett — Azure Cosmos DB: Sicherheitslücke in Gremlin-Abfragesprache ermöglichte Codeausführung via .NET-Reflection

Gremlin heißt die Graph-Abfragesprache, die Azure Cosmos DB neben SQL, MongoDB und Cassandra anbietet. Der Dienst übersetzt solche Abfragen in kompilierten .NET-Code und sperrt ihn in eine Sandbox. In dieser Absicherung fehlte der Schutz gegen die Reflection-Mechanismen von .NET, und darüber führten die Wiz-Forscher eigene Befehle auf dem Datenbank-Gateway aus.^[1]

Der Cosmos Master Key lag am Ende dieser Kette. Über diesen Signaturschlüssel ließ sich der Primärschlüssel jedes beliebigen Kontos anfordern, gültig für alle Regionen, Mandanten und Schnittstellen. Ein Konfigurationsspeicher, selbst eine Cosmos-Datenbank, nannte dazu Kontonamen sowie Abonnement- und Mandanten-IDs sämtlicher Konten einer Region.

Zielgenau wurde der Angriff durch diese Kombination: Der Konfigurationsspeicher zeigt, welche Datenbank zu welcher Organisation gehört, der Primärschlüssel öffnet dieses Konto über den öffentlich erreichbaren Endpunkt. Auf Cosmos DB laufen auch Microsoft-Dienste wie Entra ID, Teams und Copilot.

Warum half die Netzwerkisolierung nicht?

Private Endpunkte boten keinen Schutz. Das Datenbank-Gateway setzt die Netzwerkisolierung selbst durch, und nach dem Ausbruch saßen die Forscher bereits hinter dieser Grenze. Damit verliert eine Maßnahme ihre Wirkung, die in vielen Schutzkonzepten ganz oben steht, gleich neben der Kontrolle über den Entschlüsselungspunkt.

Zum zweiten Mal traf Wiz denselben Dienst. Im August 2021 brach dasselbe Team unter dem Namen ChaosDB über die Jupyter-Notebook-Funktion in fremde Cosmos-Konten ein; Microsoft bat danach alle Kunden, ihre Schlüssel neu zu erzeugen.^[2] Den Anteil der direkt benachrichtigten Kunden beziffert Wiz auf rund 30 Prozent.

Ein Muster reicht über Cosmos DB hinaus. 2023 fälschte die Gruppe Storm-0558 mit einem erbeuteten MSA-Signaturschlüssel Zugangstoken für Exchange Online und las die Postfächer von 22 Organisationen mit; das amerikanische Cyber Safety Review Board nannte Microsofts Sicherheitskultur im März 2024 unzureichend.^[3] Plattformweite Generalschlüssel bilden bei Microsoft ein wiederkehrendes Bauprinzip. Still im Hintergrund geschlossene Lücken sind dagegen branchenüblich, zuletzt bei einem GitLab-Patch ohne eigene CVE-Nummer.

CosmosEscape in Zahlen

Vom Ausbruch aus der Abfrage-Sandbox bis zum Generalschlüssel für jede Kundendatenbank

48 Stunden

vergingen zwischen der Meldung am 20. November 2025 und der ersten Notabhilfe, die den Einstiegspunkt sperrte.

252 Tage

lagen zwischen der Meldung und der Offenlegung am 30. Juli 2026. In dieser Zeit erfuhren Kunden nichts von dem Befund.

4 Schnittstellen

deckte der Generalschlüssel gleichzeitig ab: SQL, MongoDB, Cassandra und Gremlin, dazu jede Region und jeden Mandanten.

Die Angriffskette in drei Stationen

Station 1

Ausbruch aus der Sandbox

Eine präparierte Gremlin-Abfrage nutzt eine Lücke in der Reflection-Absicherung des erzeugten .NET-Codes und führt fremde Befehle auf dem Datenbank-Gateway aus.

Station 2

Generalschlüssel abgreifen

Auf dem Gateway liegt ein Signaturschlüssel, über den sich der Primärschlüssel jedes beliebigen Cosmos-DB-Kontos anfordern lässt.

Station 3

Ziele auswählen

Ein Konfigurationsspeicher nennt Kontonamen sowie Abonnement- und Mandanten-IDs aller Konten einer Region und macht die Suche nach einer bestimmten Organisation trivial.

Derselbe Dienst, zweiter Fund

ChaosDB, August 2021

Über die Jupyter-Notebook-Funktion erreichten dieselben Forscher fremde Primärschlüssel. Microsoft schaltete die Funktion ab und bat alle Kunden, ihre Schlüssel neu zu erzeugen.

CosmosEscape, Juli 2026

Der Weg führt diesmal über die Gremlin-Schnittstelle. Microsoft hat den Generalschlüssel abgeschafft, fand keine Spuren einer Ausnutzung und verlangt von Kunden keine Maßnahme.

Microsoft hat den Generalschlüssel aus Azure Cosmos DB entfernt, doch 252 Tage lang bestand er weiter, ohne dass ein einziger Kunde davon wusste. Diese Zeitspanne zwischen Meldung und Offenlegung gehört in jede Cloud-Risikobewertung.
— Markus Seyfferth, Chefredakteur Dr. Web

Was folgt daraus für Cloud-Verantwortliche im DACH-Raum?

NIS2 verpflichtet wesentliche und wichtige Einrichtungen, die Sicherheit ihrer Lieferkette zu dokumentieren, und macht die Geschäftsführung dafür persönlich haftbar. Einen Hyperscaler kann kein Kunde selbst prüfen, deshalb tritt in Deutschland das C5-Testat des BSI an diese Stelle, mit 121 Anforderungen in 17 Themenbereichen. CosmosEscape markiert die Grenze dieses Ersatzes: Ein Testat prüft Prozesse und Kontrollen, keine unentdeckte Reflection-Lücke im Abfrage-Compiler.

Schlüsselbasierte Anmeldung gehört danach auf den Prüfstand. Cosmos DB lässt sich über die Kontoeigenschaft disableLocalAuth vollständig auf Microsoft Entra ID umstellen, womit statische Primärschlüssel als Anmeldeweg entfallen.^[4] Ein statischer Schlüssel ohne zweiten Faktor und ohne bedingten Zugriff war genau der Wert, den der Angriff erbeutete, und damit das schwächste Glied jeder Strategie zum Schutz von Daten in der Cloud.

Protokolle entscheiden im Ernstfall über die Beweislage. Microsoft fand keine Spuren einer Ausnutzung, doch dieser Befund stützt sich auf Microsofts eigene Zugriffsprotokolle; für den Nachweis gegenüber der Aufsichtsbehörde helfen nur die Diagnoseeinstellungen des Kontos, deren Daten über die Meldefristen hinaus aufbewahrt werden.

Konkret heißt das für IT-Verantwortliche: die eigenen Cosmos-DB-Konten auf Entra ID umstellen und vorhandene Primärschlüssel rotieren. In die nächste Lieferantenbewertung gehört zusätzlich die Frage, wie lange ein Anbieter eine bekannte Lücke offen hält und ab wann er betroffene Kunden informiert. Den Rahmen davor beschreiben unsere Cybersecurity-Grundlagen für den Mittelstand.