MCP Python SDK sendte OAuth-hemmeligheter til ondsinnede servere: oppgrader til 2.2.0 eller 1.30.0

Et hull rangert som High (CVSS 7,5) i MCP Python SDK lar en ondsinnet MCP-server stjele klienthemmeligheten, autorisasjonskoden og PKCE-nøkkelen som klienten din bruker mot den ekte innloggingsleverandøren, skriver sikkerhetsselskapet Cycode. Versjon 1.9.1 til 2.1.1 er rammet, i de tre auth-providerne OAuthClientProvider, ClientCredentialsOAuthProvider og PrivateKeyJWTOAuthProvider. Rettelsen kom i 2.2.0 og 1.30.0 den 7. september, mens advisoryen GHSA-qx49-fqc8-xw99 ble publisert 28. september.

Angrepet krever nesten ingenting. Serveren svarer 404 når SDK-en spør hvem som håndterer innloggingen, og SDK-en faller da tilbake til å hente OAuth-konfigurasjonen direkte fra den samme serveren. Issuer-sjekken kjører bare hvis SDK-en fikk en URL i det første steget, så på reserveveien hoppes den over.

«Sjekken feiler ikke. Den kjører aldri.» — Cycode, i gjennomgangen av hullet

Serveren kan dermed oppgi din ekte leverandør, for eksempel Google, Okta eller Azure AD, som issuer. Du sendes til den ekte innloggingssiden og godkjenner som vanlig, men token-endepunktet i konfigurasjonen peker til angriperen. Ifølge Cycode veksler angriperen så koden inn hos den ekte leverandøren og får et gyldig access token. Klienthemmeligheten er langlivet, så tilgangen varer til den roteres. Det eneste brukeren ser, er en MCP-server som ser ut til å feile etter innloggingen.

Poengsummen 7,5 gjelder de ubetjente providerne ClientCredentialsOAuthProvider og PrivateKeyJWTOAuthProvider. Den interaktive OAuthClientProvider er scoret til 6,5 fordi en person må starte innloggingen. Cycode mener det undervurderer risikoen i oppsett der en KI-agent selv velger hvilke MCP-servere den kobler til, fordi en prompt injection fra et hvilket som helst verktøy i kjeden kan styre agenten mot angriperens server.

MCP-servere bygget med SDK-en, lokale stdio-klienter og klienter som setter egne tokens eller headere, er ikke rammet. Har du ClientCredentialsOAuthProvider eller PrivateKeyJWTOAuthProvider, er oppgraderingen alene ikke nok: uten issuer= følger de fortsatt den leverandøren MCP-serveren peker på, og advarselen om det er lett å overse.

«På 1.30.0 er det en DeprecationWarning, som Python skjuler som standard.» — GitHub-advisoryen GHSA-qx49-fqc8-xw99

De samme to versjonene tetter også fire andre hull i SDK-en som ble publisert mellom 28. september og 5. oktober, blant dem CVE-2026-59951 om Streamable HTTP-sesjoner som aldri ble ryddet bort (7,5) og et hull der HTTP-klienten fulgte redirects til andre domener med egne headere og body (5,9). Nyeste versjon på 2.x-linja er 2.3.0 fra 2. oktober.

Hva bør du gjøre?

1. Kjør pip show mcp i alle prosjekter med MCP-klienter, og oppgrader til minst 2.2.0 eller 1.30.0.
2. Send med issuer= til ClientCredentialsOAuthProvider og PrivateKeyJWTOAuthProvider, og kjør testene med python -W error::DeprecationWarning for å fange providere du har glemt.
3. Slett lagret OAuth-klientinformasjon én gang etter oppgraderingen, og roter klienthemmeligheten og trekk tilbake tokens hvis klienten kan ha koblet til en MCP-server du ikke kontrollerer.