Les outils MCP ont besoin d’une autorisation au niveau de l’action

Le 17 mai 2026, la NVD a publié CVE-2026-8719 pour AI Engine 3.4.9, un plugin WordPress qui expose des fonctionnalités d’IA et de MCP aux sites WordPress.¹³

Ce mode de défaillance devrait mettre mal à l’aise toute personne qui construit des serveurs MCP. Wordfence a décrit l’absence d’un contrôle de capacité WordPress dans le chemin d’autorisation OAuth par jeton Bearer de MCP : n’importe quel jeton OAuth valide pouvait accéder à des outils MCP de niveau administrateur sans vérification des privilèges d’administrateur.² Wordfence a attribué à la faille une note de 8,8, avec un niveau de gravité élevé, et indique que la version 3.5.0 contient le correctif.² Le journal des modifications du plugin précise que la version 3.5.0 a corrigé l’autorisation OAuth MCP et la validation des jetons en exigeant une capacité d’administrateur.³

L’autorisation MCP échoue lorsqu’un serveur traite la possession d’un jeton Bearer comme une permission d’utiliser tous les outils. OAuth peut prouver qu’un jeton est arrivé par un flux d’autorisation. Le serveur MCP doit tout de même décider si ce sujet peut exécuter cet outil, sur cette ressource, avec ce rayon d’impact.

TL;DR

La spécification d’autorisation HTTP de MCP donne aux constructeurs une base nécessaire : métadonnées de ressource protégée, flux OAuth 2.1, gestion des jetons Bearer, validation des jetons, contrôles d’audience et réponses explicites 403 Forbidden en cas de portées ou de permissions insuffisantes.⁴ Le tutoriel de sécurité MCP présente l’autorisation comme la couche de protection des ressources et opérations sensibles exposées par les serveurs MCP.⁵ Ces mécanismes ne suppriment pas la décision d’autorisation au niveau applicatif. Un serveur doit encore associer le jeton à un utilisateur, un rôle, un tenant, un outil, une ressource, une action et une politique.

CVE-2026-8719 rend cette distinction concrète. AI Engine a ajouté OAuth 2.1 et Dynamic Client Registration à son serveur MCP dans la version 3.4.9, le 12 mai, puis a corrigé l’autorisation OAuth MCP et la validation des jetons dans la version 3.5.0, le 16 mai, en exigeant une capacité d’administrateur.³ La leçon dépasse WordPress : tout serveur MCP capable de modifier des données, de publier du contenu, de changer des paramètres, de lire des enregistrements privés, de dépenser de l’argent ou d’appeler des API privilégiées a besoin d’une autorisation au niveau de l’action, sous le modèle et sous le client.

La distribution d’outils augmente le risque. Un article de mai 2026 sur le clonage d’outils a mesuré 8 861 dépôts MCP et Skills contenant 100 011 entrées d’outils, et a trouvé des taux élevés de clones vérifiés dans les groupes à forte similarité.⁶ Les modèles réutilisés peuvent diffuser de bonnes pratiques. Ils peuvent aussi diffuser des contrôles manquants.

Points clés

Pour les constructeurs de serveurs MCP : - Validez les jetons, puis autorisez l’action concrète. Traitez ces deux étapes comme des contrôles distincts. - Renvoyez 401 pour les jetons invalides ou absents, et 403 pour les jetons valides dépourvus de la portée ou de la permission requise. - Testez les jetons à faibles privilèges contre chaque outil d’administration, d’écriture, de publication, de suppression, d’export et de configuration.

Pour les équipes de sécurité : - Examinez les serveurs MCP comme des points de terminaison applicatifs, pas comme des plugins de chat. - Demandez à quel utilisateur, rôle, tenant, ressource et action correspond chaque appel d’outil. - Exigez des journaux indiquant le sujet du jeton, le nom de l’outil, la ressource, le verdict d’autorisation et la raison du refus.

Pour les équipes de plateformes d’agents : - Les volumes des places de marché ne prouvent pas l’existence d’implémentations indépendantes. - Les contrôles de similarité et de provenance comptent, car des outils clonés peuvent copier une logique d’autorisation vulnérable. - Traitez les modèles de serveurs comme une infrastructure sensible du point de vue de la sécurité.

