Microsoft rejette un rapport sur une faille critique d’Azure et ne publie pas de CVE

Un chercheur en sécurité affirme que Microsoft a corrigé discrètement une faille dans Azure Backup for AKS après avoir rejeté son signalement et empêché l’attribution d’un CVE.

Ce signalement décrit un défaut critique d’élévation de privilèges qui donnait un accès administrateur au cluster depuis le rôle à faible privilège de « Contributeur à la sauvegarde ».

Microsoft conteste cette affirmation et explique à BleepingComputer que le comportement était attendu et qu' »aucune modification produit n’a été faite ». Le chercheur documente pourtant de nouveaux contrôles de permissions et des tentatives d’exploitation qui échouent après sa divulgation, ce qui suggère un correctif silencieux.

Le CERT reconnaît un bug, mais Microsoft bloque un CVE

Le chercheur Justin O’Leary a découvert cette faille en mars et l’a signalée à Microsoft le 17 mars.

Le Microsoft Security Response Center a rejeté le rapport le 13 avril. Il a estimé que le problème nécessitait seulement d’obtenir le statut d’administrateur sur un cluster où « l’attaquant disposait déjà d’un accès administrateur ». O’Leary estime que cette description déforme complètement l’attaque.

« C’est factuellement incorrect », déclare le chercheur. « La vulnérabilité permet à un utilisateur sans aucune permission Kubernetes d’obtenir les droits d’administrateur du cluster. L’attaque ne nécessite pas un accès préalable au cluster ; elle le fournit. »

O’Leary ajoute que Microsoft a décrit la soumission au MITRE comme du « contenu généré par IA », ce qui, selon lui, n’a pas abordé le fond technique du rapport.

Après ce rejet, O’Leary a transmis le problème au CERT Coordination Center. Celui-ci a validé indépendamment la vulnérabilité le 16 avril et, selon le chercheur, lui a attribué l’identifiant VU#284781.

Le CERT avait initialement programmé une divulgation publique pour le 1er juin 2026, mais elle n’a jamais eu lieu.

Le 4 mai, des employés de Microsoft ont contacté le MITRE pour recommander de ne pas attribuer de CVE, en répétant que le problème exigeait un accès administratif préexistant.

Le CERT a ensuite clos le dossier en suivant les règles hiérarchiques des CNA, ce qui laisse à Microsoft, qui est un CNA, l’autorité finale sur l’émission de CVE pour ses propres produits.

Le mécanisme de l’attaque

Azure Backup for AKS utilise la fonction Trusted Access pour accorder aux extensions de sauvegarde des privilèges d’administrateur de cluster à l’intérieur des clusters Kubernetes.

Selon O’Leary, la faille permettait à toute personne qui avait seulement le rôle de Contributeur à la sauvegarde sur un coffre de déclencher cette relation de Trusted Access sans avoir déjà des permissions Kubernetes.

Un attaquant pouvait activer la sauvegarde sur un cluster AKS ciblé, ce qui forçait Azure à configurer automatiquement Trusted Access avec les privilèges cluster-admin. À 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é de type Confused Deputy, où les limites de confiance du contrôle d’accès Azure et de Kubernetes interagissaient d’une manière qui contournait les contrôles d’autorisation attendus.

Microsoft affirme n’avoir rien changé, le comportement montre le contraire

BleepingComputer a contacté Microsoft pour savoir si le géant technologique considérait cette découverte comme une vulnérabilité de sécurité valide.

Un porte-parole de Microsoft a déclaré :

« Notre évaluation a conclu qu’il ne s’agit pas d’une vulnérabilité de sécurité, mais d’un comportement attendu qui nécessite des privilèges administratifs préexistants dans l’environnement du client. Par conséquent, aucune modification produit n’a été apportée pour répondre à ce signalement et aucun CVE ou score CVSS n’a été émis. »

Cependant, après la divulgation de son rapport ce mois-ci, O’Leary a observé que le chemin d’attaque initial ne fonctionne plus.

« Le comportement actuel renvoie des erreurs qui n’existaient pas en mars 2026 », écrit-il :

ERREUR : UserErrorTrustedAccessGatewayReturnedForbidden
« La liaison de rôle Trusted Access est manquante ou a été supprimée »

D’après O’Leary, Azure Backup for AKS exige maintenant que Trusted Access soit configuré manuellement avant que la sauvegarde puisse être activée. Cela inverse le comportement précédent où Azure le configurait automatiquement.

Il a aussi observé des contrôles de permissions supplémentaires qui étaient absents lors de ses tests initiaux en mars. L’identité managée du coffre nécessite maintenant des droits Lecteur sur le cluster AKS et sur le groupe de ressources des snapshots, tandis que l’identité managée du cluster AKS nécessite des droits Contributeur sur le groupe de ressources des snapshots.

En d’autres termes, la vulnérabilité semble avoir été corrigée, mais Microsoft n’a publié aucun avis public et n’a pas averti ses clients.

Le problème de visibilité pour les défenseurs

Sans CVE ni avis, les équipes de défense ont peu de visibilité sur la fenêtre d’exposition ou le calendrier de correction.

« Les organisations qui ont accordé le rôle Contributeur à la sauvegarde entre une date de début inconnue et mai 2026 étaient exposées à une élévation de privilèges », écrit le chercheur.

« Sans CVE, les équipes de sécurité ne peuvent pas suivre cette exposition. Les correctifs silencieux protègent les éditeurs, pas les clients. »

Ce cas souligne un problème structurel sans solution facile.

Les désaccords entre chercheurs en sécurité et grands éditeurs sur la gravité, l’exploitabilité et la divulgation sont devenus fréquents ces dernières années, surtout parce que les programmes de divulgation de vulnérabilités reçoivent un volume croissant de rapports.

Certains mainteneurs de logiciels open source se sont aussi plaints publiquement que les rapports assistés par IA submergent les systèmes de primes aux bugs et de triage de la sécurité, ce qui complique l’examen rapide des découvertes légitimes. Les cas où une grande entreprise technologique ignore des correctifs pour des 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, et certainement pas les organisations qui restent exposées dans l’ignorance.