2026-07-31 · BADANIA · Zespół Offensive Technology

Bezpieczeństwo zdalnych serwerów MCP: co wynika z analizy 19,321 opublikowanych serwerów

Połowa serwerów w oficjalnym rejestrze Model Context Protocol ma charakter zdalny. Pobraliśmy pełną populację opublikowanych serwerów z dnia 31 lipca 2026 r. (19,321 unikalnych serwerów) i przeanalizowaliśmy sposób wdrażania każdego z nich. 50.0% udostępnia zdalny endpoint, czyli adres URL, z którym Twój agent AI łączy się przez sieć, co sprawia, że kod wykonuje się na obcej maszynie, a Ty widzisz tylko zwracane wyniki. Druga połowa, 48.3%, to pakiety lokalne uruchamiane na Twoim własnym sprzęcie, gdzie możesz je przeanalizować. Ten prosty podział to kluczowe pytanie o bezpieczeństwo kryjące się za każdą instalacją MCP: czy dodajesz kontrolowaną przez siebie bibliotekę, czy podłączasz swojego agenta do obcego serwera? Do tego 30.5% serwerów wymaga poświadczeń przed uruchomieniem, a grupa serwerów zdalnych odwołuje się do 7,420 unikalnych hostów zewnętrznych. Żadna z tych liczb nie wskazuje konkretnego serwera, firmy ani osoby. Pokazują one ogólny stan ekosystemu, który większość zespołów wdraża szybciej, niż audytuje.

Czym w rzeczywistości jest zdalny serwer MCP

Model Context Protocol to warstwa integracyjna, która pozwala agentowi AI wywoływać zewnętrzne narzędzia: odczytać zgłoszenie, odpytać bazę danych czy otworzyć pull request. Serwer udostępnia zestaw narzędzi, agent wybiera jedno z nich, przekazuje argumenty i wczytuje odpowiedź z powrotem do swojego kontekstu roboczego. Istnieją dwa sposoby komunikacji z takim serwerem. Serwer lokalny to pakiet w rejestrze npm, PyPI lub obraz OCI, który instalujesz i uruchamiasz samodzielnie, komunikuje się on z agentem przez stdio na Twojej własnej maszynie. Serwer zdalny to adres URL. Twój agent otwiera z nim połączenie, przesyła strumieniowo wywołania narzędzi i odbiera wyniki.

Różnica sprowadza się do granicy zaufania. W przypadku serwera lokalnego kod, zależności i wychodzące połączenia sieciowe znajdują się na sprzęcie, który kontrolujesz i możesz audytować. W przypadku serwera zdalnego kod znajduje się w infrastrukturze operatora. Nie widzisz go, nie możesz zamrozić jego dokładnej wersji za pomocą hasha tak jak w przypadku pakietu, a każdy argument wysłany przez agenta wraz z kontekstem wywołania trafia do tego operatora. Wyniki zwracane przez narzędzie są następnie traktowane przez agenta z takim samym zaufaniem, jak jego własne wnioskowanie. To właśnie ta ścieżka powrotna jest miejscem, gdzie pojawiają się ataki typu tool-poisoning oraz indirect prompt injection.

Jak dostarczane jest 19,321 opublikowanych serwerów

Oto cała populacja w podziale na sposób komunikacji serwera z agentem. Najważniejszym wnioskiem jest udział serwerów zdalnych, ponieważ to w ich przypadku granica zaufania wykracza poza Twoją maszynę.

Warto przedstawić dokładny podział, ponieważ zaokrąglone wartości ukrywają istotny szczegół. Spośród 19,321 serwerów, 8,642 (44.7%) ma wyłącznie charakter zdalny, bez lokalnego pakietu, który można by uruchomić w zamian. Kolejne 1,014 (5.2%) oferuje obie opcje zdalny endpoint i pakiet lokalny, dając możliwość wyboru. 9,323 (48.3%) udostępnia wyłącznie pakiet lokalny, a pozostała część 342 (1.8%) nie zadeklarowała ani pakietu, ani działającego endpointu. Zatem gdy serwer jest zdalny, najczęściej nie oferuje żadnego rozwiązania alternatywnego, korzystanie z niego oznacza zaakceptowanie zewnętrznego endpointu albo całkowitą rezygnację.

