Fehler bei der OAuth-Issuer-Prüfung im MCP Python SDK

GHSA-qx49-fqc8-xw99 ermöglichte es einem HTTP-MCP-Server, das Ziel zu beeinflussen, an das betroffene OAuth-Clients des Python-SDK Zugangsdaten senden konnten. Aktualisieren Sie auf mcp 1.30.0 oder 2.2.0; Machine-to-Machine-Anbieter müssen issuer= setzen. Es wurde keine CVE vergeben.^{[1], [3], [8]}

CVSS-Vektor

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N^[1]

💡 Einfache Erklärung (ELI5)

Ein Unternehmen schickt einen versiegelten Schlüssel an die Bank, deren Adresse auf einer freigegebenen Verzeichniskarte steht. Der MCP-Server durfte die Karte liefern, und ein Ausweichpfad prüfte nicht, ob der Eintrag tatsächlich zur erwarteten Bank gehörte. Die Issuer-Prüfung vergleicht die Identität der Karte mit der als vertrauenswürdig konfigurierten Bank, bevor der Schlüssel versendet wird.^{[1], [2]}

Kernkonzepte & Begriffe

MCP-Client: Eine Anwendung, die mit dem Model Context Protocol auf Werkzeuge oder Daten eines MCP-Servers zugreift. Betroffen ist das Python-SDK als HTTP-Client mit seinen OAuth-Anbietern.^[1]
Issuer des Authorization Servers: Stabile Kennung des OAuth-Dienstes, der Tokens ausstellt. Der Client muss entdeckte Metadaten mit einem unabhängig erwarteten Issuer vergleichen.^{[1], [2]}
Protected Resource Metadata (PRM): Metadaten, die Authorization Server einer geschützten Ressource nennen können. Fehlt PRM, besitzt das SDK zusätzlich einen älteren Discovery-Pfad.^{[1], [2]}
PKCE-Code-Verifier: Ein vom Client erzeugtes Geheimnis, das den OAuth-Codeaustausch an den Client bindet, der den Ablauf gestartet hat. Es darf keinem nicht vertrauenswürdigen Endpunkt offengelegt werden.^{[1], [2]}
CWE-345 / CWE-522: Unzureichende Prüfung der Datenauthentizität: Daten werden angenommen, ohne ihre Herkunft aus der erwarteten Quelle ausreichend zu bestätigen. CWE-522 beschreibt unzureichend geschützte Zugangsdaten.^{[1], [4], [7]}

Framework-Zuordnungen

CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-345 CWE-522

Schritt-für-Schritt Angriffsablauf

Schritt 1

Ein HTTP-MCP-Client hält OAuth-Zugangsdaten

Die Anwendung verwendet eine betroffene mcp-Version und einen OAuth-Anbieter des SDK. Sie kann sich mit einem nicht vollständig vertrauenswürdigen MCP-Server verbinden, während sie ein Client-Geheimnis, einen Signaturschlüssel oder eine gespeicherte Clientregistrierung besitzt.^[1]

Schritt 2

Der Server beeinflusst die Autorisierungs-Discovery

mcp 1.9.1–1.29.1 prüfte den Issuer nicht und band Zugangsdaten nicht auf allen Discovery-Pfaden. mcp 2.0.0–2.1.1 war betroffen, wenn PRM fehlte und der Legacy-Fallback lief, oder bei der Discovery nach 403 insufficient_scope. In beiden Linien fehlte Machine-to-Machine-Anbietern issuer= zur Bindung vorab bereitgestellter Zugangsdaten. Der Paketbereich im Advisory beginnt mit der Vorabversion 2.0.0a1 und reicht bis <2.2.0; betroffene 2.0.0-Vorabversionen sind daher ebenfalls eingeschlossen.^{[1], [3], [8]}

Schritt 3

Der Token-Endpunkt erhält Zugangsdaten

Der Client kann ein Client-Geheimnis, Autorisierungscode und PKCE-Verifier oder eine signierte Assertion an einen anhand dieser Metadaten gewählten Endpunkt senden. Welche Zugangsdaten betroffen sind, hängt vom Anbieter ab; nicht jeder Client ist betroffen.^{[1], [2]}

Schritt 4

Die Auswirkung hängt von Anbieter und Berechtigungen ab

Der Empfänger kann offengelegte Zugangsdaten oder Tokens innerhalb des gewährten Umfangs verwenden. Der Hinweis bewertet unbeaufsichtigte Anbieter mit CVSS 7,5; der interaktive Anbieter erhält 6,5, weil eine Person die Anmeldung starten muss. Laut Hinweis wurde keine CVE vergeben.^[1]

Schritt 5

Issuer-Pinning schließt die Vertrauenslücke

Korrigierte Versionen bestimmen den erwarteten Issuer vor der Discovery, weisen abweichende Metadaten zurück und binden gespeicherte Registrierungen an diesen Issuer. Maschine-zu-Maschine-Anbieter benötigen zusätzlich ein explizites issuer=.^{[1], [2], [3], [8]}

MCP Python SDK OAuth: Versions- und Maßnahmenmatrix

