Microsoft corrige une faille CVSS 10.0 sans authentification dans Azure AI Foundry

Le 17 septembre 2026, Microsoft a publié CVE-2026-85889, « Azure AI Foundry Elevation of Privilege Vulnerability », avec un score de base CVSS v3.1 de 10.0. L’avis la classe CWE-306, absence d’authentification pour une fonction critique : une fonction critique d’Azure AI Foundry a été livrée sans contrôle d’authentification, et un attaquant sur le réseau pouvait s’en servir pour élever ses privilèges sans la moindre accréditation.

À lire aussi: Microsoft prévoit de tripler ses centres de données pour atteindre 38 gigawatts d'ici 2032 · SK Hyper chiffre à 350 milliards de dollars les 5 premiers gigawatts de son programme d'IA.

Le vecteur, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, atteint la pire valeur sur chaque métrique qui compte. L’attaque est joignable par le réseau et de faible complexité, ne demande ni privilège ni interaction utilisateur, et entraîne un impact élevé sur la confidentialité, l’intégrité et la disponibilité. La composante de portée est la plus importante pour évaluer le rayon de dégâts. Une portée modifiée signifie que l’impact franchit une frontière de sécurité au lieu de rester dans le compte de l’attaquant, ce qui, dans un cloud multilocataire, désigne la frontière entre les locataires et la plateforme elle-même.

Selon Microsoft, la faille est déjà corrigée. L’avis indique qu’elle a été « entièrement mitigée » côté serveur, qu’aucune action n’est requise des utilisateurs du service et que la CVE a été publiée par transparence. Il n’y a aucun correctif à télécharger. Microsoft a crédité le chercheur en sécurité Rémy Marot (@R_Marot) pour le signalement, et la couverture de The Hacker News note que rien n’indique une exploitation dans la nature. Comme Azure AI Foundry est un service exclusivement hébergé, la correction a vécu et est morte à l’intérieur de l’infrastructure de Microsoft, invisible pour les clients.

La vulnérabilité en termes simples

CWE-306 décrit une erreur précise et sans éclat : une fonction qui devrait exiger un appelant authentifié en accepte un non authentifié. Le bug n’est pas un tour de corruption mémoire ni une chaîne de configurations erronées. C’est l’absence d’une connexion là où une connexion était attendue.

La conséquence découle directement de ce que la fonction non protégée pouvait faire. Dans une faille d’élévation de privilèges, le contrôle manquant permet à un appelant d’agir comme s’il détenait des permissions jamais accordées. Combiné à un vecteur d’attaque réseau et à l’absence de privilèges requis, cela revient pratiquement à dire que quiconque pouvait acheminer une requête vers le point de terminaison concerné accédait à des opérations privilégiées dans la plateforme. La portée modifiée de la CVSS signale que ces opérations ne se limitaient pas à la frontière d’autorisation de l’attaquant.

C’est pourquoi un 10.0 n’est pas exagéré ici. Un score de 10.0 est réservé aux failles joignables à distance, trivialement exploitables et entièrement destructrices pour la confidentialité, l’intégrité et la disponibilité de la cible. L’absence d’authentification dans une fonction de contrôle accessible par le réseau remplit tout cela d’un coup.

Pourquoi un plan de contrôle d’IA est une surface d’identité de premier ordre

Azure AI Foundry est la plateforme d’entreprise de Microsoft pour créer, déployer et gouverner des agents et des modèles d’IA. Cette description sous-estime ce qu’elle est en matière de sécurité. Foundry est un plan de contrôle. Elle orchestre d’autres codes, héberge des déploiements de modèles et des données d’entraînement, et se connecte à des sources de données d’entreprise et à des systèmes en aval par des accréditations que les clients configurent. Qui peut agir à l’intérieur peut agir sur beaucoup de choses auxquelles l’entreprise tient.

Une faille qui accorde un accès non authentifié à une fonction privilégiée de Foundry équivaut donc à remettre à un attaquant les clés d’un utilisateur privilégié de la plateforme. L’analyse de Mallory décrit sans détour la portée possible : un attaquant pourrait obtenir des capacités comparables à celles d’un utilisateur privilégié de Foundry, exposant ou modifiant potentiellement des modèles d’IA, des données d’entraînement, des ressources d’entreprise connectées et des systèmes en aval intégrés aux applications Foundry.

