Der Fehler steckt im Auffinden des Anmeldedienstes: Wenn ein MCP-Client sich anmelden muss, fragt er beim Server, zu dem er sich verbindet, nach dem zuständigen Autorisierungsserver. In den betroffenen Versionen prüfte das SDK diese Antwort nicht in jedem Fall. Ein bösartiger Server konnte den Client damit auf einen Anmeldedienst seiner Wahl lenken — entweder, indem er den eigenen Server benannte, oder indem er Anmeldedaten auslieferte, die zwar den echten Dienst des Nutzers nennen, die Zugangsdaten aber anderswohin schicken.
Der Client übermittelt daraufhin sein Secret, seinen Autorisierungscode und seinen PKCE-Nachweisschlüssel an den Angreifer statt an den echten Dienst. Da der Nachweisschlüssel ein Einmalwert ist, der gerade die Wiederverwendung eines gestohlenen Autorisierungscodes verhindern soll, fällt mit seiner Preisgabe auch dieser Schutz.
Beim interaktiven Provider muss eine Person die Anmeldung weiterhin bestätigen. Cycode weist allerdings darauf hin, dass die Seite, die sie zu sehen bekommt, die echte Anmeldeseite ist — es wirkt also nichts verdächtig. Die beiden Maschine-zu-Maschine-Provider kommen ganz ohne Anmeldung und ohne Person aus.
Betroffen ist eine Anwendung, wenn sie das SDK als MCP-Client über HTTP mit einem der OAuth-Provider OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider oder dem veralteten RFC7523OAuthClientProvider aus der 1.x-Reihe nutzt und sich mit einem Server verbinden kann, den sie nicht vollständig kontrolliert, während sie Zugangsdaten für einen echten Anmeldedienst hält. Mit dem SDK gebaute MCP-Server, lokale Clients über stdio sowie Clients, die eigene Tokens mitbringen, sind nicht betroffen.
Als Abhilfe empfehlen die Betreuer den Wechsel auf 1.30.0 in der 1.x-Linie beziehungsweise 2.2.0 in der 2.x-Linie. In den korrigierten Versionen ermittelt der Client den erwarteten Anmeldedienst, bevor er irgendwelche Details abruft, und weist jede Angabe zurück, die einen anderen nennt.
Für zwei der Provider reicht das Update allein nicht. Wer ClientCredentialsOAuthProvider oder PrivateKeyJWTOAuthProvider einsetzt, muss laut Hinweis zusätzlich den Parameter issuer= übergeben — „ein Upgrade ändert nichts, solange Sie nicht auch issuer= übergeben", um den Anmeldedienst zu benennen, zu dem die Zugangsdaten gehören. Ohne ihn folgen sie weiterhin dem Anmeldedienst, auf den der MCP-Server verweist. In 1.30.0 erscheint der Hinweis darauf als gewöhnliche Deprecation-Warnung, die Python standardmäßig ausblendet und die daher leicht übersehen wird. Der veraltete RFC7523OAuthClientProvider kennt gar keine issuer=-Option; hier bleibt nur der Wechsel zu einem der beiden anderen Provider.
Nach dem Upgrade sollten gespeicherte OAuth-Client-Registrierungen einmalig gelöscht werden, da ältere Einträge nicht an einen Anmeldedienst gebunden sind und dies auch bleiben. Hat ein Client womöglich bereits mit einem nicht vertrauenswürdigen Server gesprochen, rät der Hinweis, das Client Secret zu wechseln und die Tokens beim Anmeldedienst zu widerrufen. Für ältere Versionen gibt es keinen Workaround außer der Beschränkung auf vertrauenswürdige MCP-Server.
Die Issuer-Prüfungen kamen bereits am 7. September mit den Release Notes zu 1.30.0 und 2.2.0 — dort allerdings unter Verhaltensänderungen aufgeführt und nicht als Sicherheitskorrektur. Der Sicherheitshinweis folgte am 28. September, am selben Tag veröffentlichte Cycode seine Analyse. Genannt werden acht Meldende, darunter der Forscher von Cycode. Weder der Hinweis noch Cycode berichten von Angriffen über die Lücke; auch anderswo wurden keine bekannt.