La SSRF d’Azure MCP Server pourrait divulguer son jeton Managed Identity vers une URL

Microsoft a publié la CVE-2026-26118 le 10 mars 2026 : une faille de falsification de requête côté serveur (SSRF) dans Azure MCP Server Tools, le package qui permet aux agents IA et aux clients MCP d’agir sur des ressources Azure en langage naturel. Un attaquant capable d’interagir avec un agent adossé à MCP pourrait soumettre une URL malveillante à la place d’un identifiant de ressource Azure normal ; le serveur enverrait alors une requête sortante vers cette adresse et, selon les termes de Microsoft, « pourrait inclure son jeton d’identité managée » — remettant ainsi à l’appelant un identifiant qu’il n’était pas censé voir. Microsoft a attribué à la faille un score CVSS 8.8 et l’a classée « Important » ; les packages qui contiennent le correctif sont les versions 1.0.2 et 2.0.0-beta.17. L’avis ne fait état d’aucune exploitation ni d’aucune divulgation publique avant le correctif, et aucun préjudice réel n’y est consigné. Cet incident est une entrée de l’Orca AI Incident Archive, qui contient le dossier complet avec ses sources citées, son niveau de gravité et son évaluation de confiance.

Ce que dit réellement l’avis

Le compte rendu du Microsoft Security Response Center est laconique, et presque tous les détails publiés sur cette faille en découlent ou proviennent des réponses de Microsoft à une poignée de questions de suivi. La description intégrale : « Une falsification de requête côté serveur (SSRF) dans Azure MCP Server permet à un attaquant autorisé d’élever ses privilèges sur un réseau. » La fiche CVE a réservé l’identifiant le 11 février 2026 et l’a rendu public le 10 mars à 14 h 00 UTC ; la note de version de Microsoft et l’entrée du NVD portent toutes deux cette date. Le NVD a analysé la fiche et l’a publiée à 18 h 18 UTC l’après-midi même. Le seul avis de régulateur trouvé pour cet article provient du Maroc : l’unité maCERT de la DGSSI a repris CVE-2026-26118 dans un bulletin daté du 11 mars 2026, inscrivant Azure MCP Server Tools parmi les produits concernés à son propre niveau de risque « Important », sans score distinct et avec un renvoi vers la publication de Microsoft.

La faiblesse est associée à CWE-918, une falsification de requête côté serveur, et la classification de l'impact est une élévation de privilèges. Le score de base de Microsoft est de 8,8 sur le vecteur CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, avec un score temporel de 7,7 sur E:U/RL:O/RC:C — la composante E:U signifiant qu'aucun code d'exploitation n'était connu de Microsoft au moment où le score a été établi, et RL:O signifiant qu'un correctif officiel était disponible. NVD porte le même score de base et le classe dans la catégorie High ; l'échelle à trois niveaux de Microsoft le qualifie d'Important.

Deux champs comptent autant que le score. Le dossier de Microsoft indique Exploitée : Non et Divulguée publiquement : Non. Le dossier de décision SSVC de la CISA relatif à l’entrée NVD, horodaté du 5 mars 2026, aboutit à la même conclusion sur l’exploitation — aucune — tout en jugeant l’impact technique total et le caractère automatisable non. Le modèle FIRST EPSS estimait la probabilité d’exploitation dans les 30 prochains jours à environ 1,0 %, au 62,8e centile, dans une extraction datée du 3 novembre 2026. Il s’agit d’une faille qui a été trouvée et corrigée, et non d’une faille dont l’exploitation est connue.

Comment un identifiant de ressource devient une requête sortante

Azure MCP Server est l’implémentation par Microsoft du Model Context Protocol, l’interface que les agents d’IA utilisent pour appeler des outils. Ses outils prennent les paramètres fournis par un agent — un nom de compte de stockage, un identifiant d’abonnement, un nom de base de données — et les transforment en appels vers les plans de gestion et de données d’Azure. La documentation de Microsoft décrit le serveur comme s’authentifiant via Entra ID à l’aide de « vos informations d’identification utilisateur Azure ou d’une identité managée », l’accès étant limité par le contrôle d’accès basé sur les rôles Azure.

