Python MCP SDK aktualisiert auf 1.30.0 / 2.2.0, um die Sicherheitslücke von OAuth Anmeldeinformationen zu korrigieren

Pythons offizielle SDK-Aufbewahrer für das Model Context Protocol (MCP) haben eine Sicherheitslücke korrigiert, die es einem bösartigen MCP-Server erlaubte, einen Client zu täuschen und ihn über gültige OAuth-Anmeldeinformationen zu verfügen, die verwendet wurden, um sich in einen echten Service einzuloggen. In den betroffenen Versionen sandte der Client den Angreifer Client-Geheimnis, Zulassungscode und der PKCE-Schlüssel (Schutzschlüssel), ausreichende Elemente für den Angreifer, um Zugriffstoken mit den Genehmigungen zu verlangen, die die Anwendung erhalten hatte.

Technisch ergibt sich das Problem in der Phase, wenn ein MCP-Client den Server anfordert, mit dem der Standort seines Berechtigungsdienstes verbunden ist. In verletzlichen Versionen hat das SDK nicht zuverlässig überprüft, ob die URL oder Emittent des Berechtigungsservers mit demjenigen zusammenfiel, den der Client erwartet hatte, bevor er dem OAuth-Austausch folgte. Ein schädlicher Server könnte antworten, indem er auf den angreifergesteuerten Token-Endpunkt hinweist - oder Metadaten verfälscht, um den legitimen Service zu nennen, während die Anfragen anderswo gerichtet werden - und so das Kundengeheimnis, den Autorisierungscode und den PKCE-Wert erhalten. Die Lieferung des PKCE-Wertes eliminiert den Schutz, der die Wiederverwendung eines abgefangenen Zulassungscodes verhindert.

Cycode, die Firma, die das Problem berichtete und demonstrierte, machte einen Beweisaustausch und zeigte, dass der daraus resultierende Token die gleichen Genehmigungen wie die ursprünglich für den Antrag zugelassenen trug. Die ADvisory des SDK legt die Schwerkraft bei 7,5 für Lieferanten, die ohne menschliche Präsenz (machine-to@-@-machine) und 6.5 für den interaktiven Lieferanten tätig sind, wo noch jemand den Login zu genehmigen hat. Korrekturen erscheinen in den Versionen 1.30.0(Zweig 1.x) und 2.2.0(Zweig 2.x) des SDK; die Änderungen wurden in Versionsnotizen enthalten, die am 7. September veröffentlicht wurden und der Sicherheitshinweis am 28. September veröffentlicht wurde, am selben Tag, als Cycode seine Analyse veröffentlichte.

Fakten bestätigt: Der offizielle Python SDK für MCP schickte Client-Geheimnis, Autorisierungscode und den PKCE-Beweisschlüssel an einen Endpunkt, der von einem bösartigen MCP-Server in Versionen vor 1.30.0 / 2.2.0 gesteuert wird; Cycode demonstrierte den Austausch im Labor; die Korrektur ist in 1.30.0 und 2.2.0; die Warnung über das Verhalten erschien zunächst als Änderung des Verhaltens in den Versionsnotizen; es gab keine CVE zugewiesen 29 September; es gab keine Berichte der Cycode, die beräte.

Welche Implementierungen und Rollen sind betroffen: die Anwendungen, die das SDK alsMCP-Clientauf HTTP und unter Verwendung eines dieser integrierten OAuth-Lieferanten: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider oder der obsolete RFC7523OAuthClient Anbieter aus der 1.xserie. Zur Exposition muss der Kunde in der Lage sein, sich mit einem MCP-Server zu verbinden, der nicht vollständig kontrolliert (z.B. Drittserver). MCP-Server mit dem SDK, lokalen Kunden (stdio) und Kunden, die manuell ihre eigenen Token befestigen, sind nicht betroffen.

Praktische Auswirkungen: Mit den gestohlenen Anmeldeinformationen kann ein Angreifer sie für einen gültigen Zugriffstoken im legitimen Authentifizierungsdienst austauschen und mit den der Anmeldung erteilten Genehmigungen handeln. Das Client-Geheimnis ist in der Regel von langer Dauer, so bleibt die Belichtung wirksam, bis das Geheimnis gebrochen ist. In Maschinen-zu-Maschine-Szenarien kann dies einen automatisierten Zugriff ohne die Notwendigkeit menschlicher Interaktion ermöglichen; im Falle des interaktiven Flusses kann die Benutzer-zugelassene Anmeldeseite echt sein und nicht sichtbare Zeichen der Manipulation zeigen, so dass das Opfer während der Autorisierung nichts anormales wahrnimmt.

