CosmosEscape : la faille qui menaçait tout Azure Cosmos DB

Un accès universel à Azure Cosmos DB via une requête Gremlin malformée

Ce 6 août 2026, dans les salles de briefing du Mandalay Bay à Las Vegas, les chercheurs de Wiz Research ont levé le voile sur CosmosEscape lors de leur présentation intitulée « One Key to Rule Them All : Taking Over a Flagship Cloud Service ». La divulgation publique initiale avait eu lieu le 30 juillet 2026, mais c'est à Black Hat USA que la chaîne d'exploitation complète — incluant la requête Gremlin initiale — a été démontrée pour la première fois devant un public de professionnels de la sécurité. La gravité de la faille est sans appel : un attaquant disposant d'une base de données Cosmos DB, même d'un simple compte gratuit, aurait pu accéder en lecture et en écriture à la totalité des bases de données hébergées sur le service d'Azure — y compris celles d'autres entreprises et les bases internes de Microsoft.

La chaîne d'exploitation commence par une requête craftée dirigée contre l'API Gremlin d'une base de données Cosmos DB contrôlée par l'attaquant. L'API Gremlin est l'interface de requête orientée graphe proposée par Cosmos DB pour les modèles de données de type property graph. Les chercheurs de Wiz ont découvert que certaines requêtes Gremlin mal formées déclenchaient une exécution de code côté serveur sur la passerelle multi-tenant qui expose le service à l'ensemble des clients. Ce composant, partagé entre tous les tenants Azure, s'est révélé incapable de confiner correctement l'exécution dans le contexte du tenant demandeur, ouvrant la voie à une escalade vers les ressources de l'infrastructure partagée.

Une fois le code exécuté sur la passerelle partagée, les chercheurs ont pu lire le système de fichiers et les variables d'environnement du processus hôte. C'est là qu'ils ont découvert l'élément central de la vulnérabilité : une clé de signature platform-wide, un secret cryptographique commun à l'ensemble du service, stockée en mémoire sur la passerelle. Avec cette clé en main, ils pouvaient accéder à un répertoire de comptes régionaux listant l'ensemble des instances Cosmos DB déployées, filtrable par identifiant de subscription et de tenant Azure. En combinant la clé de signature et ce répertoire, ils pouvaient récupérer à la demande la clé primaire de n'importe quel compte Cosmos DB, obtenant ainsi des droits complets en lecture et en écriture sur l'intégralité des données du service.

La faille s'appuie sur une faiblesse dans le mécanisme de sandboxing du runtime .NET utilisé par la passerelle. Les restrictions d'isolation prévues ne prenaient pas en compte les possibilités offertes par la réflexion .NET, une fonctionnalité permettant d'inspecter et de manipuler les types et les membres d'un assemblage à l'exécution. En exploitant la réflexion, les chercheurs ont construit des primitives de lecture et d'écriture de fichiers arbitraires, puis ont atteint l'exécution de code avant d'extraire le secret de signature. Le détail technique complet de cette escalade a été présenté lors du briefing Black Hat, avec une démonstration en conditions réelles sur l'infrastructure de test mise à disposition par Wiz.

L'impact potentiel de CosmosEscape était considérable. Azure Cosmos DB est l'un des services de base de données phares de Microsoft Azure, utilisé par des milliers d'entreprises dans le monde pour stocker des données applicatives critiques, des profils utilisateurs, des données transactionnelles et des métadonnées de microservices. La capacité d'un attaquant à lire ou modifier n'importe laquelle de ces bases sans authentification préalable représentait un risque de violation massive affectant potentiellement l'ensemble des clients du service. Les chercheurs de Wiz ont également confirmé que les bases de données internes de Microsoft hébergées sur la même infrastructure auraient été exposées dans les mêmes conditions.

La timeline de résolution illustre une réactivité exemplaire de la part de Microsoft. Wiz a signalé la faille à Microsoft le 20 novembre 2025 via un processus de divulgation responsable coordonné. Microsoft a accusé réception le jour même. Dès le 22 novembre 2025 — moins de 48 heures après la notification — un correctif d'urgence bloquant le vecteur d'entrée Gremlin vulnérable avait été déployé en production sur l'ensemble des régions. Microsoft a ensuite conduit un travail de refonte architecturale plus profonde visant à éliminer la cause racine — le partage de secrets sensibles sur les composants multi-tenant — et ce correctif architectural complet a été déployé sur toutes les régions Azure en juillet 2026, soit huit mois après la découverte initiale.

