Serveurs MCP distants : 40 % sans authentification, OAuth cassé sur le reste

What is this?

Un article arXiv de mai 2026, A First Measurement Study on Authentication Security in Real-World Remote MCP Servers (cs.CR, 2605.22333), constitue la première analyse à grande échelle de la couche d’authentification des serveurs Model Context Protocol distants — ces programmes accessibles sur le réseau qui exposent des outils (requêtes base de données, appels d’API, accès fichiers) aux agents LLM. La plupart des travaux précédents portaient sur l’injection de prompt et le tool poisoning ; cette étude vise la question de couche protocolaire : qui a le droit de se connecter.

La mesure principale est sans appel. Sur 7 973 serveurs MCP distants validés et actifs, 3 233 (40,55 %) exposent leur interface d’outils sans aucune authentification — n’importe quel client peut invoquer des outils ou déclencher des appels d’API sans présenter d’identifiant. Pour le reste, OAuth est le mécanisme dominant (2 428 serveurs), et lorsque les auteurs ont testé manuellement un sous-ensemble entièrement reproductible de 119 serveurs OAuth, chacun présentait au moins une faille d’authentification — 325 failles au total. Neuf étaient assez graves pour recevoir un identifiant CVE après divulgation responsable (la série CVE-2026-26384 à CVE-2026-26390). Ce constat complète le scan de qualité de code VIPER-MCP et les décomptes d’exposition plus larges : non seulement ces serveurs sont vulnérables et trop exposés, mais leur porte d’entrée est souvent déverrouillée.

How it works

La spécification MCP a rendu OAuth 2.1 avec PKCE obligatoire pour les transports HTTP dans sa révision du 26 mars 2025, et la version du 25 novembre 2025 a privilégié les Client ID Metadata Documents tout en conservant le Dynamic Client Registration (DCR) comme repli de compatibilité. En pratique, les serveurs distants s’appuient sur le DCR car ils doivent accepter des clients hétérogènes — IDE, CLI, applications de bureau, agents cloud — impossibles à pré-enregistrer à la main. L’article dégage trois traits récurrents de ces déploiements et construit autour d’eux une taxonomie de neuf types de failles réparties en quatre catégories. Décrite au niveau du mécanisme, pas du payload :

Category                          Representative flaw            Effect
--------------------------------  ----------------------------  ---------------------------
C1 Dynamic Client Registration    Malicious DCR binding         Anonymous registrant submits
   (96.6% of tested servers)      (F1, 95.8%)                   an attacker redirect_uri and
                                                                gets a valid client_id back.
C3 Open Client Environment        PKCE downgrade (F5, 68.1%)    Server accepts a missing or
   (85.7% of tested servers)                                    "plain" code_challenge,
                                                                nullifying PKCE binding.
C2 Delegated Authorization        Layer inconsistency (F3)      PKCE enforced on the first
   (15.1% of tested servers)      Nested context pollution (F4) hop but dropped on the
                                                                upstream hop; unvalidated
                                                                redirect_uri inside `state`.
C4 Common OAuth misconfig         Standard OAuth hygiene gaps   Reuse/replay of codes, weak
                                                                state/CSRF handling.

La défaillance dominante est la plus simple : un point d’entrée DCR qui accepte n’importe quel redirect_uri d’un enregistrant non authentifié. L’attaquant enregistre un client pointant vers un serveur qu’il contrôle, fabrique une URL d’autorisation avec ce callback et amène par ingénierie sociale une victime à compléter le flux de consentement. Le code d’autorisation est alors livré à l’attaquant, qui l’échange contre un jeton d’accès et prend le contrôle de la session MCP de la victime — et, via l’autorisation déléguée, des comptes de service en amont. Lorsqu’un serveur autorise en plus l’omission de PKCE, voler le code suffit à lui seul. Aucun client MCP malveillant n’est requis ; l’attaquant doit seulement envoyer des requêtes HTTP vers des points d’entrée publics et héberger une page. Aucun exploit fonctionnel n’est reproduit ici — la référence reste l’article et les CVE attribuées.

Why it matters

Le MCP distant devient le tissu conjonctif entre les agents et les systèmes réels, ce qui rend sa couche d’authentification structurante. Deux constats devraient changer la façon dont les équipes la traitent. Premièrement, 40 % sans authentification est une exposition directement exploitable, pas théorique : ces serveurs confient l’exécution d’outils à quiconque peut les atteindre, et selon le récapitulatif Adversa de juin 2026, Censys a dénombré 12 520 services de ce type sur l’Internet public. Deuxièmement, la présence d’une authentification n’équivaut pas à une authentification correcte — chaque serveur OAuth testé était défaillant, et la faille la plus répandue (liaison DCR ouverte) mène directement à la prise de contrôle de compte. Comme le serveur MCP joue souvent à la fois le rôle de serveur de ressources OAuth et de client OAuth vis-à-vis des services en amont, un seul maillon cassé devient un problème de « confused deputy » s’étendant à des plateformes exploitées indépendamment.

Defenses

Les correctifs relèvent de l’hygiène OAuth standard que le code des serveurs MCP néglige régulièrement.

1. Verrouillez le Dynamic Client Registration. N’acceptez pas de redirect_uri arbitraire d’un enregistrant anonyme. Mettez en liste blanche les callbacks exacts, exigez une authentification sur le point d’entrée d’enregistrement, et préférez les Client ID Metadata Documents (mécanisme privilégié par la spécification du 25 novembre 2025) au DCR ouvert.

2. Imposez PKCE, refusez les downgrades. Exigez S256 ; rejetez les requêtes qui omettent code_challenge ou utilisent la méthode plain. PKCE est la liaison principale dans les environnements à client ouvert où aucun client_secret ne peut être protégé.

3. Validez les URI de redirection par correspondance exacte et liez le flux. Gardez les codes d’autorisation à usage unique et de courte durée, liés au même client et au même vérifieur PKCE ; préservez state contre le CSRF ; protégez en intégrité toute URI intégrée dans state.

4. Gardez PKCE cohérent sur les sauts délégués. Si le premier saut impose PKCE, la requête en amont doit le faire aussi — l’incohérence de couche annule silencieusement la garantie.

5. Authentifiez chaque serveur distant et désexposez le reste. L’action la plus efficace : placer une authentification devant chaque serveur MCP distant et retirer les serveurs non authentifiés de l’Internet public. À associer à l’admission attestée de serveurs d’outils et aux considérations de conception de sécurité MCP de la NSA comme socle.

Status

Élément	Référence	Date	Notes
Étude de mesure	arXiv:2605.22333 (cs.CR)	2026-05	Première étude d’authentification des serveurs MCP distants
Exposition	Article	2026-05	7 973 serveurs actifs ; 3 233 (40,55 %) sans authentification
Failles OAuth	Article	2026-05	119 serveurs testables, tous défaillants ; 325 failles au total
Faille dominante	Article	2026-05	Liaison DCR ouverte dans 95,8 % → vol du code d’autorisation
Divulgation	Article	2026-05	Divulgation responsable ; 9 CVE attribuées (CVE-2026-26384–26390)
Contexte écosystème	Récap Adversa / Censys	2026-06-04	12 520 services MCP exposés sur Internet

Le bon cadrage n’est pas « OAuth est cassé » — c’est que les serveurs MCP distants réimplémentent OAuth sous la pression du déploiement et se trompent sur les points difficiles, tandis qu’une part importante saute purement l’authentification. Traitez votre couche d’authentification MCP comme n’importe quelle surface OAuth publique : verrouillez l’enregistrement, imposez PKCE, et placez un identifiant devant tout ce qui peut exécuter un outil.