Poprawka, którą trzeba włączyć

Oficjalne SDK Model Context Protocol dla Pythona opublikowało jednego dnia trzy advisory, po jednym wydaniu z poprawkami na każdej z dwóch gałęzi i zdanie, które powinno zmienić sposób czytania każdego changelogu: sama aktualizacja niczego nie zmienia. Stoi ono pod tym z trzech błędów, który pilnuje drzwi wejściowych serwera MCP.

Trzy decyzje, których nikt nie podjął

Gdy położy się te trzy advisory obok siebie, same błędy nie są najciekawsze. Najciekawsze jest to, kto o czym decydował. Klient, sprawdzając wyniki narzędzi, poprosił bibliotekę JSON Schema o rozwiązanie odwołań, a jej domyślną odpowiedzią było otwarcie dowolnego adresu wskazanego przez serwer, łącznie z lokalnymi plikami. Transporty HTTP dla wygody włączyły podążanie za przekierowaniami, więc nagłówek z danymi dostępowymi szedł tam, gdzie wskazało przekierowanie. Sprawdzanie tokenu po stronie serwera oddano temu, kto napisał weryfikator, i nic nie zmuszało go do sprawdzenia, czy token w ogóle był przeznaczony dla tego serwera.

Nie ma w tym nic egzotycznego. Tak to wygląda, gdy decyzje bezpieczeństwa protokołu zapadają wewnątrz SDK, jedno ustawienie domyślne po drugim. Na MCP można budować, nigdy nie zaglądając do specyfikacji. Czyta się quickstart, a ustawienia domyślne SDK stają się protokołem, który faktycznie działa.

Metadane serwera to dane wejściowe

Błąd ze schematem zasługuje na osobny akapit, bo odwraca typowy obraz. Opis i schemat narzędzia traktujemy zwykle jak konfigurację, do której klient tylko zagląda. Tutaj klient potraktował go jak polecenie do wykonania: idź i pobierz to. Złośliwy serwer nie potrzebował prompt injection ani zdezorientowanego modelu. Wystarczyło, że zadeklarował narzędzie. Wszystko, co wysyła serwer, to dane wejściowe, także to, co wygląda jak dokumentacja.

Numer wersji to nie stan bezpieczeństwa

Dwie poprawki zaczynają działać, gdy pakiet się zmieni. Poprawka audience nie, i to z uzasadnionego powodu: jej włączenie psuje każdy weryfikator, który nie zwraca audience tokenu, więc opiekunowie zrobili ją opcjonalną, a zmianę ustawienia domyślnego odłożyli do następnego wydania głównego. Oto co dostaje serwer, który się zaktualizował i niczego nie zmienił, zamiast samej kontroli:

`AuthSettings.validate_token_resource` is not set, so bearer
tokens are not checked against `resource_server_url`; it will
default to True in 3.0 when `resource_server_url` is set.

To uczciwe ostrzeżenie, tyle że napisane dla programisty patrzącego w konsolę. Skaner zależności czyta numery wersji. Oznaczy pakiet jako naprawiony, zgłoszenie zostanie zamknięte, a serwer, który przyjmuje tokeny wydane dla innych Twoich usług, będzie je przyjmował dalej. Nie dlatego, że ktoś pominął poprawkę, tylko dlatego, że poprawka jest ustawieniem, a ustawienie nie ma właściciela.

Zaufanie to powierzchnia ataku

SDK wygląda jak instalacja wodna, a instalację dziedziczy się bez obaw. Jest odwrotnie: to tam, po cichu i przez ustawienia domyślne, zapadają decyzje o zaufaniu w protokole. W tym tygodniu trzy z nich okazały się błędne. Dwie poprawiono za Ciebie. Jedną poprawiono i zostawiono Tobie do włączenia.

Co konkretnie zrobić

• Zaktualizuj pakiet mcp na każdym kliencie i serwerze. To zamyka błędy przekierowań i schematów bez zmian w kodzie.
• Potem przejrzyj każde miejsce, w którym tworzysz AuthSettings. Albo włącz validate_token_resource i niech weryfikator zwraca audience, albo upewnij się, że weryfikator już odrzuca token, którego aud nie wskazuje Twojego serwera. Bez jednego z tych kroków błąd zostaje otwarty także w nowej wersji.
• Traktuj DeprecationWarning z biblioteki uwierzytelniania jak znalezisko. Pokazuj ostrzeżenia w CI i przerywaj build na tych, które dotyczą ustawień bezpieczeństwa.
• Przestań podążać za przekierowaniami, których nie planowałeś. Jeśli klient łączył się z serwerem przez przekierowanie na inny host, wskaż mu właściwy adres i wymień dane dostępowe, które przy tym przenosił.
• Czytaj schematy narzędzi jak niezaufane dane. Każdy kod, który rozwiązuje, wyświetla lub wykonuje to, co serwer MCP deklaruje o sobie, powinien zakładać, że serwer jest wrogi, bo czasem jest.