Une investigation approfondie menée par Microsoft sur les journaux d'accès et les logs système n'a révélé aucune trace d'exploitation malveillante par des acteurs tiers. La clé platform-wide n'a, selon Microsoft, été extraite que par les chercheurs de Wiz dans le cadre de leurs tests contrôlés. Aucun client n'a eu besoin de prendre des mesures de remédiation sur ses propres données, et Microsoft a confirmé que la correction ne requérait aucune action de la part des utilisateurs du service. La divulgation publique a été coordonnée après validation de la correction complète, permettant une communication transparente sans exposer les clients à un risque résiduel.

La présentation à Black Hat a également relancé un débat de fond dans la communauté de la sécurité cloud autour de l'architecture des services mutualisés : la séparation des secrets entre tenants, la surface d'attaque des passerelles partagées et les limites des mécanismes de sandboxing dans les runtimes managés. Plusieurs panélistes et chercheurs présents ont cité CosmosEscape comme illustration emblématique des risques spécifiques au modèle PaaS, où le client délègue entièrement la sécurité de l'infrastructure à son fournisseur cloud sans pouvoir auditer les composants intermédiaires qui traitent ses données.

CosmosEscape révèle les angles morts structurels des architectures cloud multi-tenant

Au-delà de la faille technique elle-même, CosmosEscape met en lumière un problème de fond inhérent à la conception des services cloud mutualisés : la dépendance à des composants partagés — passerelles, proxies, runtimes — qui deviennent des surfaces d'attaque transversales si leur isolation est imparfaite. Ce n'est pas la première fois qu'une vulnérabilité de ce type est découverte dans un service cloud majeur. Wiz avait déjà mis en évidence des risques similaires dans d'autres services Azure par le passé, et des chercheurs d'autres cabinets ont publié des travaux comparables sur des infrastructures AWS et GCP. La récurrence de ces découvertes invite à questionner non pas la qualité des équipes sécurité des hyperscalers, mais la difficulté intrinsèque de garantir l'isolation dans des systèmes de la complexité des clouds publics modernes.

Pour les entreprises qui stockent des données sensibles dans Azure Cosmos DB — ou plus généralement dans tout service PaaS multi-tenant — CosmosEscape rappelle qu'elles ne peuvent pas se reposer uniquement sur le modèle de responsabilité partagée tel qu'il est présenté dans les documents contractuels. Les RSSI doivent intégrer dans leurs analyses de risques la possibilité de vulnérabilités dans les composants gérés par le fournisseur, même si ces composants sont par définition inaccessibles à l'audit direct. Des contrôles compensatoires — chiffrement applicatif des données sensibles avant leur stockage, journalisation des accès anormaux via Azure Monitor et Microsoft Defender for Cloud, principe du moindre privilège sur les accès aux bases — réduisent la surface d'exposition en cas de vulnérabilité similaire découverte à l'avenir.

La réactivité de Microsoft dans cette affaire — correctif d'urgence en 48 heures, correctif architectural en huit mois, communication transparente lors de la divulgation publique — mérite d'être soulignée positivement. Elle contraste avec des situations passées où des failles cloud majeures avaient été minimisées, mal communiquées ou corrigées avec des délais excessifs. La relation entre les cabinets de recherche en sécurité comme Wiz et les grands fournisseurs cloud s'est progressivement normalisée autour de processus de divulgation coordonnée qui bénéficient in fine aux clients. Néanmoins, la durée de huit mois pour un correctif architectural complet soulève des questions légitimes sur la fenêtre de risque résiduel pendant laquelle seule la mitigation d'urgence était en place.

Sur le plan réglementaire, CosmosEscape illustre les tensions entre l'obligation de notification des incidents imposée par NIS2 et DORA aux entités réglementées et la nécessité, pour les fournisseurs cloud, de maintenir une divulgation coordonnée permettant de déployer les correctifs avant publication. Pour les organisations françaises utilisant Azure Cosmos DB pour des données relevant de secteurs critiques au sens de NIS2, cette affaire rappelle l'importance d'inclure dans les contrats cloud des clauses de notification des incidents de sécurité découverts chez le fournisseur, et d'exiger des SLA de correction documentés et auditables.

Ce qu'il faut retenir

• CosmosEscape permettait à tout détenteur d'un compte Azure Cosmos DB de récupérer la clé primaire de n'importe quelle autre base du service, via une requête Gremlin craftée exploitant un défaut de sandboxing .NET.
• Microsoft a réagi en 48 heures avec un correctif d'urgence ; le correctif architectural complet a été déployé en juillet 2026. Aucune exploitation malveillante n'a été détectée.
• Les entreprises utilisant des services PaaS doivent adopter le chiffrement applicatif des données sensibles comme contrôle compensatoire indépendant de la sécurité gérée par le fournisseur.