MCP Python SDK: Bösartige MCP-Server konnten OAuth-Zugangsdaten abgreifen

Das offizielle Python SDK des Model Context Protocol (MCP), auf PyPI als Paket mcp verteilt, hatte eine Lücke im OAuth-Client. Ein bösartiger oder kompromittierter MCP-Server konnte eine damit gebaute Client-Anwendung dazu bringen, ihr Client-Secret, den Autorisierungscode und den PKCE-Code-Verifier an einen Token-Endpunkt des Angreifers zu schicken. Betroffen sind Eigenentwicklungen, die das SDK als MCP-Client über HTTP mit einem der OAuth-Provider des SDK nutzen und dabei auch Server ansprechen, die nicht vollständig unter eigener Kontrolle stehen. Die Fixes stecken in den Versionen 1.30.0 und 2.2.0.

Nicht betroffen sind laut Advisory MCP-Server, die mit dem SDK gebaut wurden, lokale Clients über stdio sowie Clients, die ihre Tokens oder Header selbst setzen. Wer eigene Agenten oder Integrationen auf Python-Basis mit OAuth gegen externe MCP-Server betreibt, sollte heute die installierte Version prüfen und im Zweifel Client-Secrets rotieren. Für reine Server-Betreiber ist das Update ein normaler Punkt für das nächste Wartungsfenster.

Was ist passiert?

Die Maintainer des Repositorys modelcontextprotocol/python-sdk haben am 28. September 2026 das GitHub Security Advisory GHSA-qx49-fqc8-xw99 mit dem Titel „OAuth client could send credentials to an authorization server chosen by the MCP server“ veröffentlicht. Am selben Tag erschien der Bericht des Sicherheitsunternehmens Cycode, dessen Forscher Yuval Elbar zu den insgesamt acht im Advisory genannten Meldern gehört. The Hacker News berichtete am 29. September.

Der Kern des Problems liegt in der OAuth-Discovery. Bevor sich ein MCP-Client anmeldet, fragt er den MCP-Server, welcher Autorisierungsserver zuständig ist, und lädt anschließend dessen Metadaten. Laut Advisory fehlten dabei zwei Schutzmechanismen:

• Das Feld issuer in den Metadaten des Autorisierungsservers wurde nicht auf jedem Discovery-Pfad gegen den erwarteten Server geprüft.
• Gespeicherte oder vorab hinterlegte Client-Zugangsdaten waren nicht an den Autorisierungsserver gebunden, zu dem sie gehören.

Ein bösartiger Server konnte deshalb entweder einen eigenen Autorisierungsserver benennen oder gar keine Protected Resource Metadata ausliefern und stattdessen Metadaten präsentieren, die den echten Anmeldedienst des Nutzers als issuer ausgeben, den Token-Endpunkt aber auf den Angreifer umbiegen. Cycode beschreibt, dass die Anmeldeseite dabei die echte Seite des Identity Providers ist. Der Nutzer sieht also keinen Phishing-Hinweis, nur einen MCP-Server, der nach der Anmeldung scheinbar hängt. Mit Secret, Code und Verifier holt sich der Angreifer anschließend beim echten Anbieter ein gültiges Access Token. Laut The Hacker News hat Cycode diesen vollständigen Austausch in einem Test nachgestellt.

Bemerkenswert ist der Ablauf der Offenlegung: Die Issuer-Prüfung wurde bereits am 7. September 2026 mit den Releases 1.30.0 und 2.2.0 ausgeliefert, in den Release Notes aber nur als Verhaltensänderung aufgeführt. Als Sicherheitsproblem öffentlich benannt wurde sie erst mit dem Advisory vom 28. September.

Wer ist betroffen?

Laut Advisory ist eine Anwendung betroffen, wenn beide Bedingungen zutreffen:

