LONDON (IT BOLTWISE) – Laut einem Security Advisory kann ein bösartiger MCP-Server Anwendungen, die das offizielle MCP-Python-SDK nutzen, dazu bringen, OAuth-Credentials an den Angreifer zu übergeben. Betroffene Versionen schicken Client-Secret, Authorization-Code und den PKCE-Proof-Key an einen Token-Endpunkt, den der Server kontrolliert. Mit dem gestohlenen Token lassen sich dann Zugriffen abrufen, die die Anwendung zuvor erhalten hatte. Die Lösung steht in Version 1.30.0 sowie 2.2.0 bereit.
Wer MCP als Verbindungsstandard zwischen KI-Anwendungen und externen Tools nutzt, baut faktisch eine Integrationsbrücke aus mehreren Protokollen. Genau dort setzt der aktuelle Sicherheitsbericht an: Das offizielle MCP-Python-SDK soll in bestimmten Versionen nicht immer verlässlich prüfen, welcher OAuth-„Authorization Server“ beim Login tatsächlich erwartet wird. Dadurch reicht es, dass ein MCP-Client zu einem Server verbindet, den er nicht vollständig kontrolliert, und gleichzeitig OAuth-Credentials für einen echten Login-Service vorliegen. In der Praxis bedeutet das Risiko nicht „nur“ eine Fehlkonfiguration, sondern eine gezielte Umleitung der Authentifizierungsdaten an einen Token-Endpunkt, den der Angreifer selbst kontrolliert.
Der Angriff läuft nach dem beschriebenen Mechanismus über den OAuth-Ablauf beim Verbindungsaufbau. Wenn der MCP-Client sich anmelden muss, erfragt er beim angebundenen Server, wo der Authorization Server erreichbar ist. Auf den betroffenen SDK-Versionen genügt dann eine manipulierte Antwort: Der MCP-Server kann den Client auf die Login-Infrastruktur des Angreifers umleiten, oder er liefert Login-Details, die wie die echte Nutzer- bzw. Zielumgebung aussehen, während die Credentials anderswo landen. Anschließend sendet der Client im OAuth-Fluss das Client-Secret, den Authorization-Code und auch den PKCE-Proof-Key an den vom Angreifer kontrollierten Token-Endpunkt. Damit fällt ein Kernschutz aus: PKCE ist zwar als Einmalwert gedacht, um einen gestohlenen Authorization-Code nicht wiederverwenden zu können, aber der Proof-Key ist genau das, was in dieser Variante mit abfließt.
Besonders brisant ist die Wirkung je nach OAuth-Provider-Typ. Bei einem interaktiven Provider muss die Person zwar noch zustimmen; der Bericht beschreibt aber, dass die genehmigte Seite für den Benutzer die echte Login-Seite ist, sodass es während der Freigabe keine offensichtliche Abweichung geben muss. Die zwei nicht-interaktiven Provider funktionieren hingegen ohne menschliche Bestätigung vollständig durch. Laut Advisory ist das Client-Secret zudem langlebig, sodass ein bereits abgegriffenes Secret weiter nutzbar bleibt, bis es explizit geändert wird. Die Bewertung der Schwere spiegelt diese Unterschiede wider: Für die beiden Maschinen-zu-Maschinen-Provider wird die Schwachstelle mit 7,5 eingestuft, für den interaktiven Ablauf mit 6,5.
Welche Anwendungen wirklich betroffen sind, hängt an zwei Faktoren: Nutzung des SDK als MCP-Client über HTTP und die konkrete OAuth-Konfiguration. Betroffen ist demnach ein Setup, das über einen der genannten OAuth-Provider arbeitet, etwa OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider oder den in 1.x als deprecated genannten RFC7523OAuthClientProvider, und dabei zu einem MCP-Server verbindet, den man nicht vollständig kontrolliert, während OAuth-Zugangsdaten für einen echten Dienst im Spiel sind. Nicht betroffen sind MCP-Server, die ausschließlich selbst mit dem SDK gebaut wurden, lokale (stdio) Clients sowie Konstellationen, in denen der Client seine eigenen Tokens bereits vorgelagert bereitstellt. Genau diese Abgrenzung ist für Betreiber wichtig: Wer Tokens intern verwaltet oder gar nicht über den OAuth-Provider-Fluss des SDK geht, reduziert die Expositionsfläche erheblich.
Das Fix-Pattern ist gleichzeitig klar und leicht zu übersehen. Empfohlen wird ein Upgrade auf 1.30.0 in der 1.x-Linie oder auf 2.2.0 in der 2.x-Linie. In den fest eingestellten Versionen soll der Client im Ablauf vor dem Abruf relevanter Details ausarbeiten, welcher Login-Service erwartet wird, und er soll Antworten ablehnen, die einen abweichenden Authorization-Server benennen. Für zwei der Provider reicht das Upgrade laut Advisory aber nicht aus: Wer ClientCredentialsOAuthProvider oder PrivateKeyJWTOAuthProvider verwendet, muss zusätzlich beim Provider-Setup das Parameter „issuer=“ übergeben, damit die Credentials auch wirklich dem vorgesehenen Login-Service zugeordnet sind. Ohne diesen Zusatz sollen sie weiterhin dem folgen, was der MCP-Server vorgibt. In der 1.30.0-Version wird diese Änderung als Deprication-Warnung behandelt; Python blendet solche Hinweise im Standardbetrieb aus, wodurch Entwickler den Hinweis im Alltag schnell übersehen.
Nach dem Upgrade fordert die Empfehlung dann zwei weitere operative Schritte ein. Erstens: vorhandene OAuth-Client-Registrierungen einmal bereinigen, weil ältere Registrierungen nicht an einen Login-Service gebunden sind und daher weiterhin in einem unspezifizierten Modus existieren könnten. Zweitens: wenn ein Client bereits mit einem untrusted MCP-Server verbunden war, sollten Client-Secret rotiert und Tokens beim Login-Service widerrufen werden. Für ältere Versionen existiert dem Bericht zufolge praktisch keine Alternative außer dem konsequenten Betrieb nur mit vertrauenswürdigen MCP-Servern. Interessant ist außerdem der zeitliche Kontext: Die „issuer“-Prüfungen wurden bereits am 7. September in den Release Notes als Verhaltensänderungen aufgenommen, während das eigentliche Security Advisory am 28. September nach Veröffentlichung einer technischen Ausarbeitung folgte; dabei wurden acht Meldende genannt, darunter auch ein Researcher eines Sicherheitsanbieters. Bislang wird keine konkrete Ausnutzung des Problems gemeldet, allerdings zeigt gerade die Kombination aus langlebigen Secrets und fehlender Authorization-Server-Validierung, warum das Abwehrfenster jetzt eng auszufüllen ist.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Schwachstelle im offiziellen MCP-Python-SDK: OAuth-Credentials abgreifbar" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Schwachstelle im offiziellen MCP-Python-SDK: OAuth-Credentials abgreifbar" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Schwachstelle im offiziellen MCP-Python-SDK: OAuth-Credentials abgreifbar« bei Google Deutschland suchen, bei Bing oder Google News!