CVE-2026-32211 : authentification absente dans Azure MCP Server

De quoi s’agit-il ?

Le 2 avril 2026, Microsoft a publié CVE-2026-32211, une vulnérabilité de divulgation d’informations dans Azure MCP Server. La description, reprise dans la fiche NVD, est directe : « Missing authentication for critical function in Azure MCP Server allows an unauthorized attacker to disclose information over a network » (absence d’authentification sur une fonction critique permettant à un attaquant non autorisé de divulguer des informations sur le réseau).

La faiblesse sous-jacente est classée CWE-306 — Missing Authentication for Critical Function. Concrètement, une fonction qui aurait dû exiger que l’appelant prouve son identité ne le faisait pas : une requête atteignant le serveur via le réseau récupère des données qu’elle n’aurait jamais dû voir. L’outillage MCP de Microsoft expose des opérations sur des ressources cloud ; un point d’accès MCP qui répond à n’importe qui est exactement la « fonction critique » visée par CWE-306.

Cette entrée mérite l’attention non parce qu’elle est exotique — c’est l’inverse — mais parce qu’elle est une instance propre, nommée et confirmée par l’éditeur de la façon la plus courante dont échouent les déploiements Model Context Protocol : ils sont exposés sur un réseau sans aucune authentification en amont.

Comment ça marche

Il n’y a pas de payload astucieux ici, et nous n’en publions volontairement aucun. Le mécanisme tient à l’absence d’un contrôle, pas à la présence d’une ruse :

1. Une fonction est exposée sur le réseau. Azure MCP Server répond à des requêtes qui renvoient des informations sur l’environnement auquel il est relié.
2. Le contrôle d’authentification manque. Conformément à CWE-306, la fonction critique ne vérifie pas l’identité de l’appelant avant d’agir, donc une requête non autorisée (selon le texte de la CVE) est honorée.
3. Des informations reviennent. L’attaquant, qui ne s’est jamais authentifié, reçoit des données que la fonction devait protéger derrière un identifiant.

Le score raconte une histoire utile sur la lecture d’une CVE. Microsoft, en tant qu’autorité d’attribution (CNA), a noté la faille 9,1 Critique, vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Les analystes du NVD ont divergé sur une dimension et l’ont notée 7,5 Élevée, vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Tous deux conviennent que la faille est accessible par le réseau (AV:N), sans privilège (PR:N) ni interaction (UI:N), et fuit la confidentialité (C:H). Ils divergent seulement sur l’intégrité : Microsoft a attribué I:H, le NVD I:N. Quand deux sources sérieuses publient deux scores pour le même bug, ce n’est pas une erreur à ignorer : c’est une invitation à lire le vecteur, pas le chiffre en titre.

Microsoft étiquette le problème comme une vulnérabilité de « service exclusivement hébergé » (exclusively hosted service). Dans les conventions CVE de Microsoft, cela signifie que le composant affecté tourne dans le cloud de Microsoft et que le correctif est appliqué côté Microsoft, sans correctif à installer par les clients — la CVE est publiée par souci de transparence. Cela ne rend pas la leçon optionnelle : quiconque exploite un serveur MCP qu’il contrôle vraiment hérite du même mode de défaillance.

Pourquoi c’est important

Les serveurs MCP se situent à un carrefour dangereux. Ils sont conçus pour donner à un agent LLM de vraies capacités — lire telle ressource, interroger tel système — ce qui fait d’un point d’accès MCP, par construction, une passerelle vers des données et des actions. Placez-en un sur un réseau sans authentification et vous avez bâti une API ouverte vers tout ce qu’il peut atteindre.

