SDK Python MCP : une faille permet à un serveur malveillant de voler des identifiants OAuth

Les mainteneurs du SDK Python officiel du Model Context Protocol (MCP) ont publié le 28 septembre 2026 un avis de sécurité : un serveur MCP malveillant peut amener une application cliente à lui remettre les identifiants OAuth qu’elle utilise pour se connecter à un vrai service, la faille étant corrigée dans les versions 1.30.0 et 2.2.0 du SDK.

Que permet cette faille du SDK MCP ?

Le MCP est un standard ouvert qui relie des applications d’IA à des outils et à des données. Quand un client MCP doit se connecter à un service, il demande au serveur MCP où se trouve le serveur d’autorisation, c’est-à-dire le service de connexion. Dans les versions touchées, le SDK ne vérifiait pas toujours cette réponse. Un serveur hostile pouvait désigner le sien, ou publier des informations de connexion qui citent le service légitime tout en renvoyant les identifiants ailleurs.

Le client envoyait alors à l’attaquant son secret client, le code d’autorisation et la clé PKCE, une valeur à usage unique censée empêcher la réutilisation d’un code volé. Avec ces éléments, l’attaquant peut demander un jeton d’accès valide au vrai service. La société de sécurité Cycode, qui a signalé la faille, a démontré l’échange complet ; le jeton obtenu porte les droits accordés à l’application, et le secret client, de longue durée, reste utilisable tant qu’il n’est pas changé.

Quelle gravité et quelles applications sont concernées ?

La faille est notée 7,5 (élevée) pour les deux fournisseurs qui fonctionnent sans intervention humaine, et 6,5 pour le fournisseur interactif, où une personne doit lancer la connexion. Aucun identifiant CVE n’avait été attribué au 29 septembre. Sont concernées les applications qui utilisent le SDK comme client MCP en HTTP avec l’un des fournisseurs OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider ou l’ancien RFC7523OAuthClientProvider, et qui peuvent se connecter à un serveur qu’elles ne contrôlent pas. Les serveurs MCP bâtis avec le SDK, les clients locaux (stdio) et ceux qui fournissent leurs propres jetons ne sont pas touchés.

Avec le fournisseur interactif, la page approuvée par l’utilisateur est la vraie page de connexion : rien ne paraît anormal.

Comment se protéger ?

• Passer à la version 1.30.0 (branche 1.x) ou 2.2.0 (branche 2.x).

• Pour ClientCredentialsOAuthProvider et PrivateKeyJWTOAuthProvider, la mise à jour ne change rien tant que le paramètre issuer= n’est pas renseigné avec le service de connexion attendu. Sous 1.30.0, l’avertissement est un simple avertissement de dépréciation, masqué par défaut par Python.

• Abandonner RFC7523OAuthClientProvider, qui n’a pas d’option issuer=.

• Effacer une fois les enregistrements de clients OAuth stockés, car les anciens ne sont pas liés à un service.

• En cas de connexion possible à un serveur douteux, renouveler le secret client et révoquer les jetons.

Sur les anciennes versions, la seule parade est de ne se connecter qu’à des serveurs MCP de confiance. Pour le contexte de l’écosystème des connecteurs, voir notre article sur la place de marché de connecteurs et plugins de Claude.

Ce qui n’est pas établi

Ni l’avis ni Cycode ne signalent d’attaque réelle exploitant la faille. Les contrôles d’émetteur figuraient dans les notes de version du 7 septembre, classés parmi les changements de comportement plutôt que comme correctif de sécurité, et l’avis n’a suivi que le 28 septembre : des équipes ont pu mettre à jour sans savoir qu’il s’agissait d’un correctif de sécurité.

Source

• The Hacker News — Official MCP Python SDK Flaw Can Let Malicious Servers Steal OAuth Credentials, qui s’appuie sur l’avis de sécurité des mainteneurs du SDK et sur l’analyse de Cycode.