Un chercheur en sécurité affirme que **Microsoft** a discrètement corrigé une vulnérabilité dans **Azure Backup** pour AKS après avoir rejeté son rapport et empêché l'émission d'un CVE. Le rapport du chercheur décrit une faille critique d'escalade de privilèges qui permettait d'obtenir un accès administrateur au cluster à partir du rôle à faibles privilèges "Backup Contributor". Microsoft conteste cette affirmation, déclarant à BleepingComputer que le comportement était attendu et qu'"aucun changement de produit n'a été apporté", malgré le fait que le chercheur ait documenté de nouvelles vérifications de permissions et des tentatives d'exploitation échouées après la divulgation, suggérant un correctif silencieux. ## CERT convient qu'il s'agit d'un bug, mais Microsoft bloque le CVE Le chercheur en sécurité **Justin O'Leary** a découvert la faille de sécurité en mars dernier et l'a signalée à **Microsoft** le 17 mars. Le Microsoft Security Response Center (MSRC) a rejeté le rapport le 13 avril, affirmant que le problème impliquait uniquement l'obtention d'un accès administrateur au cluster "où l'attaquant détenait déjà un accès administrateur", une caractérisation qu'O'Leary juge erronée. "C'est factuellement incorrect", déclare le chercheur. "La vulnérabilité permet à un utilisateur sans aucune permission Kubernetes d'obtenir un accès administrateur au cluster. L'attaque ne nécessite pas d'accès existant au cluster – elle le confère." O'Leary ajoute que Microsoft a décrit la soumission à **MITRE** comme du "contenu généré par IA", ce qu'il affirme ne pas avoir abordé les mérites techniques du rapport. Après le rejet, O'Leary a escaladé le problème au **CERT Coordination Center**, qui a validé indépendamment la vulnérabilité le 16 avril et, selon le chercheur, lui a attribué un identifiant, VU#284781 :  Le **CERT/CC** avait initialement prévu une divulgation publique pour le 1er juin 2026, mais cette divulgation n'a jamais eu lieu. Le 4 mai, des employés de Microsoft auraient contacté **MITRE** pour déconseiller l'attribution d'un CVE, arguant à nouveau que le problème nécessitait un accès administratif préexistant :  Le **CERT/CC** a ensuite clos le dossier selon les règles de la hiérarchie CNA, laissant effectivement à **Microsoft** (qui est un CNA) l'autorité finale sur l'émission de CVE pour ses propres produits. ## Comment fonctionnait l'attaque **Azure Backup** pour AKS utilise l'accès de confiance (Trusted Access) pour accorder aux extensions de sauvegarde des privilèges d'administrateur de cluster (cluster-admin) au sein des clusters Kubernetes. Selon O'Leary, la faille permettait à toute personne détenant uniquement le rôle Backup Contributor sur un coffre-fort de sauvegarde de déclencher cette relation d'accès de confiance sans avoir déjà les permissions Kubernetes. Un attaquant pouvait activer la sauvegarde sur un cluster AKS cible, amenant Azure à configurer automatiquement l'accès de confiance avec des privilèges d'administrateur de cluster. À partir de là, un attaquant pouvait extraire des secrets via des opérations de sauvegarde ou restaurer des charges de travail malveillantes dans le cluster. O'Leary a classé le problème comme une vulnérabilité **Confused Deputy** (CWE-441), où les limites de confiance d'Azure RBAC et de Kubernetes RBAC interagissaient d'une manière qui contournait les contrôles d'autorisation attendus. ## Microsoft affirme qu'aucun changement n'a été apporté, mais le comportement dit le contraire BleepingComputer a contacté Microsoft pour comprendre si le géant de la technologie considérait cette découverte comme une vulnérabilité de sécurité valide. Un porte-parole de Microsoft a déclaré à BleepingComputer : "Notre évaluation a conclu qu'il ne s'agit pas d'une vulnérabilité de sécurité, mais plutôt d'un comportement attendu qui nécessite des privilèges administratifs préexistants au sein de l'environnement du client. Par conséquent, aucun changement de produit n'a été apporté pour traiter ce rapport et aucun CVE ni score CVSS n'ont été émis." Cependant, suite à la divulgation de son rapport ce mois-ci, O'Leary a observé que le chemin d'attaque d'origine ne fonctionnait plus. "Le comportement actuel renvoie des erreurs qui n'existaient pas en mars 2026", déclare-t-il : ERREUR : UserErrorTrustedAccessGatewayReturnedForbidden "La liaison de rôle Trusted Access est manquante/a été supprimée" Selon O'Leary, **Azure Backup** pour AKS exige désormais que l'accès de confiance soit configuré manuellement avant que la sauvegarde puisse être activée, inversant le comportement antérieur où Azure le configurait automatiquement. Il a également observé des vérifications de permissions supplémentaires qui étaient absentes lors de ses tests initiaux en mars. Le MSI du coffre-fort nécessite désormais des permissions de Lecteur sur le cluster AKS et le groupe de ressources de snapshot, tandis que le MSI du cluster AKS nécessite des permissions de Contributeur sur le groupe de ressources de snapshot. En d'autres termes, la vulnérabilité semble avoir été corrigée, mais **Microsoft** n'a ni publié d'avis public ni informé ses clients. ## Le problème de visibilité pour les défenseurs Sans CVE ni avis, les défenseurs ont peu de visibilité sur la fenêtre d'exposition ou le calendrier de remédiation. "Les organisations qui ont accordé le rôle Backup Contributor entre une date de début inconnue et mai 2026 étaient exposées à une escalade de privilèges", écrit le chercheur. "Sans CVE, les équipes de sécurité ne peuvent pas suivre cette exposition. Le correctif silencieux protège les fournisseurs, pas les clients." Ce cas met en évidence un problème structurel sans solution facile. Les différends entre les chercheurs en sécurité et les grands fournisseurs concernant la gravité, l'exploitabilité et la divulgation sont devenus courants ces dernières années, d'autant plus que les programmes de divulgation de vulnérabilités font face à un volume croissant de rapports. Certains mainteneurs de projets open-source se sont également plaints publiquement que les rapports assistés par IA submergent les systèmes de bug bounty et de triage de sécurité, rendant plus difficile pour les découvertes légitimes de recevoir une attention rapide. Les cas où les grandes entreprises ont ignoré la correction de failles valides malgré des contacts répétés par différents chercheurs ne sont pas rares non plus. Sans un cadre qui réaligne les incitations pour toutes les parties, la divulgation responsable risque de devenir un exercice bureaucratique qui ne sert personne, encore moins les organisations laissées dans l'obscurité.  ## Le fossé de validation : les tests d'intrusion automatisés répondent à une seule question. Vous en avez besoin de six. Les outils de tests d'intrusion automatisés apportent une réelle valeur, mais ils ont été conçus pour répondre à une seule question : un attaquant peut-il se déplacer sur le réseau ? Ils n'ont pas été conçus pour tester si vos contrôles bloquent les menaces, si vos règles de détection se déclenchent, ou si vos configurations cloud tiennent bon. Ce guide couvre les 6 surfaces que vous devez réellement valider. [Télécharger maintenant](https://hubs.li/Q048zztN0)