Offizielles MCP Python SDK: Bösartiger Server konnte OAuth-Zugangsdaten des Clients abfangen

Im offiziellen Python SDK für das Model Context Protocol (MCP) – einen offenen Standard zur Anbindung von AI-Anwendungen an externe Tools und Daten – wurde eine Schwachstelle mit hoher Kritikalität entdeckt. Ein bösartiger MCP-Server konnte die OAuth-Zugangsdaten einer Client-Anwendung (Client-Secret, Autorisierungscode und PKCE-Verifier) auf einen vom Angreifer kontrollierten Endpunkt umleiten und sich anschließend vom legitimen Autorisierungsserver ein gültiges Zugriffstoken ausstellen lassen. Die Korrekturen wurden in den Versionen 1.30.0 und 2.2.0 veröffentlicht, doch für zwei der betroffenen Provider reicht ein Update allein nicht aus – es ist eine zusätzliche Konfiguration des Parameters issuer= erforderlich.

Wesenskern der Schwachstelle und Angriffsmechanismus

Laut dem offiziellen Sicherheitshinweis (GHSA-qx49-fqc8-xw99) liegt das Problem in einer unzureichenden Überprüfung der Datenauthentizität (CWE-345) und einem unzureichenden Schutz von Zugangsdaten (CWE-522). Wenn ein MCP-Client eine OAuth-Authentifizierung initiiert, fragt er beim MCP-Server Informationen über den Autorisierungsserver an. In den verwundbaren Versionen überprüfte das SDK die erhaltene Antwort nicht, was es einem bösartigen Server ermöglichte:

• in den Metadaten der geschützten Ressource einen eigenen Autorisierungsserver anzugeben;
• die Metadaten der geschützten Ressource gar nicht zu veröffentlichen und stattdessen Metadaten bereitzustellen, in denen als Issuer zwar der legitime Autorisierungsserver angegeben ist, die Tokens aber tatsächlich an den Endpunkt des Angreifers gesendet werden.

In der Folge übermittelte der Client dem Angreifer das client_secret, den Autorisierungscode und den PKCE-Verifier code_verifier – einen Einmalwert, der eigentlich vor der Wiederverwendung eines abgefangenen Autorisierungscodes schützen soll. Die Weitergabe des Verifiers hebelt diesen Schutz vollständig aus. Das Client-Secret ist langlebig und bleibt gültig, bis es zwangsweise rotiert wird.

Beim interaktiven Provider OAuthClientProvider muss der Nutzer den Login zwar weiterhin bestätigen, doch wie das Unternehmen Cycode, das die Schwachstelle entdeckt hat, anmerkt, handelt es sich dabei um die echte Login-Seite des legitimen Dienstes – optisch ist nichts Verdächtiges erkennbar. Die beiden Provider für Machine-to-Machine-Kommunikation (ClientCredentialsOAuthProvider und PrivateKeyJWTOAuthProvider) erfordern überhaupt keine Benutzerinteraktion.

Betroffene Versionen und Konfigurationen

Das verwundbare Paket ist mcp (pip). Betroffene Versionen:

• 1.9.1 – 1.29.1: keine Issuer-Überprüfung und keine Bindung der Zugangsdaten auf sämtlichen Pfaden;
• 2.0.0 – 2.1.1: fehlende Prüfungen bei Verwendung des veralteten Fallback-Pfads (wenn der Server keine Metadaten der geschützten Ressource veröffentlicht) oder bei einer Antwort 403 insufficient_scope;
• Alle Alpha-Versionen von 2.0.0a1 bis zu Versionen unterhalb von 2.2.0.

Eine Anwendung ist verwundbar, wenn gleichzeitig zwei Bedingungen erfüllt sind: Sie verwendet das SDK als MCP-Client über HTTP mit einem der OAuth-Handler (OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider oder dem veralteten RFC7523OAuthClientProvider) und kann sich mit einem MCP-Server verbinden, der nicht vollständig unter der Kontrolle des Betreibers steht, während Zugangsdaten für einen legitimen Autorisierungsserver vorliegen.

Nicht betroffen sind: auf dem SDK basierende MCP-Server; Clients, die sich lokal (stdio) verbinden; Clients, die Tokens oder Header selbst anhängen.

Einstufung der Schwere

