MCP-TypeScript-SDK ließ bösartige Server bestimmen, wohin OAuth-Tokens und Secrets gingen

Victoria Shinder07 October 2026, 07:332 Min. Lesezeit

Ein am 6. Oktober veröffentlichter Sicherheitshinweis, GHSA-6qxp-vccf-f47h (CVE-2026-104850, hoch), beschreibt eine Schwachstelle im OAuth-Client des TypeScript-SDK für das Model Context Protocol: Zugangsdaten waren nicht an den Autorisierungsserver gebunden, zu dem sie gehören – der MCP-Server entschied, wohin sie gingen.

Der Angriff. Ein bösartiger oder kompromittierter MCP-Server konnte einen eigenen Autorisierungsserver angeben. Ohne Zutun des Nutzers schickte der Client ihm dann das aus einer früheren Anmeldung gespeicherte refresh_token und client_secret oder das bei einem mitgelieferten Provider hinterlegte client_secret bzw. die signierte Assertion.

Betroffen sind Anwendungen, die den OAuth-Client des SDK über HTTP nutzen – per authProvider an einem Transport, über die Middleware withOAuth() oder direkte Aufrufe von auth() bzw. fetchToken() – und die sich mit einem nicht voll vertrauenswürdigen MCP-Server verbinden können, während sie Zugangsdaten für einen legitimen Autorisierungsserver halten.

• @modelcontextprotocol/sdk 1.12.0 bis 1.30.1;
• @modelcontextprotocol/client 2.0.0 bis 2.1.0, in den im Hinweis genannten Fällen.

Mit dem SDK gebaute MCP-Server und stdio-Clients sind nicht betroffen.

Die Korrektur. Update auf @modelcontextprotocol/sdk 1.31.0 bzw. @modelcontextprotocol/client 2.2.0 (und @modelcontextprotocol/core 2.2.0 bei direktem Import). Der Client speichert den Autorisierungsserver jetzt als issuer bei den Zugangsdaten und schickt sie an keinen anderen.

Wann das Update nicht reicht. Der Hinweis nennt drei Fälle, die eine Änderung an Code oder Daten erfordern:

• Mitgelieferte Provider (ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider, CrossAppAccessProvider) brauchen expectedIssuer; ohne ihn nutzen sie weiter den Server, den der MCP-Server nennt.
• Ohne issuer gespeicherte Zugangsdaten, darunter alles, was 1.x vor 1.31.0 abgelegt hat, gehen weiterhin an den beim ersten Gebrauch genannten Server: issuer ergänzen oder die Daten löschen, damit sich Nutzer neu anmelden.
• Eigene OAuthClientProvider-Implementierungen müssen genau das speichern, was saveTokens() und saveClientInformation() erhalten, einschließlich issuer.

Nicht abgedeckt sind eine neue interaktive Anmeldung, die weiterhin an den vom MCP-Server genannten Server geht, direkte Aufrufe von refreshAuthorization() und exchangeAuthorization() sowie 2.x mit skipIssuerMetadataValidation: true. Hat ein betroffener Client womöglich mit einem nicht vertrauenswürdigen MCP-Server gesprochen, rät der Hinweis außerdem, die Zugangsdaten zu rotieren.