Żądanie poświadczeń: jedna trzecia serwerów wymaga Twoich kluczy

Narzędzie odczytujące zgłoszenia na GitHubie lub wysyłające zapytania do systemu observability musi się gdzieś uwierzytelnić, więc żądania poświadczeń są czymś naturalnym. Warto jednak doprecyzować tę liczbę: 30.5% opublikowanych serwerów (5,888 z nich) deklaruje co najmniej jedno poświadczenie o charakterze sekretu, zmienną środowiskową lub nagłówek autoryzacyjny z nazwą zawierającą token taki jak KEY, TOKEN, SECRET, PASSWORD, lub AUTH. W przybliżeniu co trzeci serwer wymaga aktywnych poświadczeń przed wykonaniem jakiejkolwiek akcji.

Zestawienie tego z udziałem serwerów zdalnych wyraźnie zwiększa ryzyko. Przekazując poświadczenia do serwera lokalnego, sekret pozostaje w Twoim środowisku, a narzędzie używa go z Twojej maszyny. Przekazując poświadczenia do serwera zdalnego, przekazujesz je operatorowi lub upoważniasz go do działania w Twoim imieniu. W obu przypadkach operator staje się posiadaczem Twojego klucza. Jeśli taki operator zaniedba kwestię logów lub zostanie przejęty, poświadczenia wygenerowane dla jednego narzędzia trafią w ręce atakującego. Zasada najmniejszych uprawnień (least privilege) jest tu kluczowa, serwer powinien otrzymać token z zakresem ograniczonym wyłącznie do tego, czego wymagają jego narzędzia.

Gdzie w rzeczywistości znajdują się zdalne endpointy

Zdalne serwery nie ograniczają się do kilku zaufanych chmur. 9,656 serwerów ze zdalnym endpointem rozprasza się na 7,420 unikalnych hostów. Długi ogon jest faktem: 98.1% z tych hostów obsługuje dokładnie jeden serwer, co oznacza ogromną liczbę niezależnych operatorów z których każdy jest osobnym podmiotem wymagającym weryfikacji. Gdyby Twoi agenci bezkrytycznie korzystali z całego rejestru, nawiązywaliby połączenia z tysiącami różnych endpointów, z których większość jest prowadzona przez nieznane podmioty.

Na drugim końcu rozkładu znajduje się wysoka koncentracja. Pojedynczy, największy host bramki (gateway) obsługuje 13.5% wszystkich zdalnych serwerów, a dziesięć najbardziej obciążonych hostów odpowiada łącznie za 18.9% zdalnych endpointów. Około jedna czwarta zdalnych serwerów korzysta ze współdzielonego hosta typu multi-tenant zamiast z własnej domeny. To obosieczny miecz każdego rynku usług: kilku agregatorów obsługuje dużą część ruchu, co jest wygodne, ale oznacza również, że pojedynczy operator lub pojedyncza awaria wpływa na znaczną część ekosystemu. Nie podajemy nazw tych hostów, kluczowy jest ogólny profil, a nie konkretny adres.

Zagrożenie, którego nie było: ukryte znaki Unicode

Jedno z dobrze udokumentowanych zagrożeń w MCP polega na ukrywaniu instrukcji dla agenta w publikowanych przez serwer polach tekstowych przy użyciu niewidocznych znaków: punktów kodowych tagów Unicode, łączników o zerowej szerokości, znaków sterujących kierunkiem tekstu czy sekwencji ANSI escape. Agent je odczytuje, a człowiek przeglądający tekst ich nie widzi. Przeprowadziliśmy skanowanie wszystkich pól tekstowych widocznych dla modeli we wszystkich 19,321 serwerach pod kątem obecności tych klas znaków. Wynik jest jednoznaczny: 0 z 19,321 serwerów zawierało znaki niedrukowalne lub służące do ataków typu injection w swoich metadanych w rejestrze.

