Wprowadzenie do problemu / definicja
W oficjalnym Python SDK dla Model Context Protocol (MCP) wykryto poważną lukę bezpieczeństwa, która może prowadzić do ujawnienia poświadczeń OAuth złośliwemu lub przejętemu serwerowi MCP. Problem dotyczy logiki klienta odpowiedzialnej za obsługę uwierzytelniania oraz walidację metadanych serwera autoryzacji.
W praktyce oznacza to, iż aplikacje korzystające z podatnych wersji biblioteki mogą przesłać wrażliwe dane, takie jak sekret klienta, kod autoryzacyjny czy elementy wykorzystywane przez PKCE, do infrastruktury kontrolowanej przez atakującego.
W skrócie
- Podatność dotyczy oficjalnego MCP Python SDK używanego po stronie klienta przez HTTP.
- Zagrożone są wersje 1.9.1–1.29.1 oraz 2.0.0–2.1.1.
- Poprawki udostępniono w wersjach 1.30.0 i 2.2.0.
- Luka może umożliwić przejęcie danych OAuth, w tym client_secret, authorization code i code_verifier.
- Na dzień 29 września 2026 r. podatność nie ma publicznie przypisanego identyfikatora CVE.
Kontekst / historia
Model Context Protocol to otwarty standard zaprojektowany do łączenia aplikacji AI z narzędziami, usługami i zewnętrznymi źródłami danych. Wraz z szybkim wzrostem popularności agentów AI oraz architektur opartych na automatycznych integracjach, komponenty implementujące MCP stały się istotnym elementem łańcucha zaufania.
Publiczne ujawnienie problemu nastąpiło 28 września 2026 r. w advisory bezpieczeństwa. Choć mechanizmy ograniczające ryzyko znalazły się wcześniej w nowszych wydaniach pakietu, początkowo były opisywane bardziej jako zmiana zachowania niż pełnoprawna poprawka bezpieczeństwa. Badacze pokazali jednak, iż w określonych warunkach możliwe jest przechwycenie danych potrzebnych do uzyskania legalnego tokenu dostępowego wobec prawdziwego serwera autoryzacji.
Analiza techniczna
Źródłem problemu była niewystarczająca walidacja tożsamości serwera autoryzacji wskazywanego w przepływie OAuth. W podatnych wersjach klient MCP nie sprawdzał konsekwentnie pola issuer we wszystkich ścieżkach odkrywania metadanych OAuth. Dodatkowo zapisane lub wcześniej dostarczone poświadczenia klienta nie były jednoznacznie związane z adekwatnym serwerem autoryzacji.
To otwierało drogę do scenariusza, w którym złośliwy serwer MCP mógł wpłynąć na to, gdzie klient wyśle poufne dane. Atak mógł przebiegać przez wskazanie własnego serwera autoryzacji w metadanych zasobu chronionego albo przez podstawienie metadanych deklarujących prawidłowego wystawcę, ale kierujących klienta do kontrolowanego endpointu tokenowego.
Najgroźniejszy aspekt tej luki polega na tym, iż wyciek mógł obejmować nie tylko client_secret, ale również authorization code oraz code_verifier. W efekcie mechanizm PKCE, który normalnie ogranicza ryzyko wykorzystania przechwyconego kodu autoryzacyjnego, przestaje zapewniać skuteczną ochronę, jeżeli atakujący uzyska oba elementy jednocześnie. W niektórych wariantach zagrożenie mogło objąć także podpisane asercje klienta.
Problem dotyczył aplikacji używających SDK jako klienta MCP po HTTP z providerami OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider oraz starszym RFC7523OAuthClientProvider w linii 1.x. Nie obejmuje on natomiast serwerów MCP zbudowanych na tym SDK, klientów stdio ani wdrożeń, które samodzielnie przekazują gotowe tokeny lub nagłówki uwierzytelniające.
W poprawionych wersjach zaostrzono walidację oczekiwanego issuer, odrzucanie niespójnych metadanych oraz powiązanie danych klienta z konkretnym serwerem autoryzacji. Jednocześnie część wdrożeń wymaga także dodatkowej, manualnej konfiguracji parametru issuer, aby w pełni ograniczyć ryzyko.
Konsekwencje / ryzyko
Najważniejszą konsekwencją jest możliwość uzyskania przez atakującego ważnego tokenu dostępowego do rzeczywistej usługi, z uprawnieniami nadanymi aplikacji. o ile wycieknie długowieczny sekret klienta, ryzyko nie ogranicza się do pojedynczej sesji i może utrzymywać się do czasu jego rotacji.
Z perspektywy organizacji oznacza to potencjalny dostęp do danych biznesowych, interfejsów API, operacji administracyjnych oraz innych zasobów objętych federacją tożsamości. Szczególnie niebezpieczne są środowiska, w których klient MCP łączy się z serwerami spoza ścisłej domeny zaufania, zwłaszcza w architekturach agentowych oraz zautomatyzowanych platformach integracyjnych.
Wariant interaktywny jest dodatkowo trudny do wykrycia, ponieważ użytkownik może przez cały czas widzieć poprawny ekran logowania. Zewnętrznie proces wygląda wiarygodnie, podczas gdy w tle krytyczne dane trafiają do niewłaściwego odbiorcy. To klasyczny przykład naruszenia granicy zaufania na etapie discovery i walidacji metadanych.
Rekomendacje
Organizacje korzystające z MCP Python SDK powinny jak najszybciej ustalić, czy używają podatnych wersji biblioteki po stronie klienta i czy realizują połączenia HTTP do serwerów MCP, których nie kontrolują w pełni. Następnie należy przeprowadzić aktualizację do wersji 1.30.0, 2.2.0 lub nowszej.
- Zweryfikować wszystkie wdrożenia wykorzystujące podatne wersje SDK.
- Zaktualizować bibliotekę do bezpiecznej wersji.
- Jawnie ustawić parametr issuer dla ClientCredentialsOAuthProvider i PrivateKeyJWTOAuthProvider.
- Wycofać użycie przestarzałego RFC7523OAuthClientProvider.
- Usunąć stare dane rejestracji klienta OAuth, jeżeli nie były powiązane z wystawcą.
- Przeprowadzić rotację client_secret oraz unieważnić potencjalnie zagrożone tokeny.
- Przeanalizować logi pod kątem nietypowych żądań i podejrzanych przepływów OAuth.
- Ograniczyć zaufanie do zewnętrznych serwerów MCP poprzez listy dozwolonych endpointów i dodatkowe monitorowanie.
Podsumowanie
Ujawniona luka w oficjalnym MCP Python SDK pokazuje, iż bezpieczeństwo integracji agentowych zależy nie tylko od poprawnej implementacji OAuth, ale również od ścisłej kontroli metadanych oraz granic zaufania między klientem a serwerem. choćby pozornie pomocnicza warstwa discovery może stać się krytycznym punktem przejęcia poświadczeń.
Dla zespołów bezpieczeństwa i programistów to wyraźny sygnał, iż komponenty AI oraz biblioteki integracyjne powinny być traktowane z taką samą ostrożnością jak systemy IAM, bramki API czy moduły odpowiedzialne za federację tożsamości. Priorytetem pozostają szybka aktualizacja, poprawna konfiguracja i przegląd wszystkich relacji zaufania.
Źródła
- https://thehackernews.com/2026/09/official-mcp-python-sdk-flaw-can-let.html
- https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-qx49-fqc8-xw99
- https://github.com/modelcontextprotocol/python-sdk/security/advisories
- https://github.com/modelcontextprotocol/python-sdk/releases
- https://github.com/modelcontextprotocol/python-sdk
