MCP Python SDK : un serveur malveillant suffisait pour récupérer votre client secret
> En bref : Un serveur MCP malveillant pouvait tromper le client du SDK Python officiel pour qu'il envoie son client secret, son code d'autorisation et sa clé PKCE à un endpoint de token contrôlé par l'attaquant. La faille était corrigée depuis le 7 septembre dans les versions 1.30.0 et 2.2.0 — mais l'advisory date du 28 septembre : beaucoup de déploiements tournent encore sur des versions affectées.
Le mécanisme : le serveur répond à la question du client
Le flux OAuth du SDK fonctionne ainsi : le client demande au serveur MCP où se trouve le serveur d'autorisation. Le serveur répond. Et c'est là que se joue tout.
Dans les versions affectées, le SDK validait insuffisamment cette réponse. Un serveur malveillant pouvait donc renvoyer un endpoint de token contrôlé par l'attaquant — et le client y transmettait client secret, code d'autorisation et clé PKCE.
Cycode a rapporté la faille et démontré un échange de credentials complet : les identités volées s'échangent contre un access token valide portant les permissions de l'application. Et le client secret est un secret longue durée : l'échanger une fois, c'est l'avoir pour longtemps.
Qui est affecté
Les providers affectés : OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, et le provider obsolète RFC7523OAuthClientProvider en 1.x. CVSS 7.5 pour les deux providers non interactifs, 6.5 pour le provider interactif. Pas de CVE attribué à ce jour, pas d'attaque active connue.
Ce que l'upgrade ne fait pas
C'est le point que la plupart des équipes vont rater :
En 1.30.0, l'avertissement est un simple deprecation warning Python, masqué par défaut. Il ne clignote nulle part.
Ce qu'il faut vérifier maintenant
La leçon
Dans le flux OAuth, le serveur MCP est la partie la moins fiable de la chaîne — et pourtant, c'est lui qui décide où le client envoie ses secrets. Un client qui fait confiance à la réponse de découverte de n'importe quel serveur, c'est la même erreur qu'un navigateur qui suit une redirection sans vérifier. La règle simple : une identité ne doit jamais dépendre de la réponse d'un tiers non contrôlé.
Vous éditez un logiciel ? CleanIssue réalise des audits de sécurité pour votre produit en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
OAuth 2.0 PKCE : quand la protection est désactivée sans le savoir
Le flux PKCE protège contre l'interception de code d'autorisation. Mais quand il est mal implémenté, il donne un faux sentiment de sécurité.
Faille MCP Azure DevOps : un commentaire de PR caché qui détourne les agents IA de revue de code
Une faille dans le serveur MCP Azure DevOps de Microsoft permettait à un commentaire de pull request caché de manipuler les agents IA de revue de code qui le consomment, leur ordonnant d'approuver des changements malveillants ou de leak du contenu de dépôt. Illustre le risque d'injection de prompt sur la couche MCP d'appel d'outils qui connecte les agents IA à l'infra de dev.
Sécurité MCP : que vérifier quand votre IA parle à votre base de données
Le Model Context Protocol (MCP) connecte les LLM à vos outils internes. Points d'audit critiques pour sécuriser ces connexions.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits ActionShield les plus pertinents.
Red Team Agent Express
Voir vite ce qu'un inconnu peut faire faire à votre agent — rapport en 5 jours.
Diagnostic Agent
L'état des lieux complet : chaque action de votre agent, testée et hiérarchisée.
Le Shield — le logiciel
La couche qui bloque l’action avant l’outil. En développement — premiers clients en avant-première.