RCE 'zgodne z projektem' w MCP: gdy dostawca mówi, że luka to funkcja

Istnieje konkretny rodzaj odkrycia w bezpieczeństwie, który łamie zwykły rytuał. Normalnie badacz ujawnia, dostawca potwierdza, łatka wychodzi, wszyscy aktualizują, CVE się zamyka. Cykl ma kształt, a ten kształt kończy się poprawką. Luka, którą OX Security ujawnił w oficjalnych SDK Model Context Protocol od Anthropic, takiego kształtu nie ma. Badacze znaleźli ścieżkę zdalnego wykonania kodu przebiegającą przez SDK, które zasilają agentów w Pythonie, TypeScripcie, Javie i Ruście. Anthropic potwierdził to zachowanie. A potem, zamiast łatki, wróciła odpowiedź: to zgodne z projektem. Sanityzacja jest obowiązkiem dewelopera. Nie ma CVE do zamknięcia, bo — według dostawcy — nic nie jest zepsute.

To paradoks, przy którym warto się zatrzymać. Szeroki zarys tego problemu omawialiśmy wcześniej w MCP in 2026: The Universal Standard — and Its Security Problem, gdzie argument brzmiał: standardowa wtyczka jest rozwiązana, ale bezpieczeństwo tego, co podłączasz, pozostaje szeroko otwarte. Ten wpis to sequel skupiony na konkretnym incydencie. Wcześniejszy tekst ostrzegał przed ekosystemem; ten dotyczy SDK w jego centrum i tego, co oznacza, gdy najpoważniejsza wada protokołu zostaje przeklasyfikowana — przez tych, którzy są właścicielami protokołu — na zachowanie zamierzone.

Mechanizm: od konfiguracji do polecenia, bez bramki pomiędzy

Żeby zrozumieć, dlaczego “zgodne z projektem” jest jednocześnie technicznie do obrony i operacyjnie przerażające, trzeba spojrzeć, jak działa transport STDIO w MCP. Serwery MCP mogą działać jako procesy lokalne. Gdy agent łączy się z takim przez STDIO, uruchamia serwer, wykonując polecenie — plik binarny, interpreter, skrypt — z argumentami, wszystkie odczytane z konfiguracji. Ta konfiguracja to po prostu dane: blob w stylu JSON mówiący “żeby uruchomić ten serwer, wykonaj to polecenie z tymi argumentami”.

Wada, jak opisują ją OX Security i późniejsza analiza Zealynx Security (“Anthropic MCP SDK Vulnerability Full Analysis”, maj 2026), polega na tym, że pole polecenia jest brane za dobrą monetę i wykonywane na hoście. Jeśli cokolwiek, na co może wpłynąć atakujący, trafi do tego pola — konfiguracja pobrana ze zdalnego źródła, wartość wstawiona z danych użytkownika, wpis serwera ściągnięty z marketplace’u — to atakujący wybiera, co uruchomi się na maszynie. Agent nie musi nawet pomyślnie zainicjalizować poprawnego serwera MCP. Kod wykonuje się już podczas próby. Nie ma walidującej bramki między “oto konfiguracja” a “oto proces działający z twoimi uprawnieniami”.

Dlatego Anthropic może nazwać to zgodnym z projektem. SDK robi dokładnie to, co deklaruje: uruchamia polecenie, które skonfigurujesz. Biblioteka nie jest, w ich ujęciu, miejscem, w którym należy wyłapać niezaufane dane wejściowe. Wyłapanie ma nastąpić wyżej, w aplikacji, przez dewelopera. Technicznie spójne. Praktycznie oznacza to, że najgroźniejsza operacja w całym stosie — dowolne wykonanie polecenia — jest strzeżona przez nic poza założeniem, że każdy z milionów deweloperów w dole łańcucha poprawnie sanityzuje każdą ścieżkę, która może dotrzeć do pola konfiguracji.

Cztery rodziny ataków