C’est le cœur de l’argument pour traiter les API de gestion de l’IA comme une surface d’identité de premier ordre. Les équipes identité durcissent depuis des années les connexions humaines puis, plus récemment, les comptes de service et les identités de charge de travail. Les plans de gestion plus récents pour l’IA sont plus jeunes, portent souvent des permissions permanentes étendues sur les données et le calcul, et sont fréquemment reliés à des automatisations que peu de gens auditent à la main. Quand une plateforme peut appeler d’autres systèmes en votre nom, sa propre authentification est aussi sensible que les accréditations qu’elle détient.

La surface d’attaque diffère aussi d’une application classique. Il n’y a pas de périmètre à défendre, ni de règle de pare-feu côté client qui aurait arrêté une requête atteignant un point de terminaison hébergé par Microsoft. La fonction vulnérable était joignable par le réseau par conception, ce qui est normal pour une API cloud, et le contrôle manquant était la seule chose entre un appelant et des opérations privilégiées.

Ce que « entièrement mitigée, aucune action client » règle

La formule est honnête et doit être lue pour ce qu’elle est. Microsoft a trouvé le problème, l’a corrigé sur ses serveurs et a publié la CVE pour que le registre ne reste pas muet sur une faille de sévérité maximale. C’est la transparence que le programme CVE est censé produire, et c’est mieux que l’alternative consistant à corriger en silence sans rien dire.

Pour le client moyen, la conséquence opérationnelle est réellement légère. Il n’y a rien à déployer, aucune version à comparer à un inventaire, aucune fenêtre de maintenance. Un locataire qui ne fait rien s’exécute déjà contre le backend corrigé.

Ce que la formule ne règle pas, c’est la vérification. Quand un éditeur corrige un logiciel, un client peut confirmer la version, lancer un scanner ou vérifier un hash de build. Quand un service hébergé est corrigé côté serveur, rien de tout cela n’est disponible. La seule preuve du client est la parole de l’éditeur et, s’il dispose de la télémétrie, un examen de ce qui s’est passé sur son compte avant et pendant la fenêtre de remédiation. Cet écart n’est pas une critique de la réponse de Microsoft. C’est une propriété structurelle de la consommation de garanties de sécurité auprès d’un service que l’on ne contrôle pas.

Il existe une seconde limite. Microsoft a divulgué peu de détails techniques sur la fonction touchée ou sur la façon dont le contrôle manquant était joignable. L’avis nomme la classe de faiblesse et le score, mais pas le point de terminaison. Un rapport de renseignement sur les menaces chez threat.wiki et des traqueurs indépendants complètent le vecteur et la lecture multilocataire, mais le registre public ne permet toujours pas à une équipe externe de reconstituer la faille. Sans ce détail, le vrai rayon de dégâts n’est pas entièrement connaissable à partir du registre public, et personne ne peut dire avec précision ce qu’un attaquant ayant utilisé la faille avant la correction aurait pu atteindre.

La correction appartient à Microsoft. La preuve que rien ne s’est produit sur votre compte vous appartient.

Le schéma plus large à travers les plateformes d’IA

CVE-2026-85889 n’est pas arrivée seule. Elle s’inscrit dans une série de correctifs Microsoft de haute sévérité autour des 16 et 17 septembre 2026, qui comprenait aussi une faille d’injection de commandes dans M365 Copilot, CVE-2026-85885, notée 9.9 ; une faille d’autorisation dans Azure Database for PostgreSQL, CVE-2026-85878, notée 9.9 ; et une faille dans Azure Cosmos DB, CVE-2026-87701, notée 9.6. Les avis de Microsoft pour chacune indiquent qu’elles ont été mitigées côté serveur sans action client, et les entrées Copilot et Cosmos DB reprennent la formulation de transparence employée pour la faille de Foundry. Une entrée Microsoft distincte dans la même fenêtre, la mise à jour Windows 26H1 KB5129194, traitait un double libéré du Secure Kernel Mode, suivi sous CVE-2026-85921. Ce dernier point est une mise à jour classique et non une correction cloud cachée, et les lecteurs devraient considérer le regroupement de toute la liste comme un cadrage, non comme une déclaration unique de Microsoft.