To dobra wiadomość, jednak z pewnym zastrzeżeniem, które ma istotne znaczenie. Rejestr publikuje nazwę, tytuł i opis serwera, ale nie opisy poszczególnych udostępnianych narzędzi. A to właśnie te pola są ładowane do kontekstu agenta przy każdym wywołaniu i stanowią atrakcyjniejszy cel ataków wykorzystujących ukryte instrukcje. Zerowy wynik oznacza, że sama warstwa metadanych rejestru jest dziś czysta. Nie oznacza to jednak, że czyste są narzędzia kryjące się za tymi serwerami, ponieważ rejestr nie udostępnia tej powierzchni do pasywnej analizy. Uczciwy wniosek jest więc wąski: na poziomie, który możemy zmierzyć bez nawiązywania połączenia z jakimkolwiek serwerem, kanał wykorzystujący niewidoczne znaki nie jest używany.

Spojrzenie na rejestr oczami atakującego

Spójrzmy na te liczby z perspektywy kogoś, kto ocenia skuteczność zabezpieczeń. Atakujący, który chce uzyskać dostęp do organizacji za pośrednictwem narzędzi AI, ma dwa oczywiste scenariusze, a nasz spis pokazuje, że oba są wykonalne na dużą skalę. Pierwszy polega na prowadzeniu własnego serwera: opublikować przydatne narzędzie, doprowadzić do jego instalacji i w pełni legalnie odbierać każde zapytanie wysyłane przez agenta oraz kontrolować każdy wynik, który agent odczytuje. Gdy połowa rejestru ma charakter zdalny, kolejny zdalny serwer nie wzbudza podejrzeń. Drugi scenariusz to przejęcie infrastruktury operatora, który cieszy się już zaufaniem wielu zespołów, a koncentracja w czołówce hostów wskazuje punkt o największej dźwigni.

Statystyki dotyczące poświadczeń stanowią dodatkowy mnożnik ryzyka. Jedna trzecia serwerów ma już dostęp do sekretów, więc zatruty lub przejęty serwer nie ogranicza się tylko do odczytywania ruchu, lecz może posiadać klucze dające dostęp do systemów znajdujących się za narzędziami. To dokładnie to samo rozszerzenie powierzchni ataku, które opisujemy w naszym przewodniku dotyczącym tego, co atakujący mogą w rzeczywistości dowiedzieć się o Twojej firmie, przeniesione o jedną warstwę głębiej: powierzchnią ataku nie są już tylko publiczne rekordy DNS i usługi, ale zestaw zewnętrznych serwerów, z którymi Twoi agenci mogą się komunikować. Każdy z nich stanowi zależność, a to właśnie od zależności zaczynają się współczesne incydenty naruszenia bezpieczeństwa.

Jak utrzymać zdalne serwery MCP pod kontrolą

Nic z tego nie jest argumentem przeciwko zdalnym serwerom MCP. Jest to argument za traktowaniem ich jak zewnętrznych zależności, którymi w rzeczywistości są. Jeśli używasz agentów połączonych z narzędziami MCP, oto lista kluczowych zaleceń.

• Stosuj listę dozwolonych (allow-list) zamiast otwartego rejestru. Określ konkretne serwery, z których agenci mogą korzystać, i zamroź ich wersje. Fakt, że połowa rejestru ma charakter zdalny, oznacza, że w połowie przypadków świadomie obdarzasz zaufaniem zewnętrznego operatora. Rób to celowo, zamiast instalować wszystko, co znajdziesz.
• Wybieraj rozwiązania lokalne, gdy dostępne są obie opcje. W przypadku 5.2% serwerów oferujących zarówno pakiet, jak i endpoint, pakiet lokalny zatrzymuje kod i cały ruch na Twojej maszynie. Wybieraj go, jeśli narzędzie nie musi działać zdalnie.
• Ograniczaj zakres poświadczeń dla każdego narzędzia. Ponieważ 30.5% serwerów wymaga sekretów, generuj tokeny ograniczone wyłącznie do tego, czego wymagają narzędzia danego serwera, dbaj o ich rotację i nigdy nie przekazuj szerokich uprawnień niezaudytowanemu serwerowi.
• Traktuj dane wyjściowe z narzędzi jako niezaufane dane wejściowe. Wyniki zwracane przez serwer mogą zawierać instrukcje skierowane do Twojego agenta. Ogranicz czynności, które agent może z nimi wykonać, i nie pozwól, aby wynik wywołania narzędzia po cichu wywoływał akcje wymagające wysokich uprawnień.
• Wiedz, kto znajduje się po drugiej stronie. Zdalny endpoint wskazuje na czyjegoś hosta. W przypadku serwerów, od których zależysz, musisz znać ich operatora i pamiętać, że większość hostów w tym rejestrze obsługuje tylko jeden serwer prowadzony przez pojedynczy podmiot.