Ujawnienie i towarzyszące mu opracowania (SuperML.dev MCP’s Security Debt Just Came Due oraz DevOps Daily “The MCP Design Flaw That Exposes 150M Downloads to RCE”) grupują praktyczną eksploatację w mniej więcej cztery rodziny:

Nieuwierzytelniony wstrzyk przez UI. Wiele narzędzi z obsługą MCP udostępnia lokalny interfejs — panel, widok webowy, powierzchnię sterującą — który przyjmuje konfigurację serwera bez uwierzytelnienia pytającego. Atakujący, który dosięgnie tej powierzchni, może zarejestrować serwer z wrogim polem polecenia i sprawić, że zostanie wykonane, bez żadnych poświadczeń.
Obejścia sanityzacji. Tam, gdzie deweloperzy próbowali filtrować pole polecenia, filtry były płytkie. Sztuczki z kodowaniem, dzielenie argumentów i nadużycia funkcji powłoki przepuszczały złośliwe ładunki przez naiwne listy dozwolonych i zabronionych. Niedokończona osłona to gorszy sygnał niż jej brak, bo wygląda, jakby problem został załatwiony.
Zero-click prompt injection. To ten, który powinien najbardziej martwić operatorów agentów. Zatruty opis narzędzia lub złośliwy dokument, wchłonięty przez agenta działającego w IDE lub w zautomatyzowanym potoku, może pokierować model do zarejestrowania lub wywołania serwera, którego pole polecenia niesie ładunek — bez żadnego kliknięcia człowieka. Wstrzyk jedzie na własnej autonomii agenta. W tej klasie raportowano skuteczność zatruwania narzędzi powyżej 60% wobec głównych agentów LLM.
Złośliwe marketplace’y i dystrybucja. Wraz ze wzrostem ekosystemu rosły rejestry i marketplace’y dystrybuujące definicje serwerów. Wrogi lub przejęty wpis może dostarczyć pole polecenia, które kompromituje każdy host go instalujący — kompromitacja łańcucha dostaw z własnymi kanałami dystrybucji protokołu jako mechanizmem dostawy. Ujęcie OX Security w ich tekście z kwietnia 2026 “The Mother of All AI Supply Chains” nie jest przesadą, biorąc pod uwagę zasięg.

Promień rażenia

To liczby przesuwają tę sprawę z błędu do zdarzenia systemowego. Wspomniane SDK mają ponad 150 mln pobrań. Skan OX Security zidentyfikował około 7000 publicznie wystawionych serwerów MCP i szacowane 200 000 podatnych instancji w środowisku produkcyjnym. Złożono ponad dziesięć CVE w dole łańcucha, gdy odkrycie propagowało się przez zależne projekty — CVE-2026-30615, -30617, -30618 i inne w tej sekwencji — mimo że samo źródłowe zachowanie w SDK nie ma łatki, bo dostawca nie uważa go za defekt.

Zatrzymaj się przy luce w zarządzaniu, która tu się otwiera. CVE jest między innymi artefaktem odpowiedzialności: nazywa defekt, przypisuje mu wagę i tworzy oczekiwanie, że ktoś go naprawi. Gdy dostawca ogłasza, że przyczyna źródłowa jest zamierzona, łańcuch odpowiedzialności zostaje przecięty u góry i przyczepiony na stałe na dole — do każdego pojedynczego dewelopera integrującego SDK. Odpowiedzialność nie znika. Jest rozdystrybuowana, po cichu, na ludzi z ponad 150 mln pobrań, którzy w większości nie wiedzą, że ją odziedziczyli. To ta sama dynamika, którą prześledziliśmy w The $100 Billion Guardrail: praca nad bezpieczeństwem nie znika, gdy platforma odmawia jej wykonania; przesuwa się po prostu w dół łańcucha i staje się czyimś centrum kosztów. Tu ten ruch jest jawny. Dostawca wskazał właściciela problemu, a właścicielem jesteś ty.

Dlaczego to szansa dla Azji Południowo-Wschodniej, nie tylko ryzyko

