Faille du MCP Python SDK : un serveur malveillant peut détourner vos identifiants OAuth ; passez à la 1.30.0 ou à la 2.2.0, puis ajoutez issuer=

Notre verdict : si vous construisez des clients MCP en Python avec le MCP Python SDK officiel (absent de notre répertoire) et vous connectez en HTTP à des serveurs que vous ne contrôlez pas, appliquez le correctif aujourd'hui. Pour deux des quatre fournisseurs concernés, la mise à jour seule ne change rien : vous devez aussi passer issuer=. Les mainteneurs classent la faille en gravité élevée, CVSS 7,5. Aucune attaque n'a été signalée.

Ce qui s'est passé

Le 28 septembre 2026, les mainteneurs du SDK ont publié l'avis GHSA-qx49-fqc8-xw99, intitulé « Le client OAuth pouvait envoyer ses identifiants à un serveur d'autorisation choisi par le serveur MCP ». Selon l'avis, le champ issuer des métadonnées du serveur d'autorisation n'était pas validé sur tous les chemins de découverte, et les identifiants client stockés ou préprovisionnés n'étaient pas liés au serveur d'autorisation auquel ils appartiennent. Un serveur MCP malveillant pouvait donc orienter les identifiants d'un client vers un point de terminaison qu'il contrôlait. The Hacker News énumère ce qui est exposé : le secret client, le code d'autorisation et la clé de preuve PKCE.

• Gravité : CVSS 3.1 de 7,5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) pour les fournisseurs machine à machine, 6,5 pour le fournisseur interactif, qui nécessite l'approbation de l'utilisateur. Aucun CVE n'est attribué.
• Fournisseurs concernés : OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider et le RFC7523OAuthClientProvider déprécié de la branche 1.x.
• Versions concernées : mcp 1.9.1 à 1.29.1, et 2.0.0 à 2.1.1.
• Corrigé dans : mcp 1.30.0 et 2.2.0.
• Non concernés : les serveurs MCP construits avec le SDK, les clients stdio, et les clients qui joignent leurs propres jetons ou en-têtes.
• Exploitation : ni l'avis ni Cycode ne font état d'attaques, selon The Hacker News.

Pourquoi c'est important

Le correctif est sorti le 7 septembre 2026, trois semaines avant l'avis, selon The Hacker News. Une mise à jour de routine l'a peut-être déjà apporté, ce qui donne un faux sentiment de sécurité : il ne vous protégeait que sur le fournisseur interactif.

ClientCredentialsOAuthProvider et PrivateKeyJWTOAuthProvider sont les fournisseurs machine à machine, et ils détiennent des secrets clients et des clés privées de longue durée. Sur ces deux-là, le code corrigé ne lie les identifiants que si vous passez un argument issuer= qui nomme le serveur d'autorisation auquel ils appartiennent. Sans lui, vous obtenez un avertissement de dépréciation et aucune protection. Des clients sans surveillance qui détiennent des secrets de longue durée, protégés seulement par un avertissement que personne ne lit : voilà pourquoi cela justifie un correctif hors calendrier.

Ce qui change pour vous

1. Mettez à jour mcp vers la 1.30.0 (1.x) ou la 2.2.0 (2.x).
2. Sur ClientCredentialsOAuthProvider et PrivateKeyJWTOAuthProvider, passez issuer= explicitement, par exemple issuer="https://auth.example.com". Il deviendra obligatoire dans la 3.0.
3. Si vous utilisez RFC7523OAuthClientProvider, abandonnez-le : il n'a pas d'option issuer=.
4. Purgez une fois les enregistrements OAuth stockés, pour que les clients se réenregistrent avec liaison à l'issuer.
5. Si un client a pu atteindre un serveur MCP non fiable, renouvelez ses secrets client auprès du serveur d'autorisation et révoquez ses jetons.

Aucun outil de notre répertoire n'est le SDK lui-même. Si vous exécutez un agent ou une passerelle Python qui parle MCP en HTTP, vérifiez quelle version du SDK il épingle.

FAQ

Suis-je concerné si je ne construis que des serveurs MCP ? Non. L'avis liste les serveurs MCP construits avec le SDK comme non concernés, tout comme les clients stdio.

J'ai déjà fait la mise à jour en septembre. Suis-je protégé ? Seulement sur le OAuthClientProvider interactif. Sur les deux fournisseurs machine à machine, vous restez exposé tant que vous ne passez pas issuer=.

Y a-t-il un CVE à suivre ? Non. Suivez-le sous GHSA-qx49-fqc8-xw99.