veilletech.fr
30 sept. Feed du jour
#01 OAUTH Faille

MCP Python : un faux serveur vole vos secrets OAuth

Un serveur MCP que vous ne contrôlez pas peut choisir à qui vous envoyez vos secrets.

Le SDK Python officiel de MCP pouvait envoyer le secret client, le code d'autorisation et la preuve PKCE d'une application au serveur d'autorisation que lui désignait un serveur MCP malveillant (avis GHSA-qx49-fqc8-xw99). L'attaquant en tire un vrai jeton d'accès, avec les droits de l'application. Corrigé en 1.30.0 et 2.2.0, mais deux fournisseurs exigent en plus le paramètre issuer=.

3 min de lectureintermédiairevidéo 1:17
Partager
Sommaire6 sections
  1. Ce qui se passe
  2. Où le flux déraille
  3. Qui est concerné
  4. Comment s'y prendre
  5. Le calendrier
  6. À retenir

Ce qui se passe

Les mainteneurs du SDK Python officiel de MCP ont publié l'avis GHSA-qx49-fqc8-xw99. Un client MCP qui s'authentifie en OAuth pouvait être amené, par le serveur MCP auquel il se connecte, à remettre ses identifiants à un tiers : le secret client, le code d'autorisation et le vérificateur PKCE.

Avec ces trois éléments, l'attaquant demande au vrai service de connexion un jeton d'accès parfaitement valide, doté de toutes les permissions accordées à l'application. Cycode, qui a signalé le problème, a mené l'échange complet en test. Le secret client ayant une longue durée de vie, il reste utilisable jusqu'à sa rotation.

Score : 7.5 pour les deux fournisseurs qui fonctionnent sans personne devant l'écran, 6.5 pour le fournisseur interactif. Aucune CVE n'était attribuée au 29 septembre, et aucune exploitation n'est connue.

Où le flux déraille

Avant de s'authentifier, le client demande au serveur MCP où trouver son serveur d'autorisation. Les versions touchées ne vérifiaient pas toujours cette réponse. Le serveur hostile peut désigner son propre service, ou — plus discret — annoncer le vrai service de connexion tout en envoyant l'échange du code ailleurs.

AttaquantVrai serviceServeur MCPhostileClient MCPAttaquantVrai serviceServeur MCPhostileClient MCPOù s'authentifier ?1Connexion chez V, jetonschez A2L'utilisateur approuve3Code d'autorisation4Secret, code, vérificateur PKCE5Échange du code6Jeton d'accès valide7
La variante interactive : la page approuvée est la vraie, c'est l'échange du code qui part chez l'attaquant

Le vérificateur PKCE existe précisément pour qu'un code intercepté ne serve à rien : le remettre avec le code annule cette protection. Et les deux fournisseurs machine à machine n'ont même pas l'étape 3.

Qui est concerné

Une application qui utilise le SDK comme client MCP en HTTP, avec OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider ou l'ancien RFC7523OAuthClientProvider (1.x, déprécié), et qui peut se connecter à un serveur qu'elle ne maîtrise pas.

Ne sont pas touchés : les serveurs MCP écrits avec le SDK, les clients locaux en stdio, les clients qui fournissent eux-mêmes leur jeton.

Branche Versions touchées Corrigé en
1.x 1.9.1 à 1.29.1 1.30.0
2.x 2.0.0 à 2.1.1 2.2.0

Comment s'y prendre

  1. Mettre à jour. Le correctif fait déterminer au client le service attendu avant toute récupération de métadonnées, et refuser tout autre.

    Terminal
    pip install --upgrade "mcp>=1.30.0,<2"   # rester sur 1.x
pip install --upgrade "mcp>=2.2.0"       # branche 2.x

  2. Avec ClientCredentialsOAuthProvider ou PrivateKeyJWTOAuthProvider, passer issuer= avec l'adresse du service auquel appartiennent les identifiants. Sans lui, l'avis est explicite : la mise à jour ne change rien. En 1.30.0, le rappel prend la forme d'un DeprecationWarning, que Python masque par défaut ; lancer les tests avec -W error::DeprecationWarning le fait apparaître.

  3. RFC7523OAuthClientProvider n'a pas d'option issuer= : migrer vers l'un des deux autres.

  4. Vider une fois les enregistrements de clients OAuth stockés : les anciens ne sont liés à aucun service et le resteront.

  5. Si un client a pu parler à un serveur douteux, changer son secret et révoquer ses jetons côté fournisseur.

Sur une version ancienne, aucun contournement : seulement ne se connecter qu'à des serveurs de confiance.

Le calendrier

Les vérifications sont arrivées le 7 septembre dans les notes de version de 1.30.0 et 2.2.0, rangées parmi les changements de comportement et non comme correctif de sécurité. L'avis a suivi le 28 septembre, le jour du billet de Cycode ; il crédite huit personnes.

Source : Official MCP Python SDK Flaw Can Let Malicious Servers Steal OAuth Credentials, The Hacker News, 29 septembre 2026. Voir aussi l'avis de sécurité et le billet de Cycode.