Client-Konfiguration	Dokumentierte Betroffenheitsbedingung	Erforderliche Maßnahme
HTTP-OAuth-Client mit `mcp` 1.9.1–1.29.1	Auf allen Discovery-Pfaden fehlten Issuer-Prüfung und eine konsistente Bindung der Zugangsdaten an den Issuer.	Auf `mcp` 1.30.0 oder neuer aktualisieren und die tatsächlich ausgerollte Version prüfen.
HTTP-OAuth-Client mit `mcp` 2.0.0–2.1.1	Betroffen, wenn PRM fehlt und der Legacy-Fallback greift, oder bei der Step-up-Discovery nach `403 insufficient_scope`. Der Paketbereich im Advisory beginnt mit der Vorabversion `2.0.0a1` und reicht bis `<2.2.0`; betroffene 2.0.0-Vorabversionen sind daher ebenfalls eingeschlossen.	Auf `mcp` 2.2.0 oder neuer aktualisieren und die tatsächlich ausgerollte Version prüfen.
`ClientCredentialsOAuthProvider` oder `PrivateKeyJWTOAuthProvider` mit vorab bereitgestellten Zugangsdaten	In den betroffenen Versionen fehlte `issuer=`, um diese Zugangsdaten an den erwarteten Authorization Server zu binden.	Nach dem Update `issuer=` ausdrücklich setzen. Den veralteten `RFC7523OAuthClientProvider` der 1.x-Linie migrieren.
Mit dem SDK erstellter Server, stdio-Client oder Client mit eigenem Token/Header	Von diesem Advisory nicht betroffen.	Für diesen konkreten Fehler keine Maßnahme erforderlich; erneut prüfen, wenn die Anwendung zusätzlich einen betroffenen HTTP-OAuth-Client nutzt.

Ursachenanalyse

Der Vertrauensfehler hatte zwei zusammenhängende Ursachen: Betroffene Discovery-Pfade verglichen den issuer in den Metadaten des Authorization-Servers nicht durchgehend mit einem unabhängig vom MCP-Server erwarteten Issuer, und gespeicherte oder vorab bereitgestellte Zugangsdaten waren nicht an ihren vorgesehenen Issuer gebunden. Ein bösartiger oder kompromittierter MCP-Server konnte dadurch den Token-Austausch an einen von ihm kontrollierten Endpunkt lenken und OAuth-Material des Clients empfangen. Die Korrekturen ermitteln den erwarteten Issuer vor der Discovery, lehnen Abweichungen ab und binden gespeicherte Registrierungen an diesen Issuer; unbeaufsichtigte Machine-to-Machine-Provider benötigen außerdem ein explizites issuer=.^{[1], [2]}

Quellcode: Verwundbar vs. Sicher

Das Argument issuer ist in den korrigierten SDK-Versionen verfügbar. Es bindet Maschine-zu-Maschine-Zugangsdaten an den zuständigen Authorization Server; es ersetzt weder das Upgrade noch das Löschen alter ungebundener Registrierungen oder das Rotieren möglicherweise offengelegter Zugangsdaten.^{[2], [3], [8]}

Quelltextauszug: mcp.client.auth

VERWUNDBARE IMPLEMENTIERUNG

import os
from mcp.client.auth import ClientCredentialsOAuthProvider

auth = ClientCredentialsOAuthProvider(
    client_id=os.environ["MCP_CLIENT_ID"],
    client_secret=os.environ["MCP_CLIENT_SECRET"],
)

GEHÄRTETER SICHERHEITS-PATCH

import os
from mcp.client.auth import ClientCredentialsOAuthProvider

auth = ClientCredentialsOAuthProvider(
    client_id=os.environ["MCP_CLIENT_ID"],
    client_secret=os.environ["MCP_CLIENT_SECRET"],
    issuer=os.environ["MCP_AUTH_ISSUER"],
)
# Verwenden Sie mcp >= 1.30.0 (1.x) oder >= 2.2.0 (2.x).

Checkliste für Engineering & Systemsicherheit

✓Inventarisieren Sie HTTP-MCP-Clients und ermitteln Sie die tatsächlich installierte mcp-Version einschließlich transitiver Abhängigkeiten und Container-Images.^[1]
✓Aktualisieren Sie 1.x-Clients auf mcp 1.30.0 oder neuer und 2.x-Clients auf 2.2.0 oder neuer; prüfen Sie Lockfile und bereitgestellte Umgebung.^{[1], [3], [8]}
✓Setzen Sie issuer= bei ClientCredentialsOAuthProvider und PrivateKeyJWTOAuthProvider; migrieren Sie vom veralteten 1.x-RFC7523OAuthClientProvider, der diese Option nicht besitzt.^{[1], [2]}
✓Löschen Sie gespeicherte OAuth-Registrierungen aus der Zeit vor der Issuer-Bindung und registrieren Sie sie neu. Geben Sie bei einer selbst vorregistrierten Client-Information den Issuer explizit an.^{[1], [2]}
✓Umsetzungsempfehlung von FlawOpen: Behandeln Sie nicht vertrauenswürdige MCP-Server als Grenzen, an die Zugangsdaten gelangen können. Verbinden Sie sie nur gemäß Richtlinie mit Clients, die Produktionsgeheimnisse oder Signaturschlüssel besitzen.^[1]
✓Falls ein betroffener Client möglicherweise einen nicht vertrauenswürdigen Server genutzt hat, rotieren Sie das Client-Geheimnis und widerrufen Sie Tokens beim Authorization Server.^[1]
✓Fügen Sie Regressionstests für Discovery-Pfade von 1.x und 2.x, abweichende Issuer, fehlendes PRM, 403 insufficient_scope, issuergebundene Registrierungen und Machine-to-Machine-Anbieter ohne issuer= hinzu.^[2]
✓Prüfen Sie den Geltungsbereich dieses Advisorys, bevor Sie andere Clients als betroffen einstufen: Mit dem SDK erstellte Server, stdio-Clients und Clients mit eigenen Tokens oder Headern sind nicht betroffen.^[1]

Quellen

← AI Security Directory →