Spezifische und unmittelbare Schritte, die von den Verantwortlichen zu ergreifen sind: zuerst aktualisieren Sie das SDK auf die korrigierten Versionen: 1.30.0 für Zweig 1.x oder 2.2.0 für die 2.x. Zweitens müssen für ClientCredentialsOAuthProvider oder PrivateKeyJWTOAuthProvider-Nutzer zusätzlich zur Aktualisierung explizit das Problem = Parameter zur Verfügung gestellt werden, der diese Anmeldeinformationen an den Autorisierungsdienst, zu dem sie gehören, verlinkt; ohne diesen Parameter werden die Anmeldeinformationen weiterhin die vom MCP-Server angegebene Adresse akzeptieren. Der veraltete Anbieter RFC7523OAuthClientProvider unterstützt keine Ausgabe = und sollte durch eine der beiden anderen ersetzt werden. Drittens, nach dem Update, entfernen Sie nur einmal alle OAuth-Client-Daten, die lokal von alten Versionen gespeichert wurden, weil diese Datensätze nicht mit einem Problem verknüpft waren und bleiben unsicher. Schließlich, wenn es eine Möglichkeit gibt, dass ein Client bereits mit einem unzuverlässigen Server verbunden hat, drehen Sie sofort das Client-Geheimnis und widerrufen Sie Token und Berechtigungen in dem betreffenden Identitätsdienst.

Als zusätzliche vorübergehende Minderungsmaßnahmen: Vermeiden Sie die Verbindung von MCP-Kunden zu Servern, die nicht kontrollieren oder nicht überprüfen können; aktivieren Sie Netzwerkkontrollen, die Token-Endpunkte-Ziele zu legitimen Dienstleistungen begrenzen; registrieren und überprüfen OAuth Austausche und Ausgabe von Ausnahmen im Audit-Log, um anormale Aktivität zu erkennen. Überprüfen Sie die Dokumentation des Identitätsanbieters für die Rotation und den Widerruf von Kunden und Token.

Einschränkungen und Unsicherheitsbereiche: Es gibt keine öffentlichen Beweise, dass die Verwundbarkeit in Produktionsumgebungen bisher ausgenutzt wurde; der Mangel an Berichten garantiert jedoch nicht, dass es keinen unentdeckten Missbrauch gibt. Am 29. September wurde auch noch eine CVE zugewiesen - dies könnte sich ändern, wenn die Betreuer oder Dritte den Ausfall später auf der CVE-Basis aufzeichnen. Die Folgenabschätzung auf bestimmte Systeme hängt davon ab, wie jede Organisation Geheimnisse, Kundenaufzeichnungen und die Kontrolle externer MCP-Server verwaltet.

Um besser zu verstehen, warum diese Schwachstelle besonders gefährlich ist, sollte das OAuth-Modell überprüft werden: OAuth 2.0 RFC 6749 und die PKCE-Mechanismen sollen sicherstellen, dass ein Zulassungscode von einem Dritten nicht wiederverwendbar ist. Wenn der Client den PKCE-Schlüssel freiwillig an den Angreifer liefert, wird diese Sperre aufgehoben. Für technische Informationen und Empfehlungen zur Verwaltung von Warnungen in Python (z.B. Abschreibungen, die standardmäßig bei 1.30.0 versteckt werden können), siehe die offizielle Python-Warndokumentation in docs.python.org. Der technische Bericht und die Demonstration des Unternehmens, die das Problem gemeldet haben, sind auf der Cycode-Website verfügbar: Cycode.

Kurz gesagt: Wenn Ihre Anwendung das offizielle MCP SDK als Client verwendet und MCP-Server vertraut, die nicht kontrollieren, so schnell wie möglich aktualisieren, das Problem gegebenenfalls konfigurieren, widerrufen und rotieren Anmeldeinformationen, wenn es eine mögliche Exposition gibt, und Ihre Datensätze und Richtlinien der Verbindung mit externen Servern überprüfen. Diese spezifischen Aktionen sind die einzigen, die das Risiko reduzieren, dass ein schädlicher MCP-Server eine legitime Interaktion in ein OAuth-Berechtigungsengagement verwandeln wird.