• Sie nutzt das SDK als MCP-Client über HTTP und setzt als auth-Handler des Transports OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider oder den veralteten 1.x-Provider RFC7523OAuthClientProvider ein.
• Sie kann sich mit einem MCP-Server verbinden, dem der Betreiber nicht vollständig vertraut, während sie Zugangsdaten für einen legitimen Autorisierungsserver hält, etwa ein vorab hinterlegtes Secret, einen Signaturschlüssel oder eine gespeicherte Client-Registrierung.

Die betroffenen Versionsbereiche laut Advisory:

• 1.x-Linie: 1.9.1 bis 1.29.1, dort ohne Issuer-Prüfung und ohne Bindung der Zugangsdaten auf allen Pfaden. Behoben in 1.30.0.
• 2.x-Linie: 2.0.0 bis 2.1.1, dort nur dann, wenn der Server keine Protected Resource Metadata veröffentlicht (Legacy-Fallback) oder mit 403 insufficient_scope antwortet. Behoben in 2.2.0.
• Beide Linien: ClientCredentialsOAuthProvider und PrivateKeyJWTOAuthProvider hatten keine Möglichkeit, den zugehörigen Autorisierungsserver festzulegen.

Praktisch relevant ist das für selbst entwickelte Python-Agenten, interne Automatisierungen und Integrationen, die entfernte MCP-Server per OAuth ansprechen, besonders für Machine-to-Machine-Setups mit Client-Credentials oder signierten JWT-Assertions. Welche fertigen Produkte, Agenten-Frameworks oder IDE-Integrationen das Python SDK intern mit diesen Providern nutzen, nennen weder Advisory noch Cycode. Das muss jeder Betreiber für seine Abhängigkeiten selbst prüfen. Die Verbreitung des Pakets ist hoch: pypistats.org weist für mcp rund 219 Millionen Downloads im letzten Monat aus (Abruf 30.09.2026), wobei Downloads nicht mit betroffenen Installationen gleichzusetzen sind.

Wie kritisch ist das?

Das Advisory stuft die Lücke als hoch ein, CVSS 3.1 Basiswert 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). Dieser Wert gilt für die beiden unbeaufsichtigten Provider, die ohne menschliche Interaktion laufen. Für den interaktiven OAuthClientProvider, bei dem eine Person die Anmeldung anstoßen muss, nennen die Maintainer 6.5. Klassifiziert ist das Problem als CWE-345 (unzureichende Prüfung der Datenauthentizität) und CWE-522 (unzureichend geschützte Zugangsdaten). Eine CVE-Nummer war laut Advisory und The Hacker News zum Zeitpunkt der Veröffentlichung nicht vergeben.

Technisch handelt es sich um Diebstahl von Zugangsdaten, nicht um Codeausführung. Die Folgen können trotzdem erheblich sein: Das Client-Secret ist langlebig und bleibt gültig, bis es geändert wird, und das erbeutete Token trägt laut Cycode alle Berechtigungen, die der Anwendung gewährt wurden. Voraussetzung ist allerdings, dass der Client einen bösartigen oder kompromittierten MCP-Server anspricht. Weder Advisory noch Cycode berichten von Angriffen in freier Wildbahn. Die Bewertung lautet daher: nur relevant für Python-MCP-Clients mit SDK-OAuth gegen nicht voll vertrauenswürdige Server, dort aber zeitnah zu behandeln.

Was sollten Admins jetzt tun?