La faille se situe là où un paramètre censé désigner une ressource Azure est plutôt accepté sous forme d’URL. L’explication de Microsoft elle-même : un attaquant « pourrait exploiter ce problème en envoyant une entrée spécialement conçue à un outil Azure Model Context Protocol (MCP) Server qui accepte des paramètres fournis par l’utilisateur. Si l’attaquant peut interagir avec l’agent adossé à MCP, il peut soumettre une URL malveillante à la place d’un identifiant de ressource Azure normal. » Le serveur envoie alors la requête là où on lui a indiqué de l’envoyer, plutôt que là où l’outil le prévoyait.

Ce qui transforme un simple désagrément en élévation de privilèges, c’est ce qui accompagne la requête. Microsoft indique que la requête sortante « peut inclure son jeton d’identité managée », ce qui permet à l’attaquant de récupérer ce jeton « sans nécessiter d’accès administratif ». Un jeton d’identité managée est un identifiant de type bearer : quiconque le détient peut le présenter aux services Azure pour lesquels cette identité est autorisée, jusqu’à son expiration. La partie atténuante du même paragraphe est tout aussi importante — l’attaquant obtient « les autorisations associées à l’identité managée du serveur MCP » et, selon Microsoft, « n’obtient pas d’autorisations plus larges au niveau du locataire ou d’administrateur ; uniquement celles liées à l’identité managée compromise ». Le rayon d’impact correspond à tout ce que quelqu’un a accordé à cette identité, ce qui, en pratique, dépasse souvent ce dont un seul outil avait besoin.

Microsoft ne nomme ni l'outil ni le paramètre concernés, et aucune source consultée pour cet article ne le fait. Cette omission est en soi un détail : l'avis décrit une catégorie d'outils — un outil qui accepte des paramètres fournis par l'utilisateur et peut être amené à récupérer une URL — plutôt qu'un point de terminaison unique.

Le correctif, et les paquets qui le contenaient

Il ne s'agissait pas d'une mise à jour Windows. Les outils Azure MCP Server sont distribués sous forme de package NuGet pour .NET, de package npm et de package Python sur PyPI, et le correctif consiste à mettre à jour la version de celui qu'utilise chaque déploiement. L'avis de Microsoft indique que les plages affectées vont de 1.0.0 jusqu'à 1.0.2 exclu, et de 2.0.0-beta.1 jusqu'à 2.0.0-beta.17 exclu, pour les distributions NuGet, npm et PyPI.

Les dates du registre npm montrent que les versions corrigées étaient présentes dans le registre avant l'avis. La version 1.0.2 de @azure/mcp a été publiée le 6 mars 2026, quatre jours avant que la CVE ne soit rendue publique ; la 2.0.0-beta.17 a été publiée le 6 février 2026, cinq jours avant que Microsoft ne réserve l'identifiant CVE et un mois avant l'apparition de l'avis. Quelle que soit la séquence en interne chez Microsoft, le code corrigé n'a pas été écrit en réaction à la date de publication. NVD et la base de données d'avis de GitHub s'accordent sur ces bornes supérieures. Ils diffèrent légèrement à la limite inférieure de la plage PyPI — NVD indique 2.0.0-beta.1, l'avis GitHub indique 2.0.0b14 — une divergence que les deux enregistrements portent depuis la publication et qui n'affecte que la profondeur à laquelle un déploiement Python doit remonter.

L’avis lui-même a été révisé le 20 mars 2026, dix jours après sa publication, avec une note indiquant que Microsoft avait « ajouté des produits au tableau des mises à jour de sécurité qui documentent les différentes méthodes d’empaquetage utilisées pour distribuer Azure MCP Server Tools ». En d’autres termes, la première version de l’avis nommait le produit mais pas tous les canaux par lesquels il était distribué, ce qui compte lorsque la remédiation consiste à « mettre à niveau le paquet » plutôt qu’à « installer ce correctif KB ».

