Dzisiejsza seria CVE w serwerach MCP: SSRF i path traversal za narzędziem agenta

9 sierpnia 2026 roku opublikowano serię CVE dotyczących niewielkich serwerów i narzędzi MCP. Powtarzają się dwie klasy błędów: server-side request forgery w funkcjach pobierających URL oraz path traversal w funkcjach zapisujących lub odczytujących dane workspace. Każda luka ma własne warunki, ale wspólny problem jest architektoniczny: argument wygenerowany przez klienta lub agenta staje się adresem sieciowym albo ścieżką systemową bez wystarczającej kontroli granicy.

To ważniejsze niż sam wynik CVSS. Serwer MCP często działa lokalnie i dlatego rekord może otrzymać wektor „local”. Jednocześnie model może wywołać jego narzędzie po przeczytaniu nieufnej strony, dokumentu lub wyniku wyszukiwania. Lokalne API nie jest automatycznie kontrolowane przez człowieka, jeżeli pośrednikiem decyzji jest agent.

Cztery reprezentatywne luki z dzisiejszej publikacji

CVE	Komponent i zakres	Klasa	Status wskazany w źródłach
CVE-2026-19328	Skill Ninja MCP Server 0.1.0	path traversal przez workspacePath	wersja 0.1.1 oznaczona jako niepodatna
CVE-2026-19336	spec-workflow-mcp 2.2.0–2.2.6	path traversal przez categoryName	poprawka w 2.2.7
CVE-2026-19337	mcp-google-search do 0.3.1	SSRF w read_webpage	istnieje commit naprawczy; rekord nie nazywa bezpiecznej wersji
CVE-2026-19339	Alibaba Cloud DataWorks MCP Server 1.0.0–1.0.43	zdalny SSRF przez URI zasobu	rekord nie wskazuje poprawionej wersji

CVE-2026-19328 obejmuje funkcje instalowania, aktualizowania i usuwania skilli oraz modyfikowania AGENTS.md. Manipulacja workspacePath mogła wyprowadzić operację poza oczekiwany projekt. Poprawka 0.1.1 wprowadza zaufane katalogi główne, rozwiązuje ścieżki i odrzuca operacje poza nimi.

CVE-2026-19336 dotyczy nazw kategorii w mechanizmie akceptacji spec-workflow-mcp. Wersja 2.2.7 stosuje kontrolę na dwóch poziomach: handler narzędzia odrzuca separatory i przejście do katalogu nadrzędnego, a warstwa storage używa bezpiecznego łączenia ścieżek. Commit projektu opisuje tę obronę warstwową.

Dwie odmiany SSRF

CVE-2026-19337 znajduje się w narzędziu read_webpage serwera mcp-google-search. Kontrolowany URL mógł skierować żądanie do zasobów, do których ma dostęp host MCP. Commit naprawczy ogranicza protokoły do HTTP/HTTPS, rozwiązuje nazwę DNS, blokuje prywatne, loopback, link-local i multicastowe adresy IPv4/IPv6 oraz wyłącza automatyczne przekierowania.

CVE-2026-19339 dotyczy ReadResourceRequestSchema w Alibaba Cloud DataWorks MCP Server do 1.0.43. Argument request.params.uri prowadzi do SSRF, a rekord klasyfikuje możliwość ataku jako zdalną. CNA nie wskazuje wersji niepodatnej i odnotowuje brak odpowiedzi projektu na wcześniejsze zgłoszenie. To sytuacja, w której ograniczenie egressu i wyłączenie narzędzia do czasu pojawienia się poprawki są równie istotne jak monitorowanie numeru pakietu.

SSRF w narzędziu agenta może sięgnąć do panelu na localhost, usługi w prywatnej sieci, endpointu metadanych chmurowych albo API, które ufa adresowi hosta. To potencjalny wpływ zależny od środowiska; CVE nie potwierdzają, że każdy z tych celów był osiągalny w każdym wdrożeniu.

Dlaczego „lokalny” nie zawsze oznacza „niski priorytet”

W klasycznej aplikacji użytkownik lokalny musi sam wywołać podatną funkcję. W systemie agentowym argument może powstać z kilku kroków:

1. agent pobiera zewnętrzny dokument lub stronę;
2. treść sugeruje użycie narzędzia i dostarcza wartość argumentu;
3. klient MCP wysyła wywołanie do lokalnego serwera;
4. serwer interpretuje wartość jako URL lub ścieżkę o uprawnieniach swojego procesu.

Źródła CVE nie stwierdzają, że taki łańcuch został wykorzystany. Jest to wniosek Breachroad pokazujący, dlaczego kontekst agenta powinien zmieniać priorytetyzację. Model nie jest granicą bezpieczeństwa i nie może zastąpić deterministycznej autoryzacji w implementacji narzędzia.

CVSS opisuje warunki bezpośredniego wywołania podatnego komponentu. Organizacja musi dodać kontekst: kto może wpływać na prompt, czy wywołania są automatyczne, do jakich plików i sieci ma dostęp proces oraz czy potrzebna jest akceptacja człowieka.

Jak bezpiecznie obsługiwać ścieżki

Walidacja ścieżki powinna zaczynać się od jawnego zaufanego katalogu głównego. Aplikacja rozwiązuje zarówno root, jak i kandydata do postaci kanonicznej, a następnie sprawdza zawieranie. Należy uwzględnić separatory Windows i POSIX, ścieżki bezwzględne, dowiązania symboliczne oraz stan wyścigu między sprawdzeniem i użyciem.

Sama kontrola .. nie wystarcza. Dobre rozwiązanie łączy:

• prosty identyfikator zamiast dowolnej ścieżki w schemacie narzędzia;
• allowlistę workspace’ów ustalaną przez operatora, nie model;
• bezpieczne API łączenia i kanonikalizacji;
• minimalne uprawnienia procesu i mounty tylko do potrzebnych katalogów;
• osobną zgodę dla zapisu, usunięcia i modyfikacji plików sterujących agentem.

Jak bezpiecznie obsługiwać URL

Allowlista http i https jest dopiero początkiem. Serwer powinien blokować adresy loopback, prywatne, link-local, multicastowe i inne zakresy specjalne dla IPv4 oraz IPv6, sprawdzać każdy cel przekierowania i kontrolować rozwiązywanie DNS. W środowisku chmurowym dodatkowa polityka egressu powinna uniemożliwiać kontakt z metadanymi i siecią zarządzającą nawet wtedy, gdy walidator aplikacji zawiedzie.

Najbezpieczniejszy interfejs nie przyjmuje dowolnego URL. Może pobierać tylko wynik wcześniej wykonanej operacji wyszukiwania, identyfikator zasobu z konkretnego dostawcy albo domenę z zatwierdzonej listy. Redukcja ekspresyjności narzędzia jest często skuteczniejsza niż rosnąca lista wyjątków.

Jak zbudować rejestr ryzyka narzędzi MCP

Lista nazw serwerów i wersji nie wystarczy, ponieważ to samo narzędzie może mieć zupełnie inny wpływ w dwóch klientach. Dla każdej funkcji zapisz schemat argumentów, dozwolone źródła danych, tożsamość procesu, katalogi, politykę egressu, sekrety, potrzebę akceptacji oraz systemy docelowe. Osobne pole powinno wskazywać, czy odpowiedź narzędzia wraca do kontekstu modelu i może wpłynąć na kolejne wywołanie.

Następnie oznacz efekty: tylko odczyt publicznych danych, odczyt wewnętrzny, zapis w workspace, uruchomienie procesu, zmiana konfiguracji albo operacja administracyjna. „Read” w nazwie nie zawsze oznacza niski wpływ — odczyt URL może wykonywać żądanie z uprzywilejowanej sieci, a odczyt pliku może ujawnić sekret dający możliwość zapisu gdzie indziej. Klasyfikacja musi opisywać realny efekt, nie marketingową nazwę funkcji.

Właścicielem ryzyka powinien być zespół, który decyduje o instalacji i uprawnieniach serwera, a nie sam dostawca modelu. Dostawca MCP odpowiada za poprawkę kodu, ale organizacja odpowiada za to, że proces nie ma niepotrzebnego dostępu do metadanych chmury, katalogu domowego czy klucza produkcyjnego. Rejestr powinien mieć datę przeglądu, ponieważ klienci agentowi i zestawy aktywnych narzędzi zmieniają się szybciej niż typowe aplikacje biznesowe.

Test, który odtwarza rzeczywisty przepływ zaufania

Test jednostkowy handlera z ręcznie przygotowanym JSON-em sprawdza tylko ostatni krok. Scenariusz integracyjny powinien zacząć się od nieufnej treści, przejść przez decyzję modelu, politykę klienta, transport MCP i implementację narzędzia, a zakończyć obserwowalnym efektem w kontrolowanym zasobie. Celem nie jest tworzenie działającego exploita, lecz potwierdzenie, że polityka blokuje niedozwolony URL lub ścieżkę niezależnie od sposobu, w jaki argument trafił do wywołania.

Zespół powinien mierzyć co najmniej decyzję allow/deny, powód, tożsamość runu, udział człowieka oraz zgodność efektu z deklarowanym zakresem. Test negatywny jest równie ważny jak pozytywny: legalna operacja w zatwierdzonym workspace ma działać, natomiast podobna operacja poza rootem musi zostać odrzucona bez częściowego zapisu. Dla URL sprawdza się także zmianę DNS i przekierowanie, ponieważ walidacja tylko pierwszego ciągu nie kontroluje końcowego miejsca połączenia.

Plan dla zespołów używających MCP

1. Wypisz wszystkie serwery MCP, ich wersje, źródła instalacji i narzędzia aktywne w klientach.
2. Zaktualizuj Skill Ninja MCP Server do 0.1.1 i spec-workflow-mcp do 2.2.7 lub nowszych wydań.
3. Dla mcp-google-search potwierdź obecność commita naprawczego w rzeczywiście uruchamianym artefakcie; nie zakładaj tego na podstawie gałęzi repozytorium.
4. Wyłącz lub odizoluj ReadResource w DataWorks MCP do czasu wskazania bezpiecznej wersji przez projekt.
5. Ogranicz egress procesów MCP i dostęp do systemu plików niezależnie od poprawek aplikacyjnych.
6. Loguj nazwę narzędzia, znormalizowany argument, decyzję polityki, użytkownika/agent run i wynik bez zapisywania sekretów.
7. Dodaj akceptację człowieka przy operacjach zapisu, usuwania, instalacji i dostępie do nowych domen.
8. Przetestuj pośredni wpływ nieufnej treści na wywołanie narzędzia, nie tylko ręczne wywołanie poprawnego JSON.

Fakty a wnioski Breachroad

Fakty to dzisiejsza publikacja wymienionych CVE, zakresy wersji i mechanizmy opisane przez CNA oraz konkretne commity dla trzech projektów. Publiczne rekordy nie potwierdzają wspólnej kampanii ani przejęcia konkretnych organizacji.

Wniosek Breachroad: seria jest sygnałem dojrzewania ekosystemu MCP, ale również powtarzalnego długu w implementacji prostych granic. Szkolenia z bezpieczeństwa AI i bezpiecznego developmentu powinny obejmować cały przepływ od nieufnej treści do systemowego efektu. Audyt bezpieczeństwa AI może zmapować serwery, narzędzia, egress, workspace’y, sekrety i punkty wymagające deterministycznej zgody.