Lücke im MCP Python SDK lässt bösartige Server Ihre OAuth-Credentials umlenken: Upgrade auf 1.30.0 oder 2.2.0, dann issuer= übergeben

MMCP Python SDKWichtig18. Oktober 2026Sicherheit
Was ist passiert
Am 28. September veröffentlichten die Maintainer des MCP Python SDK den Sicherheitshinweis GHSA-qx49-fqc8-xw99 (CVSS 7,5): Ein bösartiger MCP-Server konnte die Credentials eines OAuth-Clients an einen Autorisierungsserver seiner Wahl umlenken.
Warum es wichtig ist
Python-MCP-Clients über HTTP mit mcp 1.9.1 bis 1.29.1 oder 2.0.0 bis 2.1.1 können langlebige Client-Secrets preisgeben, und der Patch bewirkt bei den beiden Machine-to-Machine-Providern ohne issuer= nichts.
Was zu tun ist
Auf mcp 1.30.0 oder 2.2.0 aktualisieren, issuer= bei ClientCredentialsOAuthProvider und PrivateKeyJWTOAuthProvider übergeben, gespeicherte Registrierungen löschen und die Secrets rotieren, falls sie offengelegt wurden.

Unser Urteil: Wenn Sie MCP-Clients in Python mit dem offiziellen MCP Python SDK bauen (nicht in unserem Verzeichnis) und sich per HTTP mit Servern verbinden, die Sie nicht kontrollieren, patchen Sie noch heute. Bei zwei der vier betroffenen Provider ändert ein Upgrade allein nichts: Sie müssen zusätzlich issuer= übergeben. Die Maintainer stufen die Lücke als High ein, CVSS 7,5. Es wurden keine Angriffe gemeldet.

Was passiert ist

Am 28. September 2026 veröffentlichten die SDK-Maintainer den Sicherheitshinweis GHSA-qx49-fqc8-xw99 mit dem Titel „OAuth-Client könnte Credentials an einen vom MCP-Server gewählten Autorisierungsserver senden“. Laut dem Sicherheitshinweis wurde der issuer in den Metadaten des Autorisierungsservers nicht auf jedem Discovery-Pfad validiert, und gespeicherte oder vorab bereitgestellte Client-Credentials waren nicht an den Autorisierungsserver gebunden, zu dem sie gehören. Ein bösartiger MCP-Server konnte die Credentials eines Clients daher auf einen Endpunkt unter seiner Kontrolle lenken. The Hacker News nennt, was offengelegt wird: das Client-Secret, den Autorisierungscode und den PKCE-Proof-Key.

  • Schweregrad: CVSS 3.1 7,5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) für die Machine-to-Machine-Provider, 6,5 für den interaktiven Provider, der eine Freigabe durch den Nutzer erfordert. Es ist keine CVE zugewiesen.
  • Betroffene Provider: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider und der veraltete RFC7523OAuthClientProvider aus 1.x.
  • Betroffene Versionen: mcp 1.9.1 bis 1.29.1 sowie 2.0.0 bis 2.1.1.
  • Gepatcht: mcp 1.30.0 und 2.2.0.
  • Nicht betroffen: mit dem SDK gebaute MCP-Server, stdio-Clients und Clients, die eigene Tokens oder Header mitsenden.
  • Ausnutzung: Laut The Hacker News melden weder der Sicherheitshinweis noch Cycode Angriffe.

Warum es wichtig ist

Laut The Hacker News erschien der Fix bereits am 7. September 2026, drei Wochen vor dem Sicherheitshinweis. Ein routinemäßiges Upgrade kann ihn also schon eingespielt haben, was ein falsches Sicherheitsgefühl erzeugt: Er schützte nur beim interaktiven Provider.

ClientCredentialsOAuthProvider und PrivateKeyJWTOAuthProvider sind die Machine-to-Machine-Provider, und sie halten langlebige Client-Secrets und private Schlüssel. Bei diesen beiden bindet der gepatchte Code Credentials nur, wenn Sie ein Argument issuer= übergeben, das den Autorisierungsserver benennt, zu dem sie gehören. Lassen Sie es weg, erhalten Sie eine Deprecation-Warnung und keinen Schutz. Unbeaufsichtigte Clients mit langlebigen Secrets, geschützt nur durch eine Warnung, die niemand liest: Das macht einen außerplanmäßigen Patch lohnend.

Was sich für Sie ändert

  1. Aktualisieren Sie mcp auf 1.30.0 (1.x) oder 2.2.0 (2.x).
  2. Übergeben Sie bei ClientCredentialsOAuthProvider und PrivateKeyJWTOAuthProvider ausdrücklich issuer=, zum Beispiel issuer="https://auth.example.com". In 3.0 wird es Pflicht.
  3. Wenn Sie RFC7523OAuthClientProvider nutzen, stellen Sie auf einen anderen Provider um: Er hat keine Option issuer=.
  4. Löschen Sie gespeicherte OAuth-Registrierungen einmal, damit sich die Clients mit Issuer-Bindung neu registrieren.
  5. Wenn ein Client möglicherweise einen nicht vertrauenswürdigen MCP-Server erreicht hat, rotieren Sie dessen Client-Secrets beim Autorisierungsserver und widerrufen Sie seine Tokens.

Kein Tool in unserem Verzeichnis ist das SDK selbst. Wenn Sie einen Python-Agenten oder ein Gateway betreiben, das MCP über HTTP spricht, prüfen Sie, welche SDK-Version es festschreibt.

FAQ

Bin ich betroffen, wenn ich nur MCP-Server baue? Nein. Der Sicherheitshinweis führt mit dem SDK gebaute MCP-Server ebenso als nicht betroffen auf wie stdio-Clients.

Ich habe schon im September aktualisiert. Bin ich sicher? Nur beim interaktiven OAuthClientProvider. Bei den beiden Machine-to-Machine-Providern sind Sie weiterhin exponiert, bis Sie issuer= übergeben.

Gibt es eine CVE, die ich verfolgen kann? Nein. Verfolgen Sie GHSA-qx49-fqc8-xw99.

Was zu tun ist

  1. 1 Das Paket mcp auf 1.30.0 (1.x) oder 2.2.0 (2.x) aktualisieren.
  2. 2 Wer ClientCredentialsOAuthProvider oder PrivateKeyJWTOAuthProvider nutzt, übergibt issuer= ausdrücklich. Ohne diesen Parameter schützt das Upgrade nichts, und das einzige Signal ist eine Deprecation-Warnung.
  3. 3 Wer den veralteten RFC7523OAuthClientProvider nutzt, stellt auf einen anderen Provider um: Er hat keine Option issuer=.
  4. 4 Gespeicherte OAuth-Client-Registrierungen nach dem Upgrade einmal löschen, damit sich die Clients mit Issuer-Bindung neu registrieren.
  5. 5 Wenn ein Client möglicherweise mit einem nicht vertrauenswürdigen MCP-Server verbunden war, dessen Client-Secrets beim Autorisierungsserver rotieren und bestehende Tokens widerrufen.

Betroffene Tools & Modelle

MCP Python SDK

Nie wieder etwas verpassen

Das wöchentliche Delta: nur Urteilsänderungen und dringende Punkte. Kein Füllmaterial.

Mit dem Abonnieren stimmst du unserer Datenschutzerklärung zu. Jederzeit abbestellbar.