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, że 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 icode_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, że 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 właściwym 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, że 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śli 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, ręcznej 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. Jeżeli 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 nadal 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
issuerdlaClientCredentialsOAuthProvideriPrivateKeyJWTOAuthProvider. - Wycofać użycie przestarzałego
RFC7523OAuthClientProvider. - Usunąć stare dane rejestracji klienta OAuth, jeśli nie były powiązane z wystawcą.
- Przeprowadzić rotację
client_secretoraz 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, że 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. Nawet 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ł, że 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