SDK Python MCP expose les identifiants OAuth à un serveur malveillant

Contexte et portée de la vulnérabilité

Le Model Context Protocol (MCP) est un standard ouvert permettant aux applications d’IA d’interagir avec des outils externes via OAuth. Le SDK officiel Python, utilisé pour implémenter des clients et serveurs MCP, présentait une faille dans les versions 1.9.1‑1.29.1 et 2.0.0‑2.1.1. La faille permettait à un serveur MCP contrôlé par un attaquant de récupérer le client secret, le code d’autorisation et la clé PKCE d’un client légitime.

Ces trois éléments suffisent à obtenir un access token valable auprès du service d’authentification réel, car le secret OAuth est long‑vivant et la clé PKCE, bien que conçue pour être à usage unique, était transmise à l’attaquant. La gravité a été évaluée à 7,5 pour les fournisseurs machine‑to‑machine et à 6,5 pour le fournisseur interactif. Aucun CVE n’était encore attribué au moment de la divulgation.

Mécanisme d’exploitation

Lors du processus d’authentification, le client MCP interroge le serveur auquel il se connecte pour connaître l’URL de l’autorisation (authorization server). Dans les versions vulnérables, le SDK ne validait pas systématiquement que l’URL retournée correspondait à celle attendue. Un serveur malveillant pouvait donc renvoyer une URL pointant vers son propre endpoint token.

Le client, croyant communiquer avec le service légitime, envoyait alors son secret, le code d’autorisation et la clé PKCE à cet endpoint. L’attaquant, en possession de ces valeurs, pouvait demander un token d’accès au vrai service d’authentification, le token hérite alors des mêmes permissions que l’application victime. Pour les fournisseurs sans interaction humaine (ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider), l’attaque se déroule entièrement en arrière‑plan.

Correction et recommandations

Les correctifs sont disponibles dans les versions 1.30.0 (ligne 1.x) et 2.2.0 (ligne 2.x). Le SDK mis à jour vérifie que l’URL de l’autorisation correspond à l’émetteur attendu avant toute transmission de données sensibles. Cependant, pour les fournisseurs ClientCredentialsOAuthProvider et PrivateKeyJWTOAuthProvider, il faut également fournir explicitement le paramètre issuer= afin de contraindre le client à accepter uniquement l’émetteur légitime.

Après mise à jour, il est recommandé de purger les enregistrements OAuth précédemment stockés, de faire pivoter le client secret et de révoquer les tokens déjà émis. Les applications qui ne peuvent pas être mises à jour doivent restreindre les connexions aux seuls serveurs MCP de confiance, faute de quoi aucune mitigation technique n’est disponible.

La divulgation a été publiée le 28 septembre 2026, les notes de version comportant les changements de comportement depuis le 7 septembre. Aucun incident réel n’a été signalé, mais la nature de la faille justifie une mise à jour immédiate pour les environnements de production.