Azure AKS : Microsoft refuse un CVE, corrige en silence

Un rôle « Backup Contributor » qui ouvre les portes du cluster-admin Kubernetes

En mai 2026, un chercheur en sécurité indépendant a publié un rapport documentant une vulnérabilité critique affectant Azure Backup for AKS, le service de sauvegarde managé de Microsoft pour Azure Kubernetes Service. La faille, qualifiée d'élévation de privilèges non autorisée, permettait à un compte disposant uniquement du rôle « Backup Contributor » — un rôle conçu pour déléguer les opérations de sauvegarde à des tiers ou des comptes de service — d'obtenir les droits cluster-admin sur le cluster Kubernetes cible. En environnement Kubernetes, le rôle cluster-admin confère un accès complet et illimité à l'ensemble des ressources du cluster, fonctionnellement équivalent à un accès root sur un système Linux. BleepingComputer a couvert l'affaire en détail dès le 16 mai 2026.

Le mécanisme d'exploitation tire parti de l'architecture d'Azure Backup for AKS, qui repose sur une fonctionnalité Microsoft appelée Trusted Access. Ce mécanisme permet aux services managés Azure d'interagir directement avec des ressources Kubernetes en contournant le plan de contrôle RBAC standard du cluster. Concrètement, lorsqu'une extension de sauvegarde est déployée sur un cluster AKS via Trusted Access, elle reçoit automatiquement des droits cluster-admin pour exécuter ses opérations. Le chercheur a démontré qu'un titulaire du rôle « Backup Contributor » pouvait manipuler ce mécanisme pour s'approprier ces droits élevés en dehors de tout contexte légitime de sauvegarde, transformant un rôle opérationnel à faibles privilèges en vecteur d'escalade administrative totale.

La gravité de cette faille est particulièrement significative dans les architectures cloud modernes. Les clusters Kubernetes hébergent fréquemment des données applicatives sensibles, des secrets (clés API, certificats TLS, tokens OAuth, identifiants de bases de données), et constituent l'épine dorsale des architectures microservices d'entreprise. Un accès cluster-admin offre à un attaquant la capacité d'exfiltrer l'intégralité des secrets Kubernetes, de déployer des charges malveillantes dans n'importe quel namespace, d'accéder aux volumes persistants et de pivoter vers d'autres ressources Azure via les identités managées attachées aux workloads. Dans les environnements de production multi-tenant, l'impact potentiel s'étend à l'ensemble des applications hébergées sur le cluster.

Après avoir suivi les procédures standard de divulgation responsable, le chercheur a soumis son rapport au Microsoft Security Response Center (MSRC). Microsoft a contesté la qualification de la découverte en tant que vulnérabilité, arguant que l'exploitation nécessitait un « accès administratif préexistant ». Le chercheur a réfuté cet argument en démontrant que le rôle « Backup Contributor » est précisément conçu pour être accordé à des comptes tiers avec des privilèges volontairement limités, et que l'escalade vers cluster-admin constitue un dépassement non documenté et non intentionnel du périmètre de ce rôle — soit par définition une vulnérabilité d'élévation de privilèges.

Le 4 mai 2026, Microsoft a pris la décision de contacter directement MITRE — l'organisme américain qui gère le référentiel CVE — pour recommander explicitement la non-attribution d'un identifiant CVE à cette découverte. CERT/CC, sollicité par le chercheur pour arbitrer le différend, a finalement clos le dossier en invoquant les règles de hiérarchie des CNA. Ces règles confèrent aux Autorités de Numérotation CVE — statut que détient Microsoft pour ses propres produits — une autorité finale sur les désignations CVE les concernant, ce qui a permis à Microsoft de bloquer juridiquement la désignation indépendamment de toute appréciation technique extérieure. Un erratum publié par BleepingComputer le 19 mai 2026 précise que CERT/CC n'a pas validé de manière indépendante que la découverte constituait une vulnérabilité au sens technique du terme.

Parallèlement, le chercheur a documenté des modifications du comportement d'Azure Backup for AKS suggérant qu'une correction avait été silencieusement appliquée par Microsoft dans son infrastructure cloud. Microsoft, interrogé par BleepingComputer, a maintenu sa position : « aucune modification produit n'a été effectuée » et le comportement observé était « attendu ». Cette contradiction entre les observations techniques du chercheur et les déclarations officielles de Microsoft a suscité de vives réactions dans la communauté de la sécurité cloud, résumées sur DEV Community : « un patch silencieux protège le vendor, pas les clients ».

