CosmosEscape : faille critique cross-tenant dans Azure CosmosDB

CosmosEscape : comment Wiz a obtenu les clés de toutes les bases Azure CosmosDB

Le 30 juillet 2026, la firme de sécurité cloud Wiz a rendu publique une vulnérabilité critique qu'elle avait identifiée et signalée à Microsoft dès novembre 2025. Baptisée CosmosEscape, cette faille affectait Azure CosmosDB, la base de données NoSQL distribuée et multi-modèles de Microsoft, pilier de nombreuses applications cloud d'entreprise. L'exploitation de cette vulnérabilité aurait permis à un attaquant de lire et modifier les données de n'importe quel client hébergé sur la plateforme, sans disposer d'aucune authentification sur le tenant ciblé — une violation totale de l'isolation multi-tenant qui constitue la garantie fondamentale de tout service cloud mutualisé.

La vulnérabilité résidait dans le moteur de requête Gremlin, l'interface de traversée de graphes intégrée à CosmosDB et utilisée par de nombreux clients pour gérer des données relationnelles complexes. Les chercheurs de Wiz ont découvert une lacune critique dans le mécanisme de sandboxing de ce moteur : les restrictions d'exécution ne prenaient pas en compte la réflexion .NET, une fonctionnalité native du runtime .NET permettant d'inspecter et d'invoquer dynamiquement des types et des méthodes à l'exécution. Cette omission ouvrait une brèche dans l'isolation du sandbox, permettant aux requêtes Gremlin d'atteindre des ressources système normalement hors de portée.

En exploitant cette lacune, les chercheurs ont construit des primitives de lecture et d'écriture arbitraire de fichiers sur le système hôte, puis ont progressé vers une exécution de code arbitraire complète au sein de l'infrastructure multi-tenant de Microsoft. La chaîne d'exploitation complète se décompose en plusieurs étapes : injection d'une requête Gremlin spécialement forgée dans l'interface CosmosDB, déclenchement de la réflexion .NET pour contourner le sandbox, obtention d'une exécution de code arbitraire sur l'environnement d'exécution, puis extraction d'une clé de portée plateforme — une clé maître partagée entre les tenants.

C'est cette clé maître qui rendait la faille particulièrement dévastatrice. Une fois obtenue, elle offrait un accès en lecture et écriture à l'intégralité des instances CosmosDB hébergées sur la plateforme, indépendamment du tenant propriétaire. Un attaquant n'avait nul besoin de s'authentifier auprès de chaque client individuellement : la clé unique déverrouillait l'ensemble de l'écosystème. Selon Wiz, cette clé était partagée entre les régions Azure, élargissant encore davantage le périmètre d'exposition théorique.

Les conséquences potentielles allaient bien au-delà des clients directs de CosmosDB. D'après les informations publiées par Wiz, Azure CosmosDB constitue une couche de persistance pour plusieurs services Microsoft critiques : Microsoft Entra ID, l'annuaire d'identités cloud de Microsoft utilisé par des millions d'organisations mondiales ; Microsoft Teams, la plateforme de collaboration d'entreprise ; et Microsoft Copilot, l'assistant IA générative de Microsoft intégré à l'ensemble de la suite M365. Une exploitation réussie de CosmosEscape aurait donc pu cibler les données d'identité et de sessions d'authentification, les communications d'entreprise, ainsi que les contextes conversationnels de millions d'utilisateurs de Copilot.

Microsoft a réagi rapidement sur le plan opérationnel d'urgence : dans les 48 heures suivant la notification de novembre 2025, l'équipe de sécurité a bloqué le point d'entrée Gremlin vulnérable, coupant l'accès au vecteur d'exploitation principal. Ce blocage d'urgence limitait l'exposition immédiate mais ne constituait pas un correctif architectural complet. La remédiation structurelle — consistant à éliminer la clé de portée plateforme, à refactoriser le mécanisme de contrôle d'accès de CosmosDB et à garantir l'isolation effective du sandbox Gremlin — a nécessité plusieurs mois de développement et de déploiement progressif à l'échelle mondiale.

