MCP Python SDK OAuth-Lücke: Der Server bestimmt, wohin deine Keys gehen

Die MCP Python SDK OAuth-Lücke ist der bisher unangenehmste Fund im Fundament der Agenten-Welle: Das offizielle Python-SDK für das Model Context Protocol ließ zu, dass ein MCP-Server selbst bestimmt, wohin der Client seine OAuth-Zugangsdaten schickt. Das Advisory GHSA-qx49-fqc8-xw99 wurde am 28. September 2026 veröffentlicht und mit CVSS 7.5 (High) bewertet – gerechnet für die unbeaufsichtigten Provider; mit dem interaktiven Provider sind es 6.5.

Was die MCP Python SDK OAuth-Lücke technisch bedeutet

MCP-Clients fragen den Server, mit dem sie sprechen, wo dessen Anmeldedienst – der Authorization Server – liegt. In den betroffenen Versionen prüfte das SDK diese Antwort nicht auf jedem Weg: Der issuer aus den Metadaten wurde nicht durchgängig validiert, und gespeicherte oder vorab hinterlegte Client-Zugangsdaten waren nicht an den Server gebunden, zu dem sie gehören.

Ein bösartiger oder übernommener MCP-Server konnte deshalb auf sein eigenes Token-Endpoint umlenken – entweder indem er in seinen Protected-Resource-Metadaten den eigenen Authorization Server nennt, oder indem er gar keine veröffentlicht und stattdessen Metadaten ausliefert, die den echten Anmeldedienst als issuer ausgeben. Beim Angreifer landen könnten dann client_secret, Authorization Code und der PKCE-code_verifier; bei PrivateKeyJWTOAuthProvider stattdessen eine signierte Client-Assertion. Angriffe in freier Wildbahn sind bislang weder im Advisory noch bei den Findern beschrieben.

Betroffen sind laut Advisory die Versionen 1.9.1 bis 1.29.1 sowie 2.0.0 bis 2.1.1 (das Versions-Feld des Advisorys zählt bereits ab dem Prerelease 2.0.0a1). Wichtig für die Bewertung: In der 1.x-Linie fehlten die Prüfungen auf jedem Pfad, in 2.0.0 bis 2.1.1 nur beim Legacy-Fallback – also wenn der Server gar keine Protected-Resource-Metadaten veröffentlicht – und bei der Antwort 403 insufficient_scope. Gefixt ist es in 1.30.0 und 2.2.0. Nicht betroffen: Server, die mit dem SDK gebaut sind, reine stdio-Clients und Clients, die ihre Tokens oder Header selbst setzen. Zum Stand 30. September 2026 ist keine CVE-Nummer zugewiesen; das Advisory führt „No known CVE“.

Newsletter

Klartext zu KI, Security, Crypto

Einordnung statt Hype: was hinter den Tech-News steckt und was davon für dich zählt. Startbonus: die AD-Checkliste mit 12 Sofortmaßnahmen als PDF.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Der Fallstrick beim Update

Hier liegt die eigentliche Falle, und sie ist leicht zu übersehen: Wer ClientCredentialsOAuthProvider oder PrivateKeyJWTOAuthProvider einsetzt, hat mit dem reinen Versions-Upgrade nichts gewonnen. Erst wenn zusätzlich issuer= gesetzt wird, weiß der Client, zu welchem Anmeldedienst seine Zugangsdaten gehören. Fehlt der Parameter, folgt er weiter dem, was der MCP-Server behauptet. Auf 1.30.0 ist der Hinweis darauf lediglich eine DeprecationWarning – und die blendet Python standardmäßig aus. Pflicht wird issuer= erst ab Version 3.0. Ein Upgrade, das sich sauber anfühlt und trotzdem nichts ändert, ist die gefährlichste Sorte Upgrade.

Was das für dich bedeutet

Aus Identity-Sicht ist das kein exotischer Agenten-Bug, sondern ein sehr alter Fehler in neuer Verpackung: Eine Komponente lässt sich von der Gegenstelle sagen, wem sie ihre Geheimnisse anvertrauen darf. Wer aus der Active-Directory-Welt kommt, kennt das Muster als Server-Impersonation – nur dass dort seit Jahrzehnten mit Mutual Authentication und gepinnten Endpunkten dagegengehalten wird. Im Agenten-Ökosystem wurde diese Härtung schlicht noch nicht mitgebaut.

Das Risiko hängt davon ab, wie deine Agenten aufgesetzt sind. Ein Client, der ausschließlich mit selbst betriebenen MCP-Servern über stdio spricht, ist nicht betroffen. Kritisch wird es dort, wo ein Agent mit einem produktiven client_secret oder Signaturschlüssel in der Tasche auch fremde MCP-Server anspricht – also in genau dem Setup, das aktuell überall entsteht: ein Agent, viele Werkzeuge, ein Teil davon aus fremder Hand. Dass MCP-Server zu Schlüsselverwahrern geworden sind, war schon im August ein Thema; die aktuelle Lücke zeigt, dass auch die Client-Seite mitgedacht werden muss.

Und noch etwas fällt auf: Die Zugangsdaten gehören meist nicht dem Agenten, sondern einer echten Identität dahinter – einem Dienstkonto, einer App-Registrierung, oft mit weit mehr Rechten als der eine Task bräuchte. Wer hier ein Secret verliert, verliert nicht „einen Agenten“, sondern einen Zugang.

Was du jetzt konkret tun solltest

• Version prüfen: pip show mcp bzw. ein Blick in die Lockfile. Alles zwischen 1.9.1 und 1.29.1 sowie 2.0.0 bis 2.1.1 ist betroffen.
• Die stille Warnung laut stellen: Setz in der CI PYTHONWARNINGS=error::DeprecationWarning (oder starte mit python -W error::DeprecationWarning). Dann bricht der Build, wenn issuer= fehlt, statt dass die Warnung unbemerkt verschluckt wird. Diesen Schritt nennt keine der Quellen – er ist aber der einzige, der den Fallstrick oben zuverlässig sichtbar macht.
• Auf 1.30.0 bzw. 2.2.0 heben – und bei den beiden unbeaufsichtigten Providern zwingend issuer= mitgeben. Ohne diesen Schritt ist das Update wirkungslos.
• Gespeicherte Client-Registrierungen einmal löschen, damit sich der Client neu registriert. Alles, was 1.x vor 1.30.0 abgelegt hat, ist nicht an einen Issuer gebunden.
• Bei möglichem Kontakt zu fremden Servern: rotieren. Client Secret neu setzen und Tokens am Authorization Server widerrufen. Das ist die Empfehlung des Advisorys, nicht meine Vorsicht.
• Vom RFC7523OAuthClientProvider (1.x, deprecated) weg – er kennt keine issuer-Option.
• Grundsätzlich: Agenten, die OAuth-Zugangsdaten halten, nur mit MCP-Servern sprechen lassen, denen du wirklich vertraust – und je Zweck ein eigenes Konto mit minimalen Rechten statt eines Sammel-Secrets.

Wer sich tiefer damit beschäftigen will, welche Sicherheitsfragen KI-Systeme im Betrieb aufwerfen, findet in unserer Übersicht der besten Fachbücher zu KI und Cybersecurity 2026 passende Einstiege.

Quellen

• GitHub Security Advisory GHSA-qx49-fqc8-xw99 (modelcontextprotocol/python-sdk)
• The Hacker News: Official MCP Python SDK Flaw Can Let Malicious Servers Steal OAuth Credentials
• Cycode: MCP SDK OAuth Flaw Enabled Account Takeover (Analyse der Finder – keine unabhängige Zweitquelle)