De MCP Python SDK lek waarover de beheerders een beveiligingsadvies publiceerden, laat zien hoe snel een slimme koppeling tussen AI-apps en externe tools kan ontsporen. In dit geval kan een kwaadwillende MCP-server een applicatie die de officiële Python SDK gebruikt, misleiden zodat OAuth-credentials naar een aanvaller worden doorgestuurd.
Het gaat om situaties waarin een MCP-client over HTTP verbinding maakt met een server die niet volledig onder uw controle valt én waarin de client ook beschikt over geldige gegevens om in te loggen op een echte service. Het resultaat: een aanvaller kan een toegangstoken aanvragen met dezelfde rechten als de applicatie.
Wat is Model Context Protocol (MCP)?
MCP, het Model Context Protocol, is een open standaard om AI-toepassingen te koppelen aan externe tools en data. Voor ontwikkelaars betekent dat: een vaste manier om aanvragen en context uit te wisselen met systemen buiten de AI-modellen om.
De officiële MCP Python SDK hoort daarbij: die pakket gebruikt u om MCP-servers en MCP-clients te bouwen. Juist omdat het om de “officiële” SDK gaat, heeft deze kwetsbaarheid potentieel brede impact op projecten die MCP inzetten.
Hoe werkt het MCP Python SDK lek?
Volgens het advies kan een kwaadaardige MCP-server een client laten denken dat het om de juiste loginservice gaat. Vervolgens stuurt de MCP Python SDK op de getroffen versies gevoelige OAuth-informatie naar een tokenendpoint dat de aanvaller beheert.
Concreet gaat het om het doorsluizen van onder meer:
- het client secret
- de authorization code
- de PKCE proof key (de eenmalige waarde bedoeld om hergebruik van gestolen codes te voorkomen)
Met die gegevens kan de aanvaller een geldig toegangstoken ophalen bij de echte loginservice. Zo’n token draagt de rechten die de applicatie eerder kreeg.
Omdat het client secret in veel scenario’s langdurig bruikbaar is, kan het probleem blijven doorwerken totdat het secret wordt aangepast.
Welke versies zijn getroffen en wat is de fix?
De oplossing zit in twee specifieke verbeterde versies:
- Upgrade naar 1.30.0 voor de 1.x-lijn
- Upgrade naar 2.2.0 voor de 2.x-lijn
In de gecorrigeerde versies controleert de client vooraf welke loginservice wordt verwacht. Als een kwaadwillende server een andere loginservice oplevert, weigert de SDK de verbinding/aanvraag.
Belangrijk: in de beschrijving van de beheerders blijkt dat upgraden niet voor alle OAuth-aanbieders “volledig automatisch” is.
Niet alles is opgelost met alleen upgraden
Voor twee OAuth-provider-varianten geldt dat het advies aangeeft dat er extra instellingen nodig zijn. Gebruikt u bijvoorbeeld ClientCredentialsOAuthProvider of PrivateKeyJWTOAuthProvider, dan verandert upgraden op zichzelf niets zolang u niet ook expliciet aangeeft bij welke loginservice de credentials horen.
Daarvoor moet u de parameter issuer= doorgeven. Zonder die issuer-binding kan de flow alsnog volgen wat de (kwaadwillende) MCP-server aanwijst.
In de oudere, gedeprecateerde variant RFC7523OAuthClientProvider is die issuer= mogelijkheid niet aanwezig. In dat geval raadt het advies aan om over te stappen op één van de andere twee providers.
Welke scenario’s worden als kwetsbaar gezien?
Een applicatie valt onder het risico als deze voldoet aan de combinatie uit het advies:
- De applicatie gebruikt de SDK als MCP client over HTTP.
- Er wordt een van de genoemde OAuth-providers gebruikt (o.a. OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider en de gedeprecateerde 1.x RFC7523OAuthClientProvider).
- De client kan connecten met een MCP-server die niet volledig vertrouwt of beheerd wordt.
- De applicatie heeft credentials die bedoeld zijn voor een echt loginmechanisme.
Daartegenover staan scenario’s die niet worden getroffen:
- MCP servers die u bouwt met de SDK (dus als serverkant draait)
- lokale (stdio) clients
- clients die hun eigen tokens toevoegen in plaats van via de OAuth-flow uit de SDK
Impact: wat kan een aanvaller precies doen?
Cycode, de beveiligingspartij die de kwetsbaarheid rapporteerde, toonde in een test hoe de complete uitwisseling van authorizationcode, PKCE-gegevens en client secret kan leiden tot een token dat is bruikbaar bij de echte dienst.
Dat token heeft dan de rechten die aan de applicatie waren toegekend. Met andere woorden: het gaat niet alleen om “lekken en verstoppen”, maar om het daadwerkelijk misbruiken van toegangsrechten.
Volgens de beoordeling in het advies is de ernst hoog. De exacte score verschilt per type provider: voor machine-to-machine varianten zonder menselijke goedkeuring is de beoordeling 7,5, terwijl voor de interactieve provider (met gebruikersgoedkeuring) de score 6,5 geldt.
Zo pakt u dit praktisch aan
Het advies is duidelijk over de eerste stap: upgrade naar de gefixte versies. Maar daarna komt de werkelijke herstelactie.
1) Update de MCP Python SDK
Werk uw afhankelijkheid bij naar 1.30.0 of 2.2.0, afhankelijk van uw lijn. Let op dat Python de deprecation waarschuwingen soms standaard verbergt; het advies meldt dat u daardoor belangrijke aanwijzingen kunt missen.
2) Bind bij providers ook de juiste issuer
Gebruikt u ClientCredentialsOAuthProvider of PrivateKeyJWTOAuthProvider? Zorg dan dat u issuer= meegeeft zodat de SDK niet door een MCP-server kan worden “omgeleid” naar een ander loginpad.
3) Rotteer secrets en tokens
Na het upgraden is het verstandig om:
- één keer opgeslagen OAuth clientregistraties te opschonen, omdat oudere registraties niet aan een loginservice gekoppeld zijn
- het client secret te roteren als er kans bestaat dat de client al met een niet-vertrouwde MCP-server heeft gepraat
- tokens te intrekken bij de loginservice
Heeft u oudere versies? Dan is er volgens het advies geen echte praktische omweg behalve: alleen connecten met MCP-servers die u vertrouwt.
Waarom dit ook voor uw bredere AI-veiligheid relevant is
Deze kwestie raakt aan een terugkerend thema in beveiliging rond AI-integraties: zodra een applicatie automatisch kan “praten” met externe systemen, ontstaat het risico dat die systemen de beveiligingslogica proberen te sturen. In dit geval gebeurt dat via de OAuth-provider-koppeling en de manier waarop de SDK de verwachte loginservice controleert.
Als u meer wilt lezen over het veiliger inrichten van agent-achtige systemen en toegang, kan ook dit artikel relevant zijn: Zero Trust voor AI-agents: start met zichtbaarheid.
Daarnaast is het nuttig om aandacht te besteden aan het principe “least privilege” en aan hoe incidentafhandeling en context zorgen voor sneller herstel. Daarover vindt u eveneens achtergrond in Focus: stateful SOC en AI in incidentafhandeling.
Geen CVE genoemd, maar wel direct handelen
Op 29 september was er volgens het advies nog geen CVE toegewezen. Dat verandert echter weinig aan het feit dat het om een concreet misbruikscenario gaat: het kunnen verkrijgen van toegangstokens door OAuth-gegevens die naar een aanvaller worden doorgestuurd.
Omdat de fix beschikbaar is in specifieke SDK-versies en omdat u daarna secrets/tokens moet roteren, is het verstandig om dit niet te laten “staan tot later”.
Conclusie
De MCP Python SDK lek toont aan dat integraties tussen AI-apps en externe services niet alleen functioneel, maar ook beveiligd moeten zijn. In de getroffen versies kan een kwaadwillende MCP-server OAuth-credentials omleiden naar een aanvaller, waarna een geldig toegangstoken kan worden aangevraagd.
De kernaanpak is simpel: upgrade naar 1.30.0 of 2.2.0, controleer of u de juiste issuer=-instellingen gebruikt, en roteer secrets en tokens als er al contact met een niet-vertrouwde server mogelijk was.
Bron: https://thehackernews.com/2026/09/official-mcp-python-sdk-flaw-can-let.html