Pour les équipes de sécurité opérant des clusters AKS, l'absence de CVE et d'advisory public crée un angle mort opérationnel significatif. Sans numéro CVE, les plateformes de gestion des vulnérabilités, les outils SIEM et les flux de threat intelligence ne peuvent pas automatiquement associer des indicateurs potentiels d'exploitation à cette faille. Les équipes SOC ne disposent d'aucune fenêtre d'exposition officielle, d'aucun indicateur de compromission spécifique pour une investigation rétrospective, et d'aucune confirmation formelle que leur environnement AKS bénéficie bien de la correction présumée. Cette opacité est d'autant plus préoccupante que le rôle « Backup Contributor » est couramment utilisé dans les pipelines CI/CD et les architectures multi-équipes.

L'affaire intervient dans un contexte déjà tendu autour de la politique de divulgation de Microsoft. En 2023, la CISA avait publiquement critiqué le groupe pour avoir tardé à divulguer la compromission de sa messagerie Exchange Online par Storm-0558. En 2024, Wiz Research avait documenté d'autres cas de vulnérabilités cloud non divulguées. La multiplication de ces incidents interroge la cohérence des engagements de Microsoft dans le cadre de son initiative Secure Future Initiative annoncée en novembre 2023.

La politique du patch silencieux dans le cloud : un angle mort structurel pour la défense

Cette affaire illustre une problématique structurelle dans l'écosystème de la sécurité cloud : la tension fondamentale entre la capacité des hyperscalers à corriger silencieusement leurs infrastructures et les besoins de transparence des équipes de défense. AWS, Azure et Google Cloud disposent d'une capacité unique à déployer des correctifs directement dans leurs couches d'infrastructure sans que les clients aient à agir. Si cette architecture confère des avantages indéniables en termes de rapidité de correction, elle crée un angle mort critique : les clients ne savent pas qu'une faille a existé, ne peuvent pas évaluer s'ils ont été ciblés pendant la fenêtre d'exposition, et ne reçoivent aucun guide de détection ou d'investigation rétrospective.

Le statut de CNA de Microsoft — détenu également par Amazon et Google — lui confère une autorité quasi-exclusive sur les désignations CVE concernant ses propres produits. Ce système, initialement conçu pour rationaliser la gestion des CVE à l'échelle mondiale, crée un conflit d'intérêts structurel : le vendor est à la fois juge et partie dans la qualification de ses propres découvertes. L'incident Azure AKS relance le débat sur la nécessité d'un mécanisme d'appel indépendant, supervisé par un organisme neutre tel que le NIST ou l'ENISA, pour les cas où un chercheur externe conteste une décision de non-désignation par un grand éditeur.

Pour les entreprises utilisant Azure Kubernetes Service — base d'utilisateurs comprenant de nombreuses organisations du CAC 40, des administrations et des PME en transformation cloud — l'incident impose des actions immédiates. Il est recommandé d'auditer sans délai toutes les attributions du rôle « Backup Contributor » dans les abonnements Azure, de vérifier les journaux d'activité Kubernetes (audit logs) pour identifier des opérations cluster-admin inhabituelles émanant de comptes de service de sauvegarde, et d'activer Microsoft Defender for Containers pour une surveillance continue des configurations RBAC et des accès Trusted Access.

La dimension réglementaire de cet incident mérite attention dans le contexte européen. La directive NIS2, applicable depuis octobre 2024 dans les États membres, impose aux fournisseurs de services numériques des obligations de notification des incidents affectant leurs clients. Si une vulnérabilité non divulguée dans un service cloud managé a été exploitée dans des environnements clients — hypothèse qu'aucune autorité ne peut formellement exclure en l'absence d'investigation transparente —, la chaîne de responsabilité de notification reste juridiquement floue et susceptible d'être testée devant les autorités de contrôle nationales à mesure que ce type d'incident se multiplie.

Ce qu'il faut retenir

• Azure Backup for AKS présentait une élévation de privilèges vers cluster-admin depuis le rôle « Backup Contributor » via Trusted Access, corrigée silencieusement sans CVE ni advisory public.
• Microsoft a utilisé son statut de CNA pour bloquer toute désignation CVE officielle, privant les défenseurs de toute visibilité sur la fenêtre d'exposition et les éventuelles compromissions passées.
• Action immédiate : auditer les attributions Trusted Access et RBAC dans vos clusters AKS, analyser les audit logs Kubernetes pour des accès cluster-admin anormaux, activer Defender for Containers.