Pour les opérateurs : - Mettez AI Engine à niveau vers la version 3.5.0 ou ultérieure si vous exécutez le plugin WordPress concerné.²³ - Désactivez l’exposition MCP tant que vous ne savez pas quels rôles WordPress peuvent accéder à quels outils. - Lancez toute nouvelle connexion MCP en mode lecture seule, puis élargissez l’autorité uniquement après que les tests ont prouvé les chemins de refus.

Ce qui a cassé dans AI Engine

AI Engine présente MCP comme un moyen de connecter Claude Code, Claude, ChatGPT, OpenClaw et d’autres clients à un site WordPress au moyen d’une URL, d’un flux de connexion et d’une étape d’approbation.³ La version 3.4.9 a ajouté OAuth 2.1 avec Dynamic Client Registration pour le serveur MCP, afin que les clients pilotés par navigateur puissent se connecter sans jeton Bearer partagé.³

Cette orientation produit est logique. Les jetons statiques partagés conviennent mal aux intégrations MCP destinées aux utilisateurs. Les flux OAuth peuvent lier un client, un utilisateur et un serveur plus proprement que des secrets copiés-collés.

Le bug se situait une couche plus bas. D’après la NVD et Wordfence, le chemin vulnérable acceptait n’importe quel jeton OAuth valide pour l’accès MCP, sans vérifier le privilège d’administrateur avant d’accorder l’accès à des outils MCP de niveau administrateur.¹² La distinction est essentielle :

La description du correctif sur la page du plugin WordPress emploie les bons termes : l’autorisation OAuth MCP et la validation des jetons exigent désormais une capacité d’administrateur, ce qui empêche l’escalade de privilèges par des utilisateurs non administrateurs.³ Cette phrase nomme la couche manquante. Un jeton ne peut pas remplacer un contrôle de capacité.

OAuth est nécessaire, pas suffisant

La spécification d’autorisation MCP couvre le flux au niveau transport pour les transports basés sur HTTP. Elle indique que les clients MCP adressent des requêtes à des serveurs MCP restreints pour le compte de propriétaires de ressources, et elle ancre le flux dans OAuth 2.1, les métadonnées de ressource protégée, les métadonnées de serveur d’autorisation, Dynamic Client Registration et l’usage de jetons Bearer.⁴

Ces éléments résolvent de vrais problèmes :

La spécification MCP met aussi en garde contre les risques de confused deputy et de transmission de jeton. Les serveurs MCP doivent vérifier que les jetons présentés ciblent bien le serveur MCP, et ne doivent pas transmettre à des API en amont un jeton reçu du client MCP.⁴ Cette recommandation protège la frontière entre services.

L’autorisation au niveau de l’action protège la frontière à l’intérieur du serveur MCP.

Un serveur MCP peut exposer 10 outils ou 100. Certains lisent des métadonnées publiques. Certains lisent des enregistrements privés. Certains préparent des modifications. Certains modifient l’état de production. Certains administrent des utilisateurs, plugins, paiements, tâches, messages ou infrastructures. Un jeton valide ne devrait pas accéder automatiquement à tous les outils parce que le serveur a accepté la session.

La chaîne correcte ressemble à ceci :

1. Valider l’émetteur du jeton, sa signature, son expiration, son audience et les règles de transport.
2. Résoudre le jeton vers un sujet local : utilisateur, compte de service, organisation, tenant ou automatisation.
3. Charger le rôle, les portées, les autorisations, les budgets et la politique de ce sujet.
4. Classer l’outil MCP demandé par type d’action et niveau de risque.
5. Contrôler la ressource cible, pas seulement le nom de l’outil.
6. Renvoyer 403 lorsque le jeton est valide mais que l’action dépasse l’autorité accordée.
7. Journaliser la décision avec assez de détails pour permettre un examen.

OAuth amène la requête jusqu’au point de décision. L’autorisation décide si l’action est légitime.

Les appels d’outils exigent une matrice de permissions

Les outils d’agents rendent les vieux réflexes de points de terminaison plus dangereux. Une route web classique est souvent entourée d’un parcours UI étroit. Un outil exposé à un modèle se trouve dans un planificateur. L’agent peut réessayer, enchaîner les appels, inspecter les descriptions d’outils, combiner des résultats de lecture avec des actions d’écriture et transporter des instructions issues de contenu non fiable vers des étapes ultérieures.

