--- title: Fels i MCP Python SDK kan låta skadliga servrar stjäla OAuth-uppgifter url: https://www.elseif.net/sv/fels-i-mcp-python-sdk-kan-lata-skadliga-servrar-stjala-oauth-uppgifter published: 2026-09-30T09:36:50+00:00 language: sv section: Modeller source: https://thehackernews.com/2026/09/official-mcp-python-sdk-flaw-can-let.html organizations: MCP, Python SDK, OAuth publisher: elseif --- # Fels i MCP Python SDK kan låta skadliga servrar stjäla OAuth-uppgifter En skadlig MCP-server kan lura en applikation som använder den officiella MCP Python SDK att överlåta OAuth-uppgifterna den använder för att logga in på en verklig tjänst, enligt en säkerhetsavisering från SDK:s underhållare. Felsökningen gäller versioner som skickade klienthemligheten, auktoriseringskoden och PKCE-bevisnyckeln till en tokenendpoint som attackeraren kontrollerade. Rättelsen finns i version 1.30.0 och 2.2.0. SDK är den officiella Python-implementeringen av Model Context Protocol, ett öppet standardformat för att koppla AI-tillämpningar till externa verktyg och data. Med de stulna uppgifterna kan angriparen begära ett giltigt åtkomsttoken från den verkliga inloggningstjänsten. Cycode, som upptäckte felet, visade att tokenet får de behörigheter som appen har. Klienthemligheten är långlivad och fungerar tills den ändras. Felen har en allvarlighetsgrad på 7,5 för de två typerna av leverantörer som körs utan mänsklig inblandning. För interaktiv leverantör, där en användare måste godkänna inloggningen, är poängen 6,5. Ingen CVE har tilldelats per den 29 september. Så här kan en server stjäla uppgifterna När en MCP-klient ska logga in frågar den servern var dess inloggningstjänst, kallad auktoriseringsserver, finns. I de påverkade versionerna kontrollerade SDK inte alltid detta svar. En skadlig server kan peka på en egen auktoriseringstjänst eller på en legitim tjänst medan den skickar uppgifterna till en annan plats. Klienten skickar då sin hemlighet, auktoriseringskod och PKCE-bevisnyckel till angriparen istället för till den verkliga tjänsten. Bevisnyckeln är en engångsvärde som ska förhindra att en stulen auktoriseringskod kan återanvändas, så att överlåta den bryter den skyddet. Med interaktiv leverantör krävs fortfarande att en användare godkänner inloggningen. Cycode påpekade att sidan som godkänns är den äkta inloggningssidan, så inget ser fel ut. För maskin-till-maskin-leverantörer behövs ingen godkännande och ingen mänsklig inblandning. En applikation påverkas om den använder SDK som MCP-klient över HTTP med någon av OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider eller den borttagna 1.x RFC7523OAuthClientProvider, och den kan ansluta till en server som den inte fullt kontrollerar medan den har uppgifter för en verklig inloggningstjänst. SDK:en byggda MCP-servrar, lokala (stdio)-klienter och klienter som själva lägger till token är inte påverkade. Uppgradera till 1.30.0 på 1.x-linjen eller 2.2.0 på 2.x-linjen. I de rättade versionerna kontrollerar klienten vilken auktoriseringstjänst den förväntar sig innan den hämtar några uppgifter och avvisar dem som pekar på en annan. Uppgraderingen är dock inte tillräcklig för två av leverantörerna. Om du använder ClientCredentialsOAuthProvider eller PrivateKeyJWTOAuthProvider ska du dessutom ange issuer=" för att namnge den auktoriseringstjänst som credentialen tillhör. Annars följer de den server som MCP-servern pekar på. I version 1.30.0 visas en varning om detta som en standarddeprecation, vilket Python döljer som standard, så den kan lätt missas. Den borttagna RFC7523OAuthClientProvider har ingen issuer=‑alternativ, så byt till någon av de andra två leverantörerna. Efter uppgraderingen ska du radera lagrade OAuth-klientregistreringar, eftersom gamla registreringar inte är kopplade till en auktoriseringstjänst och förblir sådana. Om en klient kan ha anslutit till en ogiltig server, rotera dess klienthemlighet och återkalla dess tokener hos inloggningstjänsten. I äldre versioner finns ingen annan lösning än att endast ansluta till MCP-servrar du litar på. Issuer‑kontroller som levererades i version 1.30.0 och 2.2.0 publicerades i release‑notisen den 7 september under beteendeförändringar snarare än som en säkerhetsuppdatering. Aviseringen kom den 28 september, samma dag som Cycode publicerade sin analys. Aviseringen tackar bland andra Cycode‑forskaren. Ingen attack med felet har rapporterats och ingen annan liknande incident har framkommit.