Metodologia, czyli dlaczego można zaufać tym liczbom

Zbiór danych jest nasz własny, zbudowany ze źródeł publicznych i zautomatyzowany wyłącznie w formie zbiorczej. Wysłaliśmy zapytania do publicznego API rejestru Model Context Protocol i pobraliśmy cały katalog w dniu 31 lipca 2026 r., zapisując 62,430 rekordów wersji. Następnie ograniczyliśmy te dane do 19,321 serwerów oznaczonych jako aktualna, najnowsza wersja, co stanowi zdeduplikowaną populację aktywną i mianownik dla wszystkich podanych wartości procentowych. Sposób wdrożenia sklasyfikowano na podstawie zadeklarowanych pakietów i zdalnych endpointów; wskaźnik poświadczeń uwzględnia każdą zadeklarowaną zmienną środowiskową lub nagłówek autoryzacyjny z nazwą zawierającą token o charakterze sekretu; koncentrację hostów obliczono poprzez rozwiązanie nazwy hosta każdego zdalnego endpointu; a skanowanie pod kątem ukrytych znaków sprawdziło każde pole tekstowe pod kątem bloku tagów Unicode, znaków o zerowej szerokości, znaków sterowania kierunkiem tekstu, sekwencji ANSI escape oraz innych znaków kontrolnych i prywatnego użytku.

Odczytaliśmy wyłącznie publiczne API samego rejestru. Nie łączyliśmy się z żadnym ze znajdujących się w nim serwerów, nie wysyłaliśmy zapytań do endpointu żadnego operatora ani nie zbieraliśmy danych o żadnej osobie. Odczyt publicznego katalogu jest działaniem pasywnym, interakcja z hostami już by nim nie była, dlatego tego nie robiliśmy.

Czego te badania nie dowodzą

Liczba bez podania jej ograniczeń to tylko marketing, oto ograniczenia tych badań.

• To tylko jeden rejestr. Oficjalny rejestr jest katalogiem centralnym, ale istnieją serwery, które nigdy do niego nie trafiają, a inne katalogi prowadzą własne spisy. Pomiary te dotyczą opublikowanej, możliwej do wykrycia populacji, a nie każdego istniejącego serwera.
• Dane zadeklarowane, a nie zaobserwowane. Sposób wdrożenia i poświadczenia wynikają z tego, co każdy serwer deklaruje w swoim wpisie w rejestrze. Serwer może wymagać sekretu, którego nie umieścił na liście, lub oferować pakiet, którego w rzeczywistości nie obsługuje. Zmierzyliśmy manifest, a nie aktywną instalację.
• Zdalny charakter to powierzchnia ryzyka, a nie wyrok. Zdalny serwer nie jest niebezpieczny tylko dlatego, że jest zdalny. Wiele z nich jest dobrze zarządzanych przez profesjonalnych operatorów. Wartość 50.0% określa skalę decyzji dotyczącej zaufania, a nie liczbę złośliwych podmiotów.
• Zerowy wynik ma ograniczony zakres. Brak ukrytych znaków dotyczy wyłącznie pól metadanych na poziomie serwera w rejestrze. Opisy poszczególnych narzędzi, które są ładowane do agenta przy każdym wywołaniu, nie są publikowane w sposób umożliwiający pasywny odczyt, więc nie jest to zaświadczenie o pełnym bezpieczeństwie samych narzędzi.
• To tylko migawka stanu z danego momentu. Rejestr rośnie z dnia na dzień. Te dane przedstawiają stan na 31 lipca 2026 r., a nie stały trend, i ponowne pobranie danych w przyszłym miesiącu przyniesie inne wyniki.