Ce comportement modifie le modèle de permissions minimal. Un serveur ne doit pas seulement demander « cet utilisateur peut-il accéder à MCP ? ». Il doit demander « cet utilisateur peut-il effectuer cette action, via cet outil, sur cette ressource, maintenant ? ».

Utilisez une matrice :

Cette matrice correspond au modèle décrit dans Les clés d’agents ont besoin de budgets de risque. Les identifiants ne devraient pas se comporter comme des chaînes Bearer universelles. Ils devraient être des objets d’autorité bornée, avec limites côté serveur, journaux d’activité, révocation et valeurs par défaut prudentes.

Elle correspond aussi au cadre de responsabilité présenté dans La propriété des agents IA est le fondement de la confiance. Chaque appel d’outil privilégié devrait correspondre à un compte responsable, une session, un ensemble d’autorisations, un chemin de revue et un chemin d’arrêt.

Les outils clonés peuvent copier le même contrôle manquant

Le bug d’AI Engine serait important même si chaque serveur MCP provenait d’une implémentation indépendante et soigneuse. L’écosystème des outils n’est pas aussi propre.

Kim, Jiang, Hu, Jia et Gong ont publié le 10 mai 2026 un article mesurant le clonage d’outils dans les écosystèmes d’IA agentique. Leur jeu de données couvre 7 508 dépôts MCP avec 87 564 outils extraits et 1 353 dépôts Skills avec 12 447 outils, soit 8 861 dépôts et 100 011 entrées d’outils.⁶ Les auteurs ont utilisé la similarité de Jaccard au niveau des tokens et la similarité structurelle floue ssdeep, puis ont vérifié manuellement des paires échantillonnées dans plusieurs groupes de similarité.⁶

Le résumé indique que 60 % des candidats MCP à Jaccard élevé et 85 % des candidats MCP à ssdeep élevé ont été vérifiés manuellement comme clones.⁶ L’article soutient que la duplication cachée peut contaminer les séparations de bancs d’essai, propager des implémentations vulnérables, biaiser les mesures de généralisation de l’usage d’outils et soulever des questions de provenance, d’attribution et de licence.⁶

Ce constat change la manière dont les équipes devraient lire la croissance des places de marché MCP. Plus d’outils ne signifie pas automatiquement plus de revues de sécurité indépendantes. Un échafaudage de serveur répété peut apporter de la cohérence à l’écosystème. La même répétition peut copier le même schéma d’authentification faible dans de nombreux paquets.

La revue de sécurité devrait donc inclure la provenance :

Les Skills d’agents ont besoin de gestionnaires de paquets défendait une distribution de type paquet, avec provenance et politique autour des skills. Les serveurs MCP ont besoin de la même discipline, plus des tests d’autorisation à l’exécution.

La suite de tests minimale pour l’autorisation MCP

Tout serveur MCP qui touche des données privées ou modifiables devrait livrer une suite de tests d’autorisation. Les tests unitaires qui confirment le chemin nominal ne suffisent pas. Le comportement dangereux se trouve dans les chemins de refus.

Commencez par ces cas :

Le code de statut exact peut suivre la politique du produit, mais la distinction doit rester claire : les identifiants invalides échouent avant la résolution du sujet, et les identifiants valides dotés d’une autorité insuffisante échouent au contrôle d’autorisation. La spécification MCP nomme 401 pour une autorisation absente ou invalide, et 403 pour des portées invalides ou des permissions insuffisantes.⁴

Pour WordPress en particulier, la règle devient plus nette : les outils MCP qui effectuent des opérations d’administration devraient contrôler les mêmes capacités WordPress que le tableau de bord, l’API REST ou le chemin PHP interne. Un rôle à privilèges réduits ne devrait pas obtenir un nouveau chemin vers un comportement administrateur parce que l’appel arrive par un protocole exposé au modèle.

Ce que les places de marché devraient exiger

Les places de marché MCP et les annuaires de plugins devraient traiter les métadonnées d’autorisation comme des données de paquet de premier ordre. Un utilisateur qui décide d’activer ou non un serveur a besoin de plus qu’un nombre d’outils.

Métadonnées publiques minimales :