Qu'est-ce qui n'est pas établi ?

Qui l'a trouvé.Ni l'avis de Microsoft ni la fiche CVE.org ne nomment de rapporteur ; le champ des crédits de la CVE est vide. Cela ne prouve pas que personne n'ait été crédité en privé, seulement qu'aucun crédit public n'existe.

Une exploitation quelconque.Microsoft n'en recense aucune, l'évaluation SSVC de la CISA abonde dans ce sens, et aucune source examinée pour cet article ne décrit une identité compromise en conditions réelles. Le champ real-harm de la fiche est à false, ce qui est cohérent avec cela. Un EPSS faible est une prévision, pas un constat, et l'absence d'incident signalé ne prouve pas qu'aucun ne s'est produit.

L’existence ou non d’un exploit public. C’est ici que les sources secondaires divergent. Un billet de mars 2026 sur le blog de Blueinfy affirme qu’il existe « des exploits de preuve de concept publics, tels que ceux sur GitHub » et met en garde contre une « militarisation rapide », mais ne fournit ni lien, ni charge utile, ni tutoriel détaillé, et ne démontre pas la faille. Les éléments de Microsoft indiquent que la vulnérabilité n’a pas été divulguée publiquement avant le correctif. Une recherche de l’identifiant CVE dans les dépôts GitHub le 4 novembre 2026 a renvoyé un seul dépôt — un laboratoire de détection Microsoft Sentinel publié le 17 mars 2026, et non un exploit — et la page de vulnérabilité de Mallory indique que deux exploits candidats ont été examinés puis rejetés. L’affirmation selon laquelle il existerait du code d’exploit public fonctionnel n’est, au vu des éléments disponibles, pas étayée ; celle selon laquelle personne n’a essayé n’est pas davantage prouvée.

La présentation du problème. Une page de PolicyLayer, un site fournisseur de résumés d'incidents, reformule CVE-2026-26118 comme une chaîne d'exécution de code à distance non authentifiée aboutissant à une prise de contrôle complète du locataire, en attribuant cette analyse à un chercheur nommé et à une démonstration lors de la RSAC 2026. Or, les sources citées sur cette page portent elles-mêmes des titres évoquant une SSRF, ses dates ne concordent pas avec la chronologie de la CVE, et ni l'avis de Microsoft ni l'article de SecurityWeek du 10 mars ne décrivent d'exécution de code. Le présent article considère comme établi le récit fondé sur la SSRF et le jeton, et ne reprend pas la thèse de l'exécution de code à distance.

Pourquoi le token, et non la requête, est le constat

La falsification de requête côté serveur est l’une des plus anciennes catégories de vulnérabilités des logiciels web et, à elle seule, elle constitue généralement un moyen d’atteindre des systèmes que l’attaquant ne peut pas joindre directement. Ce qui rend cet enregistrement digne d’être conservé, c’est le justificatif d’authentification attaché à la requête. Le serveur MCP est un délégué confus par conception : il détient une identité afin qu’un agent puisse agir au nom d’un utilisateur, et chaque paramètre transmis par un agent est, du point de vue du serveur, un texte influencé par l’attaquant. Lorsque l’un de ces paramètres devient une destination plutôt qu’un nom, le délégué transporte sa propre autorisation vers la destination.

La documentation de Microsoft précise où ce risque se concentre. Elle décrit le serveur local comme « destiné strictement à un usage par les développeurs au sein de votre organisation », tout en publiant séparément des guides de déploiement pour des serveurs distants auto-hébergés dans Microsoft Foundry et Copilot Studio — les configurations où une identité managée, plutôt que l’authentification propre à un développeur, est généralement l’identifiant en jeu. Le chemin de vol de jeton décrit dans l’avis concerne spécifiquement l’identité managée. Il ne dit pas que chaque installation a été exposée, et il ne dit pas combien l’ont été.