Często zadawane pytania

Czy korzystanie ze zdalnych serwerów MCP jest bezpieczne?

Zdalny serwer MCP jest na tyle bezpieczny, na ile bezpieczny jest jego operator, ponieważ Twój agent wysyła zapytania i odczytuje wyniki przez endpoint tego operatora. W tym badaniu 50.0% serwerów miało charakter zdalny i wszystkie używały HTTPS, więc szyfrowanie transmisji nie stanowi problemu. Problemem jest zaufanie. Korzystaj tylko ze sprawdzonych serwerów i przyznawaj im poświadczenia z minimalnymi niezbędnymi uprawnieniami.

Czym różni się lokalny serwer MCP od zdalnego?

Lokalny serwer działa jako pakiet na Twojej własnej maszynie, dzięki czemu możesz przeanalizować jego kod i połączenia sieciowe. Zdalny serwer to adres URL, z którym łączy się agent, więc kod wykonuje się w czyjejś infrastrukturze, a Ty widzisz tylko odpowiedzi. W badaniu 48.3% serwerów miało charakter wyłącznie lokalny, 44.7% wyłącznie zdalny, a 5.2% oferowało obie opcje.

Ile jest serwerów MCP?

Oficjalny rejestr zawierał 19,321 unikalnych opublikowanych serwerów w momencie pobierania pełnej populacji 31 lipca 2026 r. (uwzględniając tylko najnowszą wersję każdego z nich). Rejestr szybko rośnie, więc należy traktować tę liczbę jako historyczną migawkę.

Czy serwery MCP wymagają kluczy API lub poświadczeń?

Wiele z nich wymaga. W badaniu 30.5% serwerów zadeklarowało co najmniej jedno poświadczenie o charakterze sekretu, co oznacza, że w przybliżeniu co trzeci serwer wymaga klucza lub tokena do działania. Zwiększa to promień rażenia (blast radius) w przypadku przejęcia serwera lub jego operatora.

Czy serwer MCP może skraść Twoje dane?

Złośliwy lub przejęty serwer może odczytać każde zapytanie wysłane przez agenta i zwrócić zmodyfikowane wyniki do jego kontekstu, co stanowi podstawę ataków tool-poisoning i prompt-injection. Nie może jednak wyjść poza narzędzia i poświadczenia, które mu przyznasz, dlatego główną linią obrony jest zasada najmniejszych uprawnień oraz audytowana lista dozwolonych serwerów.

Czy rejestr MCP jest weryfikowany pod kątem bezpieczeństwa?

Nie. Wpis w rejestrze to po prostu publikacja, a nie audyt bezpieczeństwa. Rejestr gromadzi informacje o lokalizacji serwera, a nie o tym, czy jego operator jest godny zaufania. Zdalne serwery odwoływały się do 7,420 hostów, z których 98.1% obsługiwało tylko jeden serwer, więc większość łańcucha dostaw stanowią operatorzy, których należałoby weryfikować indywidualnie.

Jakie są zagrożenia związane z bezpieczeństwem serwerów MCP?

Główne zagrożenia to zwracanie zatrutych wyników wywołań narzędzi do agenta, podglądanie i logowanie wszystkich zapytań przez zewnętrznego operatora, ujawnienie poświadczeń, gdy serwer wymaga kluczy, oraz ryzyko koncentracji, gdy wiele serwerów znajduje się za jedną bramką. W tym badaniu egzotyczne techniki, takie jak ukryte znaki Unicode, nie występowały w metadanych rejestru (0 z 19,321), więc bezpośrednim ryzykiem jest kwestia zaufania i dostępu, a nie kodowania znaków.

Warto przeczytać

• Co atakujący mogą w rzeczywistości dowiedzieć się o Twojej firmie? Powierzchnia ataku, którą ten artykuł rozszerza w głąb narzędzi wykorzystywanych przez agentów.
• Czy p=none wystarczy? Ta sama metoda pasywnego pomiaru zastosowana do uwierzytelniania poczty e-mail.
• Najpierw autoryzacja. Dlaczego każdy publikowany przez nas pomiar pozostaje całkowicie zgodny z prawem.