Le correctif final a été déployé sur toutes les régions Azure en juillet 2026, soit environ huit mois après le signalement initial. C'est à l'occasion de la finalisation de ce déploiement que Microsoft et Wiz ont coordonné la divulgation publique, conformément aux principes du responsible disclosure. Microsoft a publié une déclaration indiquant que la vulnérabilité avait été entièrement traitée en coopération avec Wiz et qu'aucune preuve d'exploitation malveillante par des acteurs tiers n'avait été identifiée lors des investigations internes.

Cette découverte s'inscrit dans la continuité de travaux antérieurs de Wiz sur la sécurité cloud Microsoft. En 2021, Wiz avait déjà révélé ChaosDB, une faille de nature similaire dans Azure CosmosDB permettant un accès cross-tenant via le service Jupyter Notebook intégré. CosmosEscape démontre que cinq ans après les correctifs de ChaosDB, des vulnérabilités d'isolation critiques continuaient d'exister dans le service, exploitant cette fois un vecteur différent — le moteur Gremlin et la réflexion .NET. La récurrence de ce type de faille dans le même service interroge sur la profondeur des révisions architecturales effectuées à la suite de chaque incident.

Cloud mutualisé : quand une seule clé ouvre toutes les portes

CosmosEscape illustre de façon particulièrement criante l'un des risques les plus sous-estimés de l'adoption du cloud public : la délégation de confiance envers l'hyperscaler. Lorsqu'une faille d'isolation cross-tenant existe chez un fournisseur cloud de la taille de Microsoft, aucun contrôle interne déployé par les clients — gestion des patches, segmentation réseau, politiques IAM, MFA — ne peut en atténuer l'impact. La protection repose entièrement sur la robustesse de l'infrastructure du fournisseur. Cette réalité est souvent euphémisée dans les discours commerciaux autour du shared responsibility model, mais CosmosEscape en rappelle brutalement les limites.

La durée de huit mois entre le signalement et le correctif complet soulève des questions légitimes sur les délais de remédiation acceptables pour des vulnérabilités critiques affectant des services cloud massivement utilisés. Si la réactivité initiale de Microsoft mérite d'être saluée, la fenêtre de vulnérabilité résiduelle entre le blocage du vecteur Gremlin et l'élimination complète de la clé maître reste longue. Cette latence est compréhensible au regard de la complexité d'une refactorisation architecturale multi-régions pour un service core, mais elle illustre les contraintes techniques réelles des hyperscalers lorsqu'ils doivent corriger des failles profondes sans interrompre leurs services.

Du point de vue de la conformité réglementaire, CosmosEscape soulève des questions sérieuses pour les organisations soumises au RGPD, à NIS2, ou à des cadres sectoriels comme DORA dans la finance ou la réglementation HDS dans la santé. Si la faille avait été exploitée discrètement à grande échelle, des milliers d'organisations auraient pu subir une violation de données sans en avoir la moindre visibilité, rendant impossible l'honoration de leur obligation de notification dans les 72 heures prévues par le RGPD. Le fait que Microsoft affirme n'avoir détecté aucune exploitation ne garantit pas l'absence d'incidents non détectés : une exploitation discrète d'une vulnérabilité cross-tenant laisserait peu de traces dans les journaux applicatifs standards des clients.

Enfin, la dimension systémique de la faille — qui s'étendait aux services d'identité (Entra ID), de collaboration (Teams) et d'IA générative (Copilot) — rappelle que les grandes plateformes cloud constituent désormais des infrastructures critiques de fait, dont la compromission peut avoir des effets en cascade bien au-delà du service directement affecté. Pour les RSSI, cela renforce l'impératif de cartographier précisément les dépendances de leurs environnements Azure et de surveiller activement les bulletins de sécurité Microsoft, même pour les services gérés réputés transparents pour le client.

Ce qu'il faut retenir

• CosmosEscape permettait une évasion du sandbox Gremlin d'Azure CosmosDB via la réflexion .NET, conduisant à une exécution de code arbitraire et à la récupération d'une clé maître cross-tenant.
• Microsoft a déployé un blocage d'urgence en 48 heures (novembre 2025) et finalisé le correctif complet en juillet 2026 — sans preuve d'exploitation malveillante identifiée.
• Les organisations utilisant Azure CosmosDB, Entra ID, Teams ou Copilot doivent activer Microsoft Defender for Cloud et Azure Monitor pour analyser rétrospectivement les accès inhabituels sur la période novembre 2025 – juillet 2026.