Le rapport de renseignement sur les menaces situe CVE-2026-85889 dans un schéma plus étroit : c’est la troisième faille de sévérité quasi maximale ou maximale ce mois-ci dans une plateforme dont le rôle est d’orchestrer d’autres logiciels, après un 9.8 chez Bifrost et un 9.8 chez Orkes. Ce regroupement relève du cadrage du rapport, pas d’une affirmation de Microsoft, mais il pointe vers quelque chose de réel. Les outils qui se trouvent au milieu d’une pile logicielle, orchestrant modèles, agents, flux de travail et systèmes connectés, sont exactement là où une seule erreur d’authentification produit un rayon de dégâts disproportionné. Quand l’orchestrateur est compromis, tout ce qui se trouve en aval hérite du problème.

C’est une classe de logiciels jeune. Les frameworks d’agents, les passerelles de modèles et les couches d’orchestration ont grandi vite, et beaucoup ont été construits par des équipes dont la priorité était la capacité et la vitesse, non le durcissement que les plateformes plus anciennes ont accumulé après une décennie d’examen. La leçon de l’infrastructure classique, selon laquelle les plans de contrôle méritent les garanties d’identité les plus fortes parce qu’ils détiennent les clés de tout le reste, n’a pas encore été pleinement intégrée par la vague des outils d’IA. La série de Microsoft rappelle que les mêmes modes de défaillance migrent : autorisation manquante, injection de commandes, contrôle d’accès inapproprié, tous réapparaissent dans de nouveaux systèmes.

Ce qu’il faut surveiller

Trois choses détermineront la mémoire de cet incident.

La première est de savoir si Microsoft publie davantage de détails techniques. Une classe de faiblesse et un score suffisent pour une entrée CVSS, mais pas pour que les défenseurs modélisent leur exposition. Si la fonction concernée est décrite plus tard, les équipes pourront déterminer si leur automatisation l’a touchée pendant la fenêtre précédant la correction. D’ici là, la position honnête est que le registre public est incomplet.

La deuxième est de savoir si la télémétrie postérieure à la correction révèle une activité inhabituelle. Microsoft dit qu’il n’y a aucune preuve d’exploitation, et cette déclaration doit être prise au pied de la lettre. Une faille réseau non authentifiée ayant existé pendant une période inconnue avant la divulgation reste pourtant exactement le cas pour lequel un examen rétrospectif des journaux est conçu. Les organisations qui exploitent Foundry en production devraient rechercher des appels API privilégiés anormaux, des attributions de rôles inattendues et de nouvelles connexions vers des magasins de données ou des ressources externes.

La troisième est l’orientation de la plateforme elle-même. À mesure que davantage d’entreprises confient à des agents du travail réel, la posture d’identité et d’autorisation des plans de contrôle qui les exécutent devient une question de gouvernance autant que de sécurité. Les régulateurs et les auditeurs commencent à demander qui a approuvé ce à quoi un système d’IA peut accéder. Une faille d’authentification de sévérité maximale dans une plateforme qui orchestre cet accès est le genre de constat qui accélère ces conversations.

Pour les lecteurs qui suivent la sécurité cloud, la consigne pratique est modeste et durable. Traitez le plan de gestion de l’IA comme un niveau d’identité. Cela signifie des attributions de rôles au moindre privilège, l’examen des permissions permanentes, la journalisation des opérations privilégiées et l’habitude de consulter ces journaux chaque fois qu’un éditeur annonce une correction côté serveur que vous ne pouvez pas inspecter. La correction appartient à Microsoft. La certitude que rien ne s’est produit sur votre compte est à vous de construire, et elle dépend de journaux que vous conservez avant que la divulgation n’arrive.

Couverture : « Microsoft Redmond Campus redevelopment aerial view, Sept. 2021 » par Atomic Taco, via Wikimedia Commons, sous licence CC BY-SA 2.0 (recadrée en 16:9).