Der Sicherheitshinweis bewertet die Schwachstelle mit einem Score von CVSS 7.5 (High) für Provider, die ohne Benutzerinteraktion arbeiten. Für den interaktiven OAuthClientProvider, bei dem eine Bestätigung durch den Nutzer erforderlich ist, beträgt die Bewertung 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N). Zum Zeitpunkt der Veröffentlichung des Hinweises war noch keine CVE-Kennung vergeben.

Weder der Sicherheitshinweis noch der Bericht von Cycode enthalten Hinweise auf eine aktive Ausnutzung der Schwachstelle.

Auswirkungsanalyse

Die Schwachstelle stellt das größte Risiko für Organisationen dar, die auf MCP basierende AI-Anwendungen betreiben, die sich über HTTP mit externen MCP-Servern verbinden und OAuth für die Authentifizierung nutzen. Besonders kritisch ist das Szenario mit Machine-to-Machine-Providern: Der Angriff ist vollständig automatisiert und erfordert keine Social Engineering-Maßnahmen. Das vom Angreifer erlangte Zugriffstoken übernimmt sämtliche Berechtigungen, die der Anwendung eingeräumt wurden, was zu einer vollständigen Kompromittierung des Accounts beim legitimen Dienst führen kann.

Empfehlungen zur Behebung

Ein Paket-Update ist ein notwendiger, aber nicht in allen Fällen ausreichender Schritt. Das vollständige Vorgehen:

1. Aktualisieren Sie das Paket auf Version 1.30.0 (Branch 1.x) oder Version 2.2.0 (Branch 2.x). In den korrigierten Versionen legt der Client den erwarteten Autorisierungsserver fest, bevor er irgendwelche Metadaten erhält, und weist nicht übereinstimmende zurück.
2. Für ClientCredentialsOAuthProvider und PrivateKeyJWTOAuthProvider – übergeben Sie unbedingt den Parameter issuer= mit der Adresse des legitimen Autorisierungsservers (z. B. issuer="https://auth.example.com"). Ohne diesen Parameter folgen die aktualisierten Provider weiterhin dem Autorisierungsserver, den der MCP-Server angibt. In Version 1.30.0 wird das Fehlen von issuer= als Standard-Deprecation-Warnung ausgegeben, die Python standardmäßig unterdrückt – sie lässt sich daher leicht übersehen.
3. Der veraltete RFC7523OAuthClientProvider unterstützt den Parameter issuer= nicht. Ein Umstieg auf einen der beiden anderen Provider ist erforderlich.
4. Bereinigen Sie gespeicherte OAuth-Registrierungen einmalig nach dem Update. Vor der Korrektur angelegte Registrierungen sind nicht an einen bestimmten Autorisierungsserver gebunden und bleiben in diesem Zustand.
5. Falls sich der Client mit einem nicht vertrauenswürdigen MCP-Server verbinden konnte – führen Sie eine Rotation des Client-Secrets durch und widerrufen Sie dessen Tokens auf Seiten des Autorisierungsservers.

Für Versionen unterhalb der korrigierten Varianten besteht die einzige Maßnahme darin, OAuth-Clients ausschließlich mit vertrauenswürdigen MCP-Servern zu verbinden.

Chronologie der Offenlegung

Die Korrekturen mit Issuer-Überprüfung wurden in die Releases 1.30.0 und 2.2.0 vom 7. September 2026 aufgenommen und in den Release Notes als Verhaltensänderung, nicht als Sicherheitsfix, beschrieben. Der Sicherheitshinweis wurde am 28. September veröffentlicht – am selben Tag, an dem Cycode seine Analyse veröffentlichte. Im Hinweis sind acht Personen aufgeführt, die das Problem gemeldet haben, darunter der Forscher von Cycode.

Organisationen, die das MCP Python SDK für HTTP-Clients mit OAuth-Authentifizierung verwenden, sollten das Paket umgehend auf Version 1.30.0 oder 2.2.0 aktualisieren, sicherstellen, dass für Machine-to-Machine-Provider der Parameter issuer= gesetzt ist, alte Registrierungen bereinigen und bei Verdacht auf eine Kompromittierung eine Rotation der Secrets durchführen. Das dreiwöchige Intervall zwischen der Veröffentlichung des Patches und dem Sicherheitshinweis bedeutet, dass ein Teil der Nutzer zwar aktualisiert haben könnte, ohne sich der Kritikalität der Änderung bewusst zu sein.