Menu

MCP Python SDK : le SDK officiel rejoue un vieux piège OAuth, le mix-up attack

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
2 min de lecture
⏱️
Temps de lecture estimé
~7 minutes

Le SDK Python officiel du Model Context Protocol validait mal l’identité de son serveur d’authentification. Un serveur MCP malveillant pouvait se faire passer pour le vrai fournisseur OAuth et repartir avec le client secret, l’authorization code et la preuve PKCE. CVSS 7.5, corrigé début septembre, requalifié faille de sécurité le 28.

Un bug corrigé, puis requalifié trois semaines après

Le 7 septembre, le SDK Python officiel du MCP sort en version 1.30.0 et 2.2.0. Les notes de version évoquent un “changement de comportement” sur la validation OAuth. Rien de plus. Il faut attendre le 28 pour que Cycode publie son advisory et lève le voile : ce changement de comportement colmatait une faille qui laissait un serveur MCP malveillant voler les secrets OAuth d’un client. Trois semaines entre le patch et l’annonce publique, et toujours pas de CVE au moment où j’écris ces lignes.

Le mécanisme n’a rien d’exotique pour qui suit la recherche OAuth depuis dix ans : c’est un mix-up attack, une classe d’attaque documentée depuis le papier de Fett, Küsters et Schmitz en 2016. Le SDK ne validait pas correctement quel serveur d’authentification répondait réellement à sa requête. Un serveur MCP compromis ou malveillant pouvait pointer le client vers son propre endpoint OAuth au lieu du vrai, et le client, sans moyen fiable de vérifier qui parlait, suivait.

Note du PandaRedacteur : ça fait dix ans que la littérature académique documente le mix-up attack sur OAuth. Il a fallu attendre qu’un protocole tout neuf le réimplémente pour qu’on en reparle. Le train de l’IA va vite ; la mémoire collective de la sécu, moins.

Ce que le client perd

La suite de cette analyse est publiée sur Substack :

  • Ce que le client perd (le butin en trois pièces, les deux scores CVSS)
  • On validait le contenu, pas l’émetteur (le correctif issuer=, le diagramme de séquence de l’attaque)
  • Analyse STRIDE
  • Impact potentiel
  • Mitigations (les 5 recommandations concrètes)
📬 Analyse complète sur Substack
Le reste de cet article est publié sur la newsletter, en accès libre pour tous les abonnés Substack.

Quelques références pour aller plus loin

À retenir 📌

  • ✓ Le SDK Python officiel du MCP validait mal l'identité de son serveur d'authentification, ouvrant la voie à un mix-up attack classique de la littérature OAuth.
  • ✓ Trois secrets exposés : client secret, authorization code et preuve PKCE, suffisants pour obtenir un jeton d'accès valide.
  • ✓ CVSS 7.5 (non-interactif) / 6.5 (interactif), corrigé en 1.30.0 et 2.2.0, sans CVE assigné au moment de l'annonce.
  • ✓ Le correctif tient dans un paramètre, issuer=, qui nomme enfin explicitement le fournisseur d'authentification attendu.
  • ✓ Aucune exploitation active documentée à ce jour, mais un SDK de référence touché signifie une propagation potentiellement large.

MCP Python SDK OAuth mixup - Générée par IA

LinkedIn Reddit Substack