Een kwetsbaarheid in de officiële MCP Python SDK kan kwaadwillende servers misleiden om OAuth-gegevens van een gebruiker te stelen, zo waarschuwen de beheerders van de SDK in een beveiligingsadvies. De getroffen versies stuurden het client secret, de autorisatiecode en de PKCE-proof key naar een token endpoint dat door de aanvaller werd gecontroleerd. Met deze gestolen gegevens kan de aanvaller een geldig toegangstoken aanvragen bij de echte inlogservice.

De Model Context Protocol (MCP) is een open standaard voor het koppelen van AI-toepassingen aan externe tools en data. De Python SDK is het officiële pakket voor het bouwen van MCP-servers en -clients. De beveiligingsfirma Cycode, die het lek meldde, demonstreerde het volledige proces in een testomgeving en stelt dat het verkregen token dezelfde rechten heeft als de app die het gebruikte. Omdat het client secret lang geldig blijft, blijft het lek actief totdat het secret wordt gewijzigd.

De kwetsbaarheid is beoordeeld met een hoge ernstscore van 7,5 voor providers die zonder menselijke tussenkomst werken. Voor interactieve providers, waarbij een gebruiker moet inloggen, is de score 6,5. Tot 29 september was er nog geen CVE-nummer toegekend. Het probleem ontstaat doordat de SDK in de getroffen versies niet altijd controleert of de opgegeven autorisatieserver overeenkomt met de verwachte. Een malafide MCP-server kan daardoor een client naar een door de aanvaller beheerde token endpoint leiden, waardoor de OAuth-gegevens onbedoeld naar de aanvaller worden gestuurd.

De interactie met de gebruiker verloopt via een echte inlogpagina, waardoor er geen zichtbare afwijkingen zijn. Voor machine-to-machine providers is geen gebruikersinteractie nodig, waardoor het risico groter is. Applicaties die de SDK als MCP-client gebruiken via HTTP en verbinding maken met een server die ze niet volledig vertrouwen, lopen risico als ze credentials voor een echte inlogservice bevatten. MCP-servers gebouwd met de SDK, lokale clients en clients die eigen tokens gebruiken, zijn niet kwetsbaar.

De kwetsbaarheid is opgelost in versie 1.30.0 van de 1.x-lijn en 2.2.0 van de 2.x-lijn van de SDK. In deze versies controleert de client vooraf welke inlogservice wordt verwacht en weigert afwijkende antwoorden. Voor de providers ClientCredentialsOAuthProvider en PrivateKeyJWTOAuthProvider is het daarnaast noodzakelijk om de parameter issuer= mee te geven, zodat de credentials aan een specifieke inlogservice worden gekoppeld. Zonder deze aanpassing blijven de credentials nog steeds volgen naar de server die de MCP-server aanwijst. De verouderde RFC7523OAuthClientProvider ondersteunt deze parameter niet en moet daarom worden vervangen.

Na het updaten is het aanbevolen om opgeslagen OAuth-registraties te verwijderen, omdat oudere registraties niet aan een inlogservice zijn gekoppeld. Indien een client mogelijk al verbinding heeft gemaakt met een onbetrouwbare server, moeten het client secret worden geroteerd en tokens worden ingetrokken bij de inlogservice. Voor oudere versies bestaat geen workaround behalve alleen verbinding maken met volledig vertrouwde MCP-servers.