Python MCP SDK mis à jour à 1.30.0 / 2.2.0 pour corriger la vulnérabilité des identifiants OAuth

Les responsables officiels du SDK de Python pour le Model Context Protocol (MCP) ont corrigé une vulnérabilité qui a permis à un serveur MCP malveillant de tromper un client et de lui faire livrer des identifiants OAuth valides utilisés pour se connecter à un service réel. Dans les versions touchées, le client a envoyé l'attaquant secret client, code d'autorisation et la clé PKCE (clé d'épreuve), des éléments suffisants pour que l'agresseur puisse demander l'accès aux permis que la demande avait reçus.

D'une manière technique, le problème se pose dans la phase où un client MCP demande le serveur avec lequel l'emplacement de son service d'autorisation est connecté. Dans les versions vulnérables, le SDK n'a pas vérifié de manière fiable que l'URL ou l'émetteur (émetteur) du serveur d'autorisation coïncidait avec celui que le client attendait avant de suivre l'échange OAuth. Un serveur malveillant pourrait répondre en pointant vers l'extrémité de jeton contrôlée par l'attaquant - ou en falsifiant les métadonnées pour nommer le service légitime tout en dirigeant les demandes ailleurs - et ainsi recevoir le secret client, le code d'autorisation et la valeur PKCE. La livraison de la valeur PKCE élimine la protection qui empêche la réutilisation d'un code d'autorisation intercepté.

Cycode, l'entreprise qui a signalé et démontré le problème, a procédé à un échange de preuves et a montré que le jeton résultant portait les mêmes permis que ceux initialement autorisés pour la demande. L'ADvisory du SDK place la gravité à 7,5 pour les fournisseurs opérant sans présence humaine (machine-to@-@ machine) et 6,5 pour le fournisseur interactif, où quelqu'un doit encore approuver la connexion. Les rectifications apparaissent dans les versions 1,30,0(branche 1.x) et 2.2.0(branche 2.x) du SDK; les modifications ont été incluses dans les notes de version publiées le 7 septembre et l'avis de sécurité a été publié le 28 septembre, le même jour que Cycode a publié son analyse.

Faits confirmés : Le SDK Python officiel pour MCP a envoyé le secret client, le code d'autorisation et la clé de preuve PKCE à un paramètre contrôlé par un serveur MCP malveillant dans des versions antérieures à 1.30.0 / 2.2.0; Cycode a démontré l'échange en laboratoire; la correction est en 1.30.0 et 2.2.0; l'avertissement sur le comportement est apparu d'abord comme un changement de comportement dans les notes de version; il n'y avait pas CVE assigné au 29 septembre; il n'y avait aucun rapport de ses exploits dans le champ selon l'avis et le rapport Cycode.

Quelles sont les répercussions des mises en œuvre et des rôles? les applications qui utilisent le SDK commeClient MCPsur HTTP et en utilisant l'un de ces fournisseurs OAuth intégrés: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider ou le RFC7523OauthClient obsolète Fournisseur de la série 1.xseries. Pour que l'exposition existe, le client doit pouvoir se connecter à un serveur MCP qui ne contrôle pas entièrement (par exemple, des serveurs tiers). Les serveurs MCP construits avec le SDK, les clients locaux (stdio) et les clients qui fixent manuellement leurs propres jetons ne sont pas affectés.

Incidences pratiques: Avec les pouvoirs volés, un attaquant peut les échanger contre un jeton d'accès valide dans le service d'authentification légitime et agir avec les permis accordés à la demande. Le secret du client est généralement de longue durée, de sorte que l'exposition reste efficace jusqu'à ce que le secret soit brisé. Dans les scénarios machine-à-machine, cela peut permettre un accès automatisé sans besoin d'interaction humaine; dans le cas d'un flux interactif, la page de connexion approuvée par l'utilisateur peut être authentique et ne pas afficher de signes visibles de manipulation, de sorte que la victime ne perçoit rien d'anormal pendant l'autorisation.

Mesures spécifiques et immédiates à prendre par les responsables: d'abord, mettre à jour le SDK dans les versions corrigées: 1.30.0 pour la branche 1.x ou 2.2.0 pour la 2.x. Deuxièmement, pour ClientCredentialsOauthProvider ou PrivateKeyJWTOAuthProvider utilisateurs, en plus de la mise à jour, ils doivent fournir explicitement le problème = paramètre qui relie ces identifiants au service d'autorisation auquel ils appartiennent; sans ce paramètre, les identifiants continueront à accepter l'adresse indiquée par le serveur MCP. Le fournisseur obsolète RFC7523OauthClientProvider ne supporte pas la question = et devrait être remplacé par l'un des deux autres. Troisièmement, après la mise à jour, supprimer seulement une fois tous les fichiers clients OAuth stockés localement par les anciennes versions, parce que ces fichiers n'étaient pas liés à un problème et resteraient dangereux. Enfin, s'il est possible qu'un client se soit déjà connecté à un serveur peu fiable, faire immédiatement pivoter le secret du client et révoquer les jetons et les autorisations dans le service d'identité pertinent.

À titre de mesures temporaires supplémentaires d'atténuation : éviter de connecter les clients de MCP à des serveurs qui ne contrôlent pas ou ne peuvent pas vérifier; permettre des contrôles de réseau qui limitent les destinations de bout en bout aux services légitimes; enregistrer et examiner les échanges OAuth et émettre des exceptions dans le journal d'audit pour détecter une activité anormale. Vérifiez la documentation du fournisseur d'identité pour les procédures de rotation et de révocation des clients et les jetons.

Limites et zones d'incertitude: Il n'existe aucune preuve publique que la vulnérabilité ait été exploitée dans les environnements de production à ce jour; toutefois, l'absence de rapports ne garantit pas qu'il n'y a pas d'abus non détecté. Un CVE n'avait pas non plus été assigné le 29 septembre - cela pourrait changer si les responsables ou les tiers enregistrent plus tard l'échec à la base du CVE. L'évaluation d'impact sur des systèmes spécifiques dépendra de la façon dont chaque organisation gère les secrets, les dossiers clients et le contrôle des serveurs MCP externes.

Pour mieux comprendre pourquoi cette vulnérabilité est particulièrement dangereuse, le modèle OAuth devrait être revu : OAuth 2.0 RFC 6749 et les mécanismes PKCE sont conçus pour garantir qu'un code d'autorisation n'est pas réutilisable par un tiers. Si le client livre volontairement la clé PKCE à l'attaquant, cette barrière est annulée. Pour des informations techniques et des recommandations sur la gestion des avertissements en Python (par exemple, la déprécation qui peut être cachée par défaut à 1.30.0), voir la documentation officielle d'avertissement en Python docs.python.org. Le rapport technique et la démonstration de l'entreprise qui a signalé le problème sont disponibles sur le site Cycode: Cycode.

En bref : si votre application utilise le SDK MCP officiel comme client et fait confiance aux serveurs MCP qui ne contrôlent pas, mettent à jour dès que possible, configurent le problème le cas échéant, révoquent et font pivoter les identifiants s'il y a exposition potentielle, et examinent vos dossiers et vos politiques de connexion aux serveurs externes. Ces actions spécifiques sont les seules qui réduisent le risque qu'un serveur MCP malveillant transforme une interaction légitime en un engagement d'identification OAuth.