La leçon générale est celle que la norme AI Security Verification Standard de l’OWASP utilise désormais comme cas d’école. Le chapitre sur l’orchestration de l’AISVS cite CVE-2026-26118 parmi ses exemples détaillés et en tire la conclusion que « les paramètres des outils MCP doivent être considérés comme contrôlés par l’attaquant, et les requêtes sortantes des serveurs MCP doivent passer par les mêmes politiques de sortie et d’origine que celles attendues de toute autre E/S pilotée par un agent ». Il s’agit d’une recommandation de contrôle, et non d’un constat sur cet incident, mais c’est la réponse la plus concrète que quiconque ait publiée à la question de ce qui devrait changer.

Qu’est-ce qui a changé après

Trois choses, et aucune n’a rien de spectaculaire. {{1}}Microsoft a publié des paquets corrigés dans les trois écosystèmes{{/1}} et {{2}}révisé l’avis pour les nommer{{/2}}. {{3}}L’écosystème du renseignement sur les vulnérabilités l’a absorbé discrètement{{/3}} : {{4}}un score EPSS faible{{/4}}, et {{5}}une fiche NVD modifiée pour la dernière fois le 17 juin 2026{{/5}}. Et {{6}}la communauté des normes l’a adopté comme cas d’école{{/6}}, une forme de réponse plus lente et plus durable qu’un correctif.

Pour quiconque exécute encore une version affectée, la remédiation est inchangée et peu glamour : passer à 1.0.2 ou une version ultérieure sur la ligne stable, ou à 2.0.0-beta.17 ou une version ultérieure sur la ligne preview, dans chaque gestionnaire de paquets que le déploiement touche. Au-delà, la logique même de l’avis implique trois mesures de contrôle — restreindre ce que le serveur peut joindre en sortie, n’accorder à l’identité managée que les rôles dont ses outils ont réellement besoin, et traiter comme une entrée hostile tout paramètre d’outil susceptible de devenir une URL. Aucune de ces mesures n’est nécessaire pour avoir survécu à CVE-2026-26118. Chacune réduirait la valeur que la suivante représente pour un attaquant.

Comment l'archive classe celui-ci

L'enregistrement est classé comme une vulnérabilité — quelque chose qui a été découvert, et non quelque chose dont l'exploitation est connue — avec une confiance de grade A, ce qui signifie qu'elle est bien documentée et que des sources primaires concordent, et il n'est pas marqué comme contesté. Son champ real-harm est false et son implication de l'IA est confirmée, car le produit concerné est le pont entre un agent IA et un plan de contrôle cloud, plutôt qu'un service à usage général qui se trouverait simplement à proximité. La date est enregistrée à la précision du jour, le 10 mars 2026, sans date de fin, car il s'agit d'un instant précis plutôt que d'une campagne. La région est mondiale et l'indicateur landmark est false.

Un champ se lit différemment de la notation publiée. La gravité de l’archive est consignée comme moyenne, selon sa propre échelle ; le nombre publié tant par Microsoft que par NVD est 8,8, que Microsoft qualifie d’Important et que NVD classe dans la tranche High. Le résumé de l’enregistrement commence par ce 8,8, et l’écart tient à un découpage en catégories différent plutôt qu’aux faits.

Ce que le compte rendu ne peut pas transmettre, c’est quelle part de cette histoire relève de l’absence. Il y a une faille qui remet une identité cloud à quiconque la demande sous une forme incorrecte. Il existe un correctif, publié avant l’annonce. Il n’y a aucun découvreur crédité, aucun outil nommé, aucune exploitation confirmée et aucun moyen pour un observateur extérieur de savoir si un déploiement hébergé a jamais exécuté une version vulnérable tout en détenant une identité puissante. L’avis est précis sur ce que fait la faille et silencieux sur presque tout le reste, et ce silence est ce qu’il y a de plus utile à remarquer à son sujet.