CVE-2026-32211 est un point dans un schéma que ce site suit depuis le printemps. Une étude de mai 2026 portant sur 7 973 serveurs MCP distants actifs a révélé que 40,55 % exposaient leurs outils sans aucune authentification, et que chaque serveur OAuth testé présentait au moins une faille (voir serveurs MCP distants : 40 % sans authentification). Le balayage à l’échelle d’Internet raconte la même histoire pour le reste de la pile — la défaillance récurrente tient aux valeurs par défaut permissives, pas à des bugs exotiques. Et le rapport State of Agentic AI Security d’OWASP de juin 2026 place la couche protocole-et-chaîne-d’approvisionnement au centre, recensant des CVE plutôt que des hypothèses. Quand le serveur MCP officiel de Microsoft lui-même atterrit sur cette liste, l’argument « ça n’arrive pas à un éditeur sérieux » s’effondre.

Le cadrage « divulgation d’informations » sous-estime aussi le risque agentique. Une fuite en lecture seule est déjà fâcheuse, mais dans un pipeline d’agents, cette même portée non authentifiée devient le point d’appui qui alimente les étapes suivantes — combinez accès aux données, contenu non fiable et capacité d’agir et vous revenez à la triade létale.

Défenses

Traitez chaque serveur MCP — hébergé ou auto-géré — comme un service authentifié et segmenté sur le réseau, jamais comme une commodité posée sur un port.

1. Authentifiez le serveur, pas seulement le modèle. Exigez une identité d’appelant vérifiée (mTLS, OAuth avec validation des jetons, ou une passerelle qui l’impose) avant l’exécution de toute fonction outil. CWE-306 se corrige en ajoutant le contrôle manquant.
2. N’exposez pas MCP à des réseaux qui n’en ont pas besoin. Liez le service à localhost ou à un segment privé par défaut ; placez tout accès distant derrière un reverse proxy qui termine l’authentification. Cela rejoint les recommandations de mitigation de Microsoft pour le cas hébergé (restreindre l’accès réseau, le placer derrière un accès authentifié).
3. Appliquez le moindre privilège à la portée du serveur. Même authentifié, un serveur MCP ne devrait détenir que des identifiants limités aux ressources strictement nécessaires à ses outils, pour qu’un contournement fuite moins.
4. Inventoriez votre surface MCP. La plupart des organisations ne savent pas lister les points d’accès MCP qui tournent chez elles. Scannez-les comme tout autre service exposé et vérifiez l’exigence d’authentification de chacun — voir les considérations de conception MCP de la NSA.
5. Lisez le vecteur, fixez votre propre gravité. Ne laissez pas un unique chiffre CVSS piloter le tri. Pour CVE-2026-32211, l’écart entre le 9,1 de Microsoft et le 7,5 du NVD tient entièrement à la question de l’intégrité — décidez ce qui correspond à votre déploiement.

État des lieux

Élément	Référence	Date	Notes
CVE-2026-32211 publiée	Microsoft / NVD	2026-04-02	« Missing authentication for critical function in Azure MCP Server » (CWE-306)
Score Microsoft (CNA)	Avis MSRC	2026-04-02	9,1 Critique — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Score NVD	Analyse NVD	2026-04-06	7,5 Élevée — C:H/I:N/A:N (diverge sur l’intégrité)
Remédiation	Convention CVE Microsoft	—	Étiqueté « service exclusivement hébergé » ; correctif côté Microsoft, pas de patch client
Contexte élargi	OWASP / scans arXiv	2026-05 à 06	~40 % des serveurs MCP distants tournent sans authentification

À retenir : non pas qu’Azure MCP Server ait été particulièrement négligent, mais que « déployer le point d’accès MCP, ajouter l’authentification plus tard » est un réflexe répandu dans toute l’industrie, et que CVE-2026-32211 en est la version portant le nom d’un grand éditeur et un CVSS 9,1. Si vous exploitez du MCP quelque part, la question à trancher aujourd’hui est simple : lequel de vos serveurs répondra à un inconnu ?

Cet article résume des informations de vulnérabilité publiques, divulguées par l’éditeur, à des fins défensives et éducatives. Il ne reproduit aucun code d’exploitation.