Ces champs n’élimineraient pas les outils vulnérables. Ils rendraient la surface de revue réelle. Les opérateurs pourraient comparer l’autorité déclarée au code effectif, et les places de marché pourraient regrouper les implémentations similaires lorsqu’un défaut apparaît.

C’est le pont manquant entre la spécification d’autorisation MCP et l’article sur le clonage d’outils. La spécification indique aux implémenteurs comment réaliser le flux au niveau du protocole. L’écosystème a besoin d’une provenance au niveau paquet et de preuves d’autorisation au niveau de l’action, afin que les implémentations répétées ne répètent pas les mêmes contrôles manquants.

Ce qu’il faut construire à la place

Construisez l’autorisation MCP comme un pipeline :

1. Contrôle de protocole : vérifier les métadonnées de ressource protégée, le flux OAuth, l’emplacement du jeton, la validité du jeton, son expiration, son émetteur et son audience.
2. Contrôle de sujet : associer le jeton à un utilisateur, un compte de service, un rôle, un tenant et un espace de travail.
3. Contrôle d’outil : classer chaque outil en lecture, brouillon, écriture, suppression, publication, export, administration, exécution ou dépense.
4. Contrôle de ressource : autoriser l’objet cible exact ou la frontière exacte du tenant.
5. Contrôle de budget : appliquer les limites de débit, taille, dépense, audience et temps avant l’exécution.
6. Contrôle d’approbation : exiger une approbation humaine ou politique pour les actions à haut risque.
7. Contrôle d’audit : enregistrer les verdicts d’autorisation, de refus et de revue requise dans un endroit consultable par les opérateurs.

Ces contrôles doivent se trouver hors du modèle. Une description d’outil peut dire à l’agent d’éviter les actions d’administration. Une consigne peut demander de la prudence. Aucun des deux ne doit porter la frontière. Le serveur doit rejeter l’action non autorisée même lorsque l’agent la demande poliment, avec assurance ou à plusieurs reprises.

Votre bac à sable d’agent est une suggestion formule le même point sous un autre angle : des permissions valides peuvent encore se composer en comportements dangereux. Les outils MCP ont besoin d’une autorisation à la frontière de l’action parce que l’agent composera les actions plus vite qu’un humain ne peut les simuler mentalement.

FAQ

MCP exige-t-il OAuth ?

Non. L’autorisation MCP est facultative, et la spécification d’autorisation HTTP s’applique lorsqu’une implémentation prend en charge l’autorisation sur des transports basés sur HTTP. La même spécification indique que les transports STDIO devraient récupérer les identifiants depuis l’environnement plutôt que suivre le flux OAuth HTTP.⁴

OAuth résout-il l’autorisation MCP ?

OAuth ne résout qu’une partie du problème. OAuth peut établir un flux d’autorisation, émettre des jetons et permettre à un serveur MCP protégé de valider des jetons Bearer. Le serveur MCP doit encore décider si le sujet du jeton peut effectuer l’action d’outil spécifique sur la ressource cible.

Qu’a prouvé CVE-2026-8719 ?

CVE-2026-8719 a prouvé qu’un chemin à jeton valide peut tout de même oublier l’application des capacités locales. La NVD et Wordfence décrivent AI Engine 3.4.9 comme acceptant n’importe quel jeton OAuth valide pour l’accès MCP, sans vérifier le privilège d’administrateur avant que des outils MCP de niveau administrateur deviennent accessibles.¹²

Que devraient tester les constructeurs MCP en premier ?

Testez d’abord les chemins de refus : jeton à faibles privilèges vers un outil d’administration, jeton en lecture seule vers un outil d’écriture, jeton valide vers la ressource d’un autre tenant, jeton expiré, jeton destiné à une mauvaise audience et outil destructeur sans approbation. Réussir le chemin OAuth nominal ne prouve pas l’autorisation au niveau de l’action.

Pourquoi le clonage d’outils compte-t-il pour la sécurité MCP ?

Le clonage d’outils compte parce que des implémentations répétées peuvent répéter le même intergiciel vulnérable, les mêmes raccourcis d’authentification et les mêmes contrôles manquants. L’article de mai 2026 sur le clonage d’outils a trouvé des taux élevés de clones vérifiés parmi les candidats MCP à forte similarité, et a averti que la duplication cachée pouvait propager des implémentations vulnérables.⁶

Références