Przez ostatnie wpisy cyberflux opisywał CVE w ekosystemie MCP jedno po drugim. Path traversal w mcp-server-git Anthropic, zdalne wykonanie kodu w serwerze Figma MCP, wstrzykiwanie kodu w Orval MCP. Brak uwierzytelnienia w Azure MCP Server z wynikiem CVSS 9.1. Trzydzieści CVE w sześćdziesiąt dni.
15 kwietnia 2026 roku firma OX Security opublikowała raport, który zmienia sposób czytania całej tej listy. Tamte podatności nie były zbiegiem okoliczności ani przypadkowym skupieniem błędów implementacyjnych. Były objawem jednej wspólnej przyczyny siedzącej w rdzeniu protokołu — przyczyny, o której Anthropic wiedział i którą świadomie zdecydował się nie naprawiać.
Pięć miesięcy badań, trzydzieści ujawnień, jeden wniosek
Badacze OX Security — Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok i Roni Bar — rozpoczęli pracę w listopadzie 2025 roku. Przez pięć miesięcy przeprowadzili ponad trzydzieści procesów odpowiedzialnego ujawniania podatności. Wyniki: ponad dziesięć CVE oznaczonych jako krytyczne lub wysokie w popularnych narzędziach AI, demonstracja aktywnej eksploitacji na sześciu platformach produkcyjnych z prawdziwymi klientami, zatrucie dziewięciu z jedenastu badanych katalogów serwerów MCP.
Raport nosi tytuł "Matka wszystkich łańcuchów dostaw AI" — i trudno temu tytułowi odmówić trafności.
Ale najważniejsze zdanie w całym dokumencie nie dotyczy konkretnej podatności. Dotyczy odpowiedzi Anthropic na wielokrotne prośby o naprawę podstawowego problemu: "Anthropic odmówił modyfikacji architektury protokołu, powołując się na to że zachowanie jest oczekiwane."
Gdzie siedzi problem
MCP używa interfejsu STDIO — standardowego wejścia/wyjścia — jako lokalnego mechanizmu transportu, przez który aplikacja AI uruchamia serwer MCP jako podproces. Mechanizm jest zaprojektowany tak, żeby przyjąć polecenie, uruchomić je jako proces i zwrócić uchwyt do komunikacji.
Problem polega na tym, że w praktyce oznacza to: przyjąć dowolne polecenie systemowe, uruchomić je, a jeśli nie powiedzie się jako serwer STDIO — zwrócić błąd po wykonaniu. To subtelne, ale konsekwencje są poważne: interfejs, który miał uruchamiać serwery MCP, uruchamia dowolne polecenia operacyjne.
Podatność działa we wszystkich językach programowania obsługiwanych przez oficjalny zestaw programistyczny MCP Anthropic: Python, TypeScript, Java, Kotlin, C#, Go, Ruby, Swift, PHP i Rust. Każdy deweloper budujący na fundamencie MCP dziedziczy tę ekspozycję automatycznie — bez żadnego własnego błędu implementacyjnego. To jest właśnie to co odróżnia tę historię od wszystkich poprzednich CVE w ekosystemie MCP: tamte dotyczyły konkretnych implementacji. Ten dotyczy protokołu.
Cztery klasy podatności z jednego źródła
OX Security zidentyfikował cztery odrębne wzorce eksploitacji wynikające z tego samego błędu architektonicznego.
Pierwsze: wstrzykiwanie poleceń bez uwierzytelnienia. Każda platforma AI z publicznie dostępnym interfejsem użytkownika jest podatna. Atakujący wpisuje kontrolowane przez siebie polecenie, które wykonuje się bezpośrednio na serwerze bez uwierzytelnienia i bez oczyszczania danych. OX demonstrowało ten wektor na LangFlow — platformie IBM do budowania aplikacji AI z ponad 900 publicznie dostępnymi instancjami według danych Shodan. Token sesji jest dostępny dla każdego nieuwierzytelnionego odwiedzającego. Badacze użyli go do przesłania złośliwej konfiguracji STDIO i przejęcia serwera produkcyjnego.
Drugie: obejście zabezpieczeń w platformach, które próbowały się bronić. Upsonic i Flowise zaimplementowały własne mechanizmy ochrony — zezwalając tylko na określone polecenia jak "python", "npm" czy "npx". W teorii powinno to uniemożliwić bezpośrednie wstrzyknięcie. W praktyce OX ominęło te zabezpieczenia przez wstrzyknięcie polecenia jako argumentu dozwolonego procesu: npx -c <polecenie>. Dozwolone polecenie uruchamia się i wykonuje złośliwy kod w swoim kontekście.
Trzecie: zero-click przez środowiska programistyczne. Windsurf, Claude Code, Cursor, Gemini-CLI, GitHub Copilot — wszystkie podatne na wstrzyknięcie przez monit wpływające bezpośrednio na konfigurację JSON serwera MCP bez interakcji użytkownika. Jedyne CVE za tę klasę ataków dostał Windsurf (CVE-2026-30615), bo jako jedyny potwierdził że to prawdziwy błąd wymagający naprawy. Google, Microsoft i Anthropic odpowiedzieli że to "znany problem" lub "nie jest podatnością bo wymaga jawnej zgody użytkownika na modyfikację pliku."
Czwarte: zatrucie katalogów serwerów MCP. OX zatruło dziewięć z jedenastu badanych katalogów, przesyłając złośliwy serwer MCP jako demonstrację możliwości. Katalogi, które przyjęły zgłoszenie, mają setki tysięcy miesięcznych odwiedzających. Jeden złośliwy wpis może trafić do tysięcy instalacji deweloperów przed wykryciem, dając atakującemu zdalne wykonanie kodu na każdej z nich.
150 milionów pobrań, 200 tysięcy serwerów
Skala ekspozycji wynikająca z jednej decyzji architektonicznej jest trudna do ogarnięcia. OX szacuje łączną liczbę pobrań pakietów MCP na ponad 150 milionów. Liczba publicznie dostępnych serwerów MCP to około 7 tysięcy, ale liczba potencjalnie podatnych instancji — uwzględniając wdrożenia lokalne i prywatne — sięga 200 tysięcy.
Dziesięć CVE oznaczonych jako krytyczne lub wysokie, które OX zidentyfikowało do tej pory, to tylko te, które udało się przypisać do konkretnych narzędzi i dla których znalazł się opiekun gotowy przyznać błąd. Rzeczywista powierzchnia ataku jest szersza — obejmuje każde narzędzie zbudowane na STDIO bez dodatkowej warstwy ochrony, niezależnie od tego czy dostało własny identyfikator CVE.
"Oczekiwane zachowanie" i co to znaczy
Tydzień po pierwszym zgłoszeniu OX, Anthropic cicho zaktualizował politykę bezpieczeństwa. Nowe wytyczne zalecają ostrożność przy adapterach STDIO. Komentarz badaczy OX jest krótki i precyzyjny: "Ta zmiana niczego nie naprawiła."
Stanowisko Anthropic — że zachowanie jest oczekiwane i odpowiedzialność za oczyszczanie danych spoczywa na deweloperach — jest pozycją, którą można zrozumieć z perspektywy projektanta protokołu ogólnego przeznaczenia. STDIO jest standardowym mechanizmem, który z założenia wykonuje podane procesy. Twórca protokołu może argumentować, że walidacja danych wejściowych jest obowiązkiem każdej implementacji, nie samego protokołu.
Ale OX kontrargumentuje na poziomie rzeczywistości, nie teorii: kiedy jeden błąd architektoniczny generuje dziesięć CVE w produktach firm takich jak IBM, Microsoft i Google — i kiedy badacze mogą zainfekować dziewięć z jedenastu katalogów dystrybucji złośliwym serwerem — pytanie o to czy zachowanie jest technicznie "oczekiwane" staje się drugorzędne wobec pytania o skutki tego zachowania w praktyce.
OX ujmuje to bezpośrednio: "Jedna zmiana architektoniczna na poziomie protokołu chroniłaby każdy projekt pochodny, każdego dewelopera i każdego użytkownika końcowego polegającego dziś na MCP. To właśnie oznacza posiadanie stosu."
Łącznik z poprzednimi wpisami cyberflux
Przez ostatnie miesiące pisaliśmy o kolejnych CVE w ekosystemie MCP traktując je jako serię niezależnych incydentów. CVE-2026-32211 w Azure MCP Server z brakiem uwierzytelnienia jako decyzja implementacyjna Microsoftu. CVE w mcp-server-git Anthropic, Figma MCP i Orval MCP jako błędy ich twórców.
Raport OX Security pokazuje że te incydenty mają wspólny mianownik. Nie każdy z nich wynika bezpośrednio z błędu STDIO — ale wszystkie są przejawem tej samej strukturalnej cechy ekosystemu MCP: protokół jest zaprojektowany z założeniem że deweloperzy implementują walidację i zabezpieczenia po swojej stronie, bez mechanizmów wymuszających to na poziomie samego protokołu.
Pisaliśmy o tym przy okazji WordPress 7.0 i natywnej integracji z MCP — platforma zasilająca 40% sieci adoptuje protokół, którego ekosystem ma trzydzieści CVE w sześćdziesiąt dni. Raport OX dodaje do tego obrazu: część z tych CVE wynika nie z niedopatrzeń implementatorów, lecz z decyzji projektowej twórcy protokołu.
Warto też sięgnąć do wcześniejszego wpisu o permission injection przy Bedrock — tam opisywaliśmy jak agent dostaje dostęp do zasobów bo nikt nie przemyślał granic uprawnień. STDIO jako mechanizm wykonania dowolnych poleceń to ta sama klasa problemu, tylko na poziomie niżej: nie uprawnień do zasobów, lecz samego wykonania kodu.
Flowise: ta sama platforma, dwa razy
Jest jeden szczegół w raporcie OX, który warto wyciągnąć osobno. Flowise pojawia się zarówno jako przykład podatności na wstrzyknięcie bez uwierzytelnienia, jak i jako platforma której zabezpieczenia zostały obejścia przez obejście listy dozwolonych poleceń. CVE-2025-59528 który opisywaliśmy wcześniej — podatność z wynikiem CVSS 10.0, aktywnie eksploitowana sześć miesięcy po dostępnej poprawce — to jedna z podatności wynikających z tego samego pierwotnego problemu STDIO.
To nie jest przypadkowe skupienie problemów w jednej platformie. To jest demonstracja że łatanie indywidualnych CVE bez naprawy pierwotnej przyczyny prowadzi do gry w kotka i myszkę między kolejnymi zabezpieczeniami a metodami ich obejścia.
Połączenie ze stored prompt injection
Przy okazji GrafanaGhost opisywaliśmy stored indirect prompt injection — złośliwą treść przechowywaną w danych, którą agent przetwarza i która wpływa na jego zachowanie. STDIO jako wektor to inna warstwa tego samego problemu: zamiast wpływać na polecenia agenta, atakujący wpływa na konfigurację jego infrastruktury. Oba podejścia korzystają z tego samego strukturalnego założenia że wejście do agenta pochodzi z zaufanego źródła.
Google DeepMind opisywał sześć klas pułapek webowych dla agentów — raport OX dodaje siódmą klasę, ulokowaną nie na poziomie treści przetwarzanej przez agenta, lecz na poziomie protokołu który go napędza.
Co zrobić
Dla deweloperów budujących na MCP: każda implementacja przyjmująca dane konfiguracyjne serwera STDIO od użytkownika lub z zewnętrznych źródeł powinna traktować te dane jako niezaufane i walidować je z listą dozwolonych wzorców. Podejście oparte na liście dozwolonych wartości — zamiast blokowania znanych złośliwych wzorców — jest jedynym skutecznym mechanizmem obrony przed klasą ataków przez obejście, którą OX zademonstrował na Upsonic i Flowise.
Dla organizacji wdrażających narzędzia AI oparte na MCP: publicznie dostępne instancje bez dodatkowej warstwy uwierzytelnienia są podatne na pierwszą klasę ataków bez żadnych warunków wstępnych. Izolacja sieciowa i wymaganie uwierzytelnienia na poziomie infrastruktury — nie aplikacji — są minimalnymi środkami zaradczymi.
Dla twórców katalogów MCP: dziewięć z jedenastu zatrutych katalogów to nie jest akceptowalny wynik dla infrastruktury dystrybucji narzędzi AI.
Podsumowanie
OX Security zadało pytanie, które w cyberflux też stawialiśmy przez ostatnie wpisy opisując kolejne CVE: czy te incydenty są przypadkowym skupieniem błędów czy objawem głębszego problemu architektonicznego?
Raport odpowiada: głębszego. I dodaje że Anthropic był o tym informowany wielokrotnie i wybrał nienaprawianie.
To jest właśnie różnica między ekosystemem, który uczy się na błędach i takim, który wypycha odpowiedzialność za bezpieczeństwo na każdy węzeł z osobna — licząc na to że gdzieś po drodze ktoś wykona wymagane oczyszczanie danych. Historia ekosystemów otwartego oprogramowania pokazuje konsekwentnie jak ta kalkulacja kończy się w praktyce.
Źródła
The Register — szczegółowy opis badań OX Security i stanowiska Anthropic: https://www.theregister.com/2026/04/16/anthropic_mcp_design_flaw/
OX Security — blog z opisem czterech klas podatności: https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/
Computing — omówienie skali ekspozycji i stanowiska badaczy: https://www.computing.co.uk/news/2026/security/flaw-in-anthropic-s-mcp-putting-200k-servers-at-risk
Cyber Kendra — analiza techniczna z kontekstem LangFlow i LiteLLM: https://www.cyberkendra.com/2026/04/anthropics-mcp-design-flaw-enables.html
