Une faille Cosmos DB critique, identifiée par l’entreprise de cybersécurité Wiz, aurait pu permettre à un attaquant de compromettre l’ensemble des bases de données hébergées sur le service. Baptisée CosmosEscape, la vulnérabilité visait notamment l’accès aux clés nécessaires pour lire et écrire des données à grande échelle.
Selon les informations publiées, l’impact potentiel dépassait un simple compte : l’attaque aurait pu fonctionner au niveau de la plateforme, en s’appuyant sur des composants exposés via des points d’accès accessibles publiquement. Wiz détaille également comment l’exploitation a été possible via l’API Gremlin, puis comment l’exécution de code a pu être détournée.
Qu’est-ce que la faille Cosmos DB « CosmosEscape » ?
Le cœur du problème, d’après Wiz, reposait sur la capacité d’un attaquant à obtenir une clé de plateforme. Avec cette clé, il devenait possible de récupérer la clé primaire de n’importe quel compte Cosmos DB.
En pratique, cela signifiait que l’attaquant pouvait obtenir un accès complet en lecture et en écriture à travers le service. Wiz décrit aussi une étape supplémentaire d’énumération : l’attaquant pouvait lister toutes les bases de données et les filtrer à l’aide d’identifiants d’organisation, comme les subscription IDs et les tenant IDs.
Cette combinaison d’actions — identification puis compromission — pouvait, selon la société, faciliter un ciblage précis à l’échelle de la plateforme.
Pourquoi cette vulnérabilité pouvait toucher des environnements sensibles
Wiz souligne que Microsoft s’appuie sur Azure Cosmos DB pour stocker des données utilisées par plusieurs services. L’entreprise cite notamment Entra ID, Teams et Copilot.
Sur la base de cet écosystème, la faille Cosmos DB aurait potentiellement exposé des bases associées à l’infrastructure de Microsoft à un accès non autorisé.
Autrement dit, même si l’attaque n’avait pas été observée en production, la surface de risque concernait des systèmes largement utilisés.
L’exploitation : Gremlin, sandbox et contournement
L’une des particularités de l’affaire réside dans la manière dont l’exploitation aurait été menée. Wiz indique que la vulnérabilité pouvait être exploitée via l’API Gremlin, une interface orientée graphes.
Gremlin s’appuie sur un moteur personnalisé : il transforme des requêtes en code .NET qui est ensuite exécuté dans un environnement isolé, conçu pour limiter l’accès à ce qui n’est pas autorisé.
Le point d’échec, d’après Wiz, est que les restrictions appliquées au moteur Gremlin ne prenaient pas en compte le mécanisme de reflection en .NET. En contournant cette sandbox, les chercheurs ont pu construire des primitives d’exécution de code.
De l’évasion de sandbox à l’exécution sur le gateway
Une fois la sandbox contournée, Wiz explique avoir obtenu une exécution de code sur le DB Gateway. Ce service, utilisé pour exécuter des requêtes de clients, s’exécute sur des clusters multi-tenant basés sur Service Fabric.
Wiz rapporte ensuite que le gateway s’appuyait sur une clé de signature capable de récupérer les clés primaires des comptes clients. Plus inquiétant encore, cette clé de signature aurait fonctionné au-delà d’un périmètre réduit : elle aurait été valide à travers des tenants, des régions et même différentes APIs.
Le rôle de la « Cosmos Master Key »
Selon les chercheurs, la clé obtenue correspondait à un secret au niveau plateforme, capable de récupérer la clé primaire de n’importe quel compte Cosmos DB sur le service. Wiz l’a surnommée « Cosmos Master Key ».
Avec cette clé, il devenait possible de viser des comptes de manière ciblée depuis des endpoints accessibles publiquement. Autrement dit, l’attaque ne dépendait pas seulement d’un accès direct à une base précise : elle donnait une capacité d’accès transversal.
Wiz précise également que la Cosmos Master Key donnait accès à un configuration store contenant des informations détaillées sur chaque compte Cosmos DB. On y trouvait notamment les noms des comptes, les subscription IDs, les tenant IDs et d’autres données de configuration.
De la configuration store aux bases de données
Le scénario d’attaque décrit par Wiz enchaîne sur un autre point : le Config Store était lui-même une base Cosmos DB. Cela signifiait qu’il pouvait être interrogé avec la pleine flexibilité de l’engine SQL de Cosmos DB.
Wiz indique aussi que le fait que le Config Store soit indexé dans l’écosystème Cosmos DB rendait possible la récupération de sa propre clé primaire. En conséquence, un attaquant disposant de la Cosmos Master Key pouvait :
- lister des comptes au niveau régional ;
- filtrer par identifiant de tenant afin d’identifier des organisations spécifiques ;
- retrouver ensuite la clé primaire d’un compte ciblé.
Une fois la clé du compte obtenue, l’attaquant pouvait obtenir un accès lecture/écriture complet aux bases visées.
Quid des comptes privés et des environnements isolés ?
Wiz mentionne que l’attaque pouvait aussi être mise en œuvre contre des comptes Cosmos DB privés ou réseau isolés. La société indique également que des bases appartenant à Microsoft elles-mêmes auraient pu être ciblées dans le cadre de cette exploitation.
Ce point renforce l’idée que la faille Cosmos DB ne se limitait pas à une configuration publique standard. Le problème aurait plutôt concerné la logique d’accès et le périmètre des clés exploitables.
Réponse de Microsoft et correctifs
Wiz affirme avoir signalé la vulnérabilité à Microsoft en novembre 2025. D’après les informations communiquées, Microsoft a ensuite déployé un hotfix afin de bloquer le vecteur d’attaque dans les deux jours suivant le signalement.
Par ailleurs, Wiz indique qu’en juillet, Microsoft a finalisé le déploiement d’un correctif d’architecture à l’échelle de l’ensemble des régions.
Activité observée : aucune donnée client compromise
Microsoft aurait mené des revues approfondies des journaux d’accès. L’entreprise rapporte qu’il n’y avait aucune preuve d’activité non autorisée en dehors des tests réalisés par les chercheurs.
Enfin, Microsoft précise que aucune donnée client n’a été consultée et qu’il n’y a pas d’action requise pour les clients.
Ce que l’affaire CosmosEscape rappelle aux équipes sécurité
Même si l’impact décrit relève d’un scénario théorique d’exploitation, l’enchaînement mis en avant par Wiz illustre un risque récurrent : les protections qui semblent suffisantes à un niveau (par exemple une sandbox) peuvent être contournées si des mécanismes internes de la plateforme ne sont pas entièrement pris en compte.
Le cas de la faille Cosmos DB montre aussi l’importance de maîtriser la portée des clés et de vérifier si des secrets utilisés pour une fonctionnalité donnée peuvent, en pratique, ouvrir un accès trop large.
Enfin, l’approche de réponse — hotfix rapide puis correction architecturale étendue — illustre la nécessité de traiter non seulement le symptôme, mais aussi la cause de fond.
Conclusion
La faille Cosmos DB « CosmosEscape », telle que décrite par Wiz, aurait pu permettre l’obtention d’une clé au niveau plateforme et la récupération de clés primaires de comptes Cosmos DB, offrant un accès lecture/écriture complet. L’exploitation aurait combiné l’API Gremlin, un contournement de la sandbox .NET et l’exploitation du DB Gateway.
Heureusement, Microsoft a déployé un hotfix rapidement puis un correctif d’architecture à grande échelle, et les vérifications rapportées indiquent qu’il n’y a eu aucune compromission de données client. Cette affaire souligne toutefois l’enjeu stratégique d’une sécurité robuste, de bout en bout, dans les environnements multi-tenant.
Source: https://www.securityweek.com/critical-flaw-led-to-azure-cosmos-db-pwnage/