• Installierte Version prüfen: in jeder relevanten Python-Umgebung, jedem Container-Image und jeder CI-Umgebung pip show mcp oder python -m pip list | grep -i mcp ausführen. Versionen von 1.9.1 bis 1.29.1 und 2.0.0 bis 2.1.1 sind betroffen.
• Im Code nach den Providern suchen, etwa mit grep -rnE "OAuthClientProvider|ClientCredentialsOAuthProvider|PrivateKeyJWTOAuthProvider|RFC7523OAuthClientProvider" .. Ohne Treffer und ohne OAuth-Nutzung über HTTP ist die Anwendung laut Advisory nicht betroffen.
• Auf die gefixten Versionen aktualisieren: pip install -U "mcp>=2.2.0" für die 2.x-Linie oder pip install "mcp>=1.30.0,<2" für Projekte, die auf 1.x bleiben. Lockfiles und Requirements-Dateien entsprechend anpassen.
• Bei ClientCredentialsOAuthProvider und PrivateKeyJWTOAuthProvider zusätzlich den Parameter issuer= setzen, zum Beispiel issuer="https://auth.example.com". Laut Advisory ändert das Update ohne diesen Parameter nichts. Unter 1.30.0 erscheint nur eine DeprecationWarning, die Python standardmäßig ausblendet.
• Den veralteten RFC7523OAuthClientProvider ersetzen, er kennt keine issuer-Option.
• Gespeicherte OAuth-Client-Registrierungen nach dem Update einmal löschen, damit sich der Client neu registriert und an den Issuer gebunden wird. Selbst hinterlegte Registrierungen stattdessen mit dem Feld issuer versehen.
• Falls ein betroffener Client bereits mit einem nicht vertrauenswürdigen MCP-Server verbunden war: Client-Secret beim Autorisierungsserver rotieren und ausgestellte Tokens widerrufen.
• Protokolle des Identity Providers auf Token-Ausstellungen für die betroffenen Client-IDs von unbekannten IP-Adressen prüfen.
• OAuth-fähige Clients bis zum Update ausschließlich mit vertrauenswürdigen MCP-Servern verbinden, laut Advisory gibt es für ältere Versionen keinen anderen Workaround.
• Scopes der OAuth-Clients auf das Nötigste begrenzen, damit ein erbeutetes Token möglichst wenig Schaden anrichten kann.

Einordnung für Unternehmen

Für die meisten kleinen und mittleren Unternehmen ist die Lücke kein Grund zur Eskalation. Wer MCP nur über fertige Desktop-Anwendungen oder lokal per stdio nutzt, ist nach Lage des Advisorys nicht über diesen Weg betroffen, sofern das jeweilige Werkzeug nicht selbst das Python SDK mit dessen OAuth-Providern einsetzt. Anders sieht es bei Teams aus, die eigene KI-Agenten in Python bauen und diese mit externen MCP-Servern verbinden. Dort wird der MCP-Server zur Vertrauensinstanz, und genau diese Annahme hat das SDK zu großzügig umgesetzt.

Die Lücke zeigt ein grundsätzliches Muster beim Einsatz von KI-Agenten: Jeder angebundene Server ist potenziell eine Angriffsfläche für die Zugangsdaten des Clients. Unternehmen sollten eine Freigabeliste für erlaubte MCP-Server führen, Service-Zugangsdaten je Integration trennen und für Agenten eigene OAuth-Clients mit minimalen Scopes anlegen. Hilfreich ist zudem, SDK-Updates nicht nur nach dem Label „Security“ zu bewerten: Der Fix war drei Wochen vor dem Advisory verfügbar, aber nur als Verhaltensänderung dokumentiert.

Passende Anleitungen auf S-EDV

• KI-Agenten im Unternehmen: Aufgaben und Rechte vor dem Einsatz begrenzen: Grundsätze für minimale Berechtigungen.
• Zitadel als Identity Server mit Docker: eigener OAuth- und OIDC-Anbieter mit getrennten Clients und Scopes.
• Infisical mit Docker für Secrets-Management: Client-Secrets zentral verwalten und rotieren.

Quellen

• GitHub Security Advisory GHSA-qx49-fqc8-xw99 im Repository modelcontextprotocol/python-sdk (28.09.2026)
• Release-Notes mcp 2.2.0 (07.09.2026)
• Release-Notes mcp 1.30.0 (07.09.2026)
• Cycode: Bericht zur Kontoübernahme über das MCP Python SDK (28.09.2026)
• The Hacker News: Bericht zur Lücke im offiziellen MCP Python SDK (29.09.2026)
• pypistats.org: Downloadstatistik des Pakets mcp