Eine kritische Sicherheitslücke in Azure Cosmos DB hätte Angreifern theoretisch erlaubt, Datenbanken im gesamten Dienst zu kompromittieren. Das berichtet die Cybersecurity-Firma Wiz. Die Schwachstelle trägt den Namen CosmosEscape und zielte darauf ab, Schlüssel zu erlangen, die eine vollständige Lese- und Schreibberechtigung über die Plattform ermöglicht hätten.
Wiz beschreibt dabei ein Angriffsszenario, das sich über öffentlich erreichbare Schnittstellen realisieren lassen könnte und eine präzise Zielauswahl auf Ebene einzelner Organisationen erlaubt. Microsoft hat nach eigenen Angaben zunächst einen Hotfix und später eine langfristige technische Lösung ausgerollt.
Was die CosmosEscape Lücke technisch ermöglicht
Im Kern geht es bei der CosmosEscape Lücke um das Potenzial, einen plattformweiten Schlüssel zu erhalten. Mit diesem hätten Angreifer den Primary Key beliebiger Cosmos-DB-Konten extrahieren können. Gelingt das, entsteht für den Angreifer ein Zugang, der laut Wiz vollständige Lese- und Schreibrechte über alle Datenbanken im jeweiligen Cosmos-DB-Konto umfasst.
Darüber hinaus lässt sich der Zugriff laut Wiz nicht nur „blind“, sondern gezielt strukturieren: Der Angreifer könnte alle Datenbanken auflisten und anschließend nach Organisationsmerkmalen filtern. Genannt werden insbesondere Subscription- und Tenant-IDs.
Wiz fasst das als Möglichkeit zusammen, Angriffe „auf Plattformskalierung“ mit hoher Genauigkeit durchzuführen: von der Identifikation relevanter Datenbanken bis zur tatsächlichen Kompromittierung – basierend auf öffentlich zugänglichen Endpunkten.
Warum die Reichweite für Microsoft besonders groß wirkt
Wiz argumentiert, dass die Auswirkungen auch Microsoft selbst betreffen könnten. Hintergrund: Microsoft nutzt Cosmos DB, um Daten über mehrere Dienste hinweg zu speichern, darunter Entra ID, Teams und Copilot. Wenn eine Schwachstelle Zugriff auf plattformweite Schlüssel und Primärschlüssel ermöglicht, rückt damit auch die Frage in den Fokus, ob Angreifer auf Daten hinter diesen Diensten hätten zugreifen können.
Wichtig ist: Wiz beschreibt die Schwachstelle als potenziell kritisch. Microsoft teilte anschließend mit, dass es keine Hinweise auf unbefugte Aktivitäten außerhalb der Tests des Forschungsteams gab und dass keine Kundendaten erreicht wurden.
Angriff über die Gremlin API
Der von Wiz beschriebene Weg zur Ausnutzung führt über die Gremlin API. Dabei handelt es sich um eine beliebte Graph-Abfragesprache. Cosmos DB setzt dafür eine eigene Gremlin-Engine ein, die Abfragen in .NET-Code übersetzt und anschließend in einer Sandbox ausführt.
Diese Sandbox soll den Zugriff eigentlich auf Gremlin-spezifische Operationen begrenzen. Laut Wiz reichte diese Schutzannahme jedoch nicht aus, weil .NET Reflection nicht zuverlässig berücksichtigt wurde. Genau diese Lücke erlaubte es, „primitive“ Bausteine für beliebige Codeausführung zu konstruieren.
Sandbox umgehen und Code auf dem DB Gateway ausführen
Wiz beschreibt, dass die Forscher die Gremlin-Sandbox umgehen konnten. Dadurch gelangten sie zu Codeausführung im DB Gateway. Dieses Gateway ist dafür zuständig, Kundenabfragen im Auftrag der Nutzer auszuführen. Es läuft laut Bericht auf multi-tenant Service Fabric-Clustern, also einer Infrastruktur, die mehrere Mandanten gemeinsam nutzt.
Die nächste Hürde betrifft dann die Frage, ob aus dieser Codeausführung heraus auch wirklich sensible Schlüssel verfügbar werden. Wiz sagt: Die Gateway-Komponente verwendete einen Signing Key, um die Primary Keys von Kundenkonten abzurufen. Besonders problematisch war dabei, dass dieser Signing Key über Tenants, Regionen und sogar APIs hinweg funktionierte.
Wiz bezeichnete diesen plattformweit nutzbaren Schlüssel später als „Cosmos Master Key“. Über öffentlich erreichbare Endpunkte hätte damit der Primary Key für jedes Cosmos-DB-Konto im Dienst ermittelt werden können.
Vom Master Key zum vollständigen Dateninventar
Mit dem sogenannten Cosmos Master Key konnten Wiz-Forscher laut Bericht außerdem auf einen konfigurationsbasierten Speicher zugreifen. Dieser Config Store enthält Details zu jedem Cosmos-DB-Konto – darunter Kontonamen, Subscription-IDs, Tenant-IDs und weitere Konfigurationsdaten.
Entscheidend ist dabei zweierlei: Erstens ist der Config Store selbst wiederum eine Cosmos-DB-Datenbank. Das bedeutet, dass er mit der vollen Flexibilität des CosmosDB-SQL-Engines abgefragt werden kann. Zweitens konnte der Master Key auch den Primary Key des Config Stores selbst nachladen.
Wiz beschreibt dadurch einen klaren Ablauf: Wer den Master Key besitzt und auf den Config Store zugreifen kann, kann alle Konten auflisten, nach einem bestimmten Tenant filtern und anschließend die Primary Keys konkreter Ziele extrahieren. Ergebnis: vollständiger Lese- und Schreibzugriff auf die Datenbanken der Zielorganisation.
Auch gegen private und isolierte Konten möglich
Ein weiterer Aspekt aus dem Bericht: Die Angriffsführung sei laut Wiz nicht auf öffentlich zugängliche Standardumgebungen beschränkt. Der Angriff könne auch gegen private beziehungsweise netzwerkisolierte Cosmos-DB-Konten sowie sogar gegen Microsoft-eigene Datenbanken gerichtet werden.
Damit verschiebt sich der Schwerpunkt von reiner Perimeter-Absicherung hin zu der Frage, ob ein Angreifer über einen Schwachpunkt innerhalb der Dienstlogik an entscheidende Schlüssel gelangt.
Reaktion von Microsoft: Hotfix und dauerhafte Architekturänderung
Wiz meldete die Schwachstelle Microsoft im November 2025. Laut Bericht reagierte Microsoft innerhalb von zwei Tagen mit einem Hotfix, der den beschriebenen Angriffspfad blockieren sollte.
Darüber hinaus erfolgte im Juli ein Abschluss des Rollouts einer langfristigen architektonischen Lösung in allen Regionen. Das zielt darauf, nicht nur einzelne Symptome zu entfernen, sondern die Ursache über eine nachhaltigere Änderung der Komponentenstruktur zu beheben.
Microsoft erklärte außerdem, es habe umfangreiche Prüfungen der Access Logs durchgeführt. Dabei fand man laut Aussage keine Anzeichen unbefugter Aktivität außerhalb der Testaktivität der Forscher. Zudem seien keine Kundendaten abgerufen worden.
Nach Angaben des Unternehmens sei keine Aktion für Kunden erforderlich, was darauf hindeutet, dass die Korrekturen auf der Seite des Dienstanbieters umgesetzt wurden.
Was man daraus für die Praxis ableiten kann
Auch wenn Microsoft die Schwachstelle inzwischen geschlossen hat, zeigt die CosmosEscape Lücke deutlich, wie eng die Themen Sandbox-Sicherheit, Codeausführung und Schlüsselzugriff miteinander verknüpft sind. Sobald ein Angreifer den Weg aus einer restriktiven Umgebung findet, kann die eigentliche Sicherheitsgrenze sehr schnell „durchbrechen“ – selbst wenn die ursprüngliche Schutzmaßnahme grundsätzlich sinnvolle Grenzen gesetzt hat.
Für Organisationen, die Cosmos DB nutzen, lautet die zentrale Lehre: Sich ausschließlich auf Zugriffsbeschränkungen am Netzwerk- oder API-Perimeter zu verlassen, reicht nicht immer. In kritischen Cloud-Umgebungen sind vor allem robuste Mechanismen zur Schlüsselverwaltung und zur Mandantentrennung entscheidend.
Zusätzlich unterstreicht der Fall, wie wichtig ein schnelles Melde- und Patch-Management ist. Wiz erhielt durch das koordinierte Vorgehen offenbar die Möglichkeit, die Schwachstelle zuerst zu melden, bevor Angriffe hätten breit wirksam werden können.
Fazit
Die von Wiz beschriebene CosmosEscape Lücke hätte Angreifern theoretisch ermöglicht, über die Gremlin API an einen plattformweiten Schlüssel zu gelangen und damit Primary Keys für Cosmos-DB-Konten zu ermitteln. Dadurch wären vollständige Lese- und Schreibzugriffe möglich gewesen und Angriffe hätten nach Subscription- und Tenant-IDs präzise ausgerichtet werden können.
Microsoft reagierte zügig mit einem Hotfix innerhalb weniger Tage und rollte anschließend eine langfristige Architekturänderung aus. Laut dem Anbieter gab es keine Hinweise auf unbefugte Aktivitäten außerhalb der Tests, und Kundendaten wurden nicht erreicht.
Quelle: https://www.securityweek.com/critical-flaw-led-to-azure-cosmos-db-pwnage/