Jeśli specyfikacja nie wyłapie niezaufanych danych, zanim staną się poleceniem, to ktoś musi zbudować warstwę, która to zrobi — listę dozwolonych poleceń MCP, walidator konfiguracji, monitor rejestracji. I oto część istotna dla zespołu o niskim kapitale w Phnom Penh, Da Nang czy Cebu: zbudowanie tej warstwy nie wymaga GPU, treningów ani centrum danych. Wymaga zrozumienia protokołu, audytu powierzchni, na których konfiguracja dociera do wykonania, i napisania zdyscyplinowanej walidacji. To inżynieria, nie kapitał.

To ta sama szansa, o którą argumentowaliśmy wielokrotnie. Zespół, który potrafi wziąć wdrożenie MCP i wyprodukować jego utwardzoną, zaudytowaną wersję z listą dozwolonych — taką, która egzekwuje to, czego SDK odmawia — buduje broniące się IP z umiejętności, a nie z wydatków. Dostawca na stałe oddelegował poprawkę w dół łańcucha; ta delegacja to rynek. Granica, którą byś egzekwował, to dokładnie praca strażnika-jako-granicy-zgodności, zastosowana przy najgroźniejszej operacji w stosie agenta. I łączy się naturalnie z dyscypliną izolacji z Sandboxing the Agent — lista dozwolonych decyduje, co może się uruchomić, a piaskownica ogranicza, dokąd sięgnie szkoda, gdy coś jednak prześliźnie się przez listę. Obrona, jak ujęliśmy to w Defense in the Loop, musi siedzieć w środku zadania, między konfiguracją a poleceniem, a nie być doczepiona po fakcie.

Co operatorzy muszą zrobić dziś

Stanowisko dostawcy oznacza, że odpowiedzialność jest teraz, jednoznacznie, operacyjna. Konkretnie:

Waliduj każdą konfigurację serwera MCP przed jej załadowaniem. Traktuj pole polecenia jako uprzywilejowaną operację, którą jest. Powinno to być znaną, stałą ścieżką do pliku binarnego, a nie wartością montowaną w czasie działania.
Egzekwuj listę dozwolonych poleceń. Agentowi wolno uruchamiać tylko jawny, zaudytowany zestaw poleceń serwerów. Cokolwiek spoza listy się nie uruchamia. To jest warstwa, której SDK ci nie da, więc ją budujesz.
Nigdy nie przekazuj niezaufanych danych użytkownika do pola konfiguracji STDIO. Żadnego szablonowania, żadnej interpolacji stringów, żadnej “wygodnej” ścieżki pozwalającej, by treść żądania, pobrany dokument czy wpis z marketplace’u dotarły do polecenia. Jeśli dane wejściowe mają wpływać na zachowanie, prowadź je przez zwalidowane parametry, nigdy przez sam plik wykonywalny.
Monitoruj nieoczekiwane rejestracje MCP. Nowy serwer pojawiający się w konfiguracji agenta, którego nikt nie wdrożył, to incydent, nie ciekawostka. Alarmuj na to. Zero-click injection działa właśnie dlatego, że rejestracja jest cicha.
Umieść procesy serwerów w piaskownicy. Załóż, że lista dozwolonych zostanie w końcu obejdzie, i ogranicz promień rażenia izolacją, najmniejszymi uprawnieniami i kontrolą ruchu wychodzącego z sieci.

MCP rozwiązał, jak agenci łączą się z narzędziami, i było to realne osiągnięcie. Ale dostawca wytyczył teraz wyraźną linię: SDK uruchamia to, co mu każesz uruchomić, a wyłapanie tego, czego nie powinno się mu kazać, to twoja robota — na zawsze. To nie jest stan tymczasowy w oczekiwaniu na łatkę. To trwały kontrakt. Zespoły, które to zinternalizują — i zbudują listę dozwolonych, której odmówiła specyfikacja — to te, które mogą używać MCP bez dziedziczenia jego najgorszego CVE z automatu.