MCP-SDK-en for Python sendte OAuth-hemmeligheter til ondsinnede servere: oppdater til 1.30.0

Den offisielle Python-SDK-en for Model Context Protocol lot MCP-serveren bestemme hvor klientens OAuth-legitimasjon ble sendt, ifølge sikkerhetsselskapet Cycode, som fant feilen. Advisoryen GHSA-qx49-fqc8-xw99, publisert på GitHub 28. september, gir den CVSS 7,5 (High) for de ubetjente providerne og 6,5 for den interaktive OAuthClientProvider, der en person må starte innloggingen. Rammet er versjon 1.9.1 til 1.29.1 og 2.0.0 til 2.1.1 av PyPI-pakken mcp. Rettelsene lå på PyPI allerede 7. september, tre uker før detaljene ble offentlige.

Feilen sitter i discovery-steget, der klienten finner ut hvem som håndterer innloggingen. Svarer MCP-serveren 404, faller SDK-en tilbake til en eldre metode og ber serveren selv om autorisasjonskonfigurasjonen. Issuer-sjekken, som skal avsløre en server som lyver om innloggingsleverandøren, kjørte bare når det første steget hadde gitt en URL. På fallback-stien kjørte den aldri. Angriperen kan da oppgi din ekte leverandør, for eksempel Okta eller Azure AD, som issuer og samtidig peke token-endepunktet til sin egen server.

«Det eneste du ville sett, er en helt vanlig innloggingsside (fordi det er den ekte innloggingssiden), etterfulgt av at MCP-serveren ser ut til å feile.» — Cycode, via Security Boulevard

Etter at du har godkjent innloggingen, sender SDK-en authorization code, client_secret og PKCE-nøkkelen code_verifier til angriperen. PKCE er laget nettopp for å gjøre en stjålet kode verdiløs, men her får angriperen begge deler. Cycode demonstrerte hele kjeden mot en ekte autorisasjonsserver med PKCE påskrudd og hentet ut et gyldig access-token. Client secret er langlivet og kan gjenbrukes etter at økten er over.

Cycode mener «krever brukerinteraksjon» undervurderer risikoen for KI-agenter. Velger en agent selv hvilke MCP-servere den kobler til, kan en prompt injection fra et annet verktøy i kjeden styre den mot angriperens server, og godkjenner rammeverket innloggingsflyter automatisk, forsvinner det menneskelige leddet. Forgiftede oppføringer i MCP-kataloger og DNS-kapring er de to andre scenarioene selskapet peker på.

Ikke rammet er MCP-servere bygget med SDK-en, stdio-klienter og klienter som setter egne tokens eller headere.

«På tidligere versjoner finnes det ingen annen løsning enn å bare koble OAuth-aktiverte klienter til MCP-servere du stoler på.» — GitHub-advisoryen for MCP Python SDK

Hva bør du gjøre?

1. Sjekk versjonen med pip show mcp, og oppgrader til 1.30.0 på 1.x-linjen eller 2.2.0 på 2.x-linjen.
2. Bruker du ClientCredentialsOAuthProvider eller PrivateKeyJWTOAuthProvider, send med issuer= og URL-en til din egen autorisasjonsserver. Uten den følger de fortsatt serveren MCP-serveren peker på, og på 1.30.0 kommer advarselen som DeprecationWarning, som Python skjuler som standard. Parameteret blir påkrevd i 3.0.
3. Slett lagret OAuth-klientinformasjon én gang etter oppgraderingen, fordi registreringer lagret før 1.30.0 mangler issuer-binding. Bytt bort fra den utfasede RFC7523OAuthClientProvider, som ikke har noe issuer-valg.
4. Har klienten koblet til en MCP-server du ikke kontrollerer, roter client secret og tilbakekall tokens hos autorisasjonsserveren.

Bakgrunn

Dette er den fjerde advisoryen med severity High for Python-SDK-en i 2026, etter to i juni og én i juli. Samme dag publiserte prosjektet også GHSA-rwrf-2pqf-9j8j (Medium): klienten hentet $ref-URL-er valgt av serveren når den validerte verktøyresultater mot output-skjemaer. Den er rettet i de samme versjonene, så én oppgradering tar begge.