Badacz ujawnia tę samą lukę MCP w Google, JPMorgan i dwóch rządach

Niezależny badacz bezpieczeństwa Syed Anas Mohiuddin ujawnił w aktualizacji badawczej z października 2026, że ten sam błąd polegający na ataku typu server‑side request forgery w serwerach Model Context Protocol został potwierdzony i naprawiony przez zespoły bezpieczeństwa pięciu niezależnych organizacji: Google, JPMorgan Chase, Weaviate, francuskiego interministerialnego dyrektoriatu cyfrowego oraz rządu miasta Tangerang w Indonezji.

Aktualizacja, zatytułowana “Protocol Pivoting, four months later”, weryfikuje prognozę Mohiuddina z maja 2026: jeśli słabość ma charakter strukturalny, a nie jest wynikiem pojedynczej nieostrożnej implementacji, ta sama luka pojawi się w serwerach napisanych przez zespoły nie dzielące kodu, branży, kraju ani właściciela. Raportuje, że każda z pięciu organizacji potwierdziła przypadek za pośrednictwem własnego zespołu bezpieczeństwa oraz że dostawca bezpieczeństwa Rapid7 osobno opublikował CVE dotyczące innej, ale powiązanej luki. Aktualizacja zestawia pięć organizacji, które naprawiły tę samą SSRF, dwa opublikowane CVE oraz pięć odkryć w federalnych serwerach MCP w USA, które pozostają otwarte.

Mohiuddin opisuje dwa tryby awarii stojące za tym wzorcem. Pierwszy to server‑side request forgery: serwer MCP konstruuje żądanie wychodzące na podstawie URL, ścieżki lub punktu końcowego dostarczonego przez agenta, nie sprawdzając, dokąd się ono rozwiązuje, więc to agent w praktyce decyduje, z kim tożsamość sieciowa serwera się komunikuje. Drugi to niebezpieczne obchodzenie się z danymi pochodzącymi z góry, najwidoczniej polegające na zapisywaniu pełnych odpowiedzi API do scentralizowanych logów bez redakcji, co zwykłe błędy wystarczają, aby wywołać. Oba tryby wiąże jedno założenie, że dane przekraczające granicę MCP są zaufane, ponieważ pochodzą z wnętrza systemu, co – jak twierdzi – nie ma zastosowania w agentycznym potoku.

CVE‑2026‑14540 w MCP Toolbox firmy Google

Zgodnie z wpisem w bazie advisory GitHub dla CVE‑2026‑14540, opublikowanym przez National Vulnerability Database, w komponentach źródła HTTP i narzędziowych MCP Toolbox Google w wersjach od 0.3.0 do 1.4.0 występuje luka SSRF. Ponieważ klient HTTP nie posiadał restrykcyjnej polityki przekierowań i nigdy nie weryfikował adresów IP docelowych, spreparowany parametr ścieżki mógł przekierować wychodzące żądania toolboxa do wewnętrznych lub dowolnych zewnętrznych punktów końcowych. Advisory ocenia tę lukę jako o wysokiej powadze (High) z wynikiem CVSS 8,0; została opublikowana 31 lipca 2026 r., a ostatnio zaktualizowana 8 sierpnia 2026 r. Mohiuddin podaje, że CVE zostało zarezerwowane 3 lipca 2026 r. i że rekord przyznaje mu status odkrywcy.

Google wprowadziło poprawkę, żądanie scalenia #3448 w repozytorium googleapis/mcp-toolbox, 18 czerwca 2026 r., i została ona udostępniona w mcp-toolbox v1.5.0. Żądanie scalenia implementuje SSRFGuard, aby zapobiec atakom DNS‑rebinding w oknie pomiędzy sprawdzeniem adresu a połączeniem, dodaje konfigurowalne właściwości allowPrivateNetworks, allowedIpRanges i customBlockedIpRanges, weryfikuje skonfigurowany BaseURL podczas inicjalizacji zamiast przy pierwszym żądaniu oraz wyraźnie ostrzega o ryzyku ataku typu man‑in‑the‑middle, gdy weryfikacja SSL jest wyłączona. PR przyznaje Mohiuddina jako zgłaszającego, a Mohiuddin opisuje naprawę Google jako referencyjną implementację rzeczywistego strażnika SSRF.

Cztery kolejne potwierdzone przypadki

Mohiuddin informuje, że otwarto‑źródłowe repozytorium jpmorgan-payments/ai firmy JPMorgan Chase zawiera serwer MCP do przeszukiwania dokumentacji, którego narzędzie read_documentation stosuje listę dozwolonych domen przed pobraniem, podczas gdy pokrewne narzędzie related() pobiera podany przez wywołującego URL po stronie serwera bez żadnych ograniczeń. Stwierdza, że komponent został rozwidłowany z projektu AWS, którego oryginał nigdy nie dereferencjonował URL wywołującego, że zespół ds. odpowiedzialnego ujawniania w banku potwierdził trafność odkrycia oraz że wdrożono poprawkę. Jego nazwisko znajduje się na publicznej stronie uznania odpowiedzialnego ujawniania JPMorgan Chase, a on ocenia odkrycie jako o średniej powadze, zauważając, że żadne poświadczenia nie są przesyłane wraz z sfałszowanym żądaniem.

Weaviate, jak podaje, wprowadziło żądanie scalenia ograniczające ustawienia apiEndpoint, region i location modułu Google do hostów Google API, i wymienia go z imienia i nazwiska w publicznym wpisie Security Hall of Fame z dnia 25 sierpnia 2026 r.

Projekt datagouv/datagouv-mcp wprowadził żądanie scalenia #126, “feat: harden SSRF on external APIs”, 4 września 2026 r., a żądanie scalenia rozpoczyna się od przyznania Mohiuddina jako zgłaszającego. Zgodnie z PR, pole machinedokumentacjaurl dostarczone przez dowolnego zarejestrowanego producenta data.gouv.fr było pobierane po stronie serwera i mogło wskazywać na adresy loopback, prywatnej sieci lub metadane chmury, przy czym DNS‑rebinding mógł zamienić cel pomiędzy sprawdzeniem a połączeniem, a przekierowanie 302 mogło trafić na wewnętrzny host. Poprawka weryfikuje adres IP docelowy w momencie połączenia, ponownie sprawdza każdy przeskok przekierowania i odrzuca proxy. Mohiuddin identyfikuje projekt jako oficjalny serwer MCP dla francuskiej krajowej platformy otwartych danych, utrzymywany przez DINUM, interministerialny dyrektorat cyfrowy rządu.

A Porada bezpieczeństwa GitHub opublikowana 3 września 2026 przez maintainerów INFOKOM-KI/Wazuh-MCP-Server, oceniona jako Wysoki, rejestruje, że reklamowana ochrona przed SSRF w narzędziu blueteamcheckwebshell odrzucała jedynie dosłowne adresy IP i nigdy nie rozwiązywała nazw hostów, więc każda nazwa DNS wskazująca na prywatny, pętlowy lub link‑local adres, w tym metadane instancji w chmurze, omijała tę ochronę. Porada zauważa, że udokumentowane zapewnienie narzędzia, „Ochrona SSRF: Prywatne/zarezerwowane adresy IP w hoście URL są odrzucane”, nie obowiązywało w przypadku URL‑ów opartych na nazwach hostów. Luka została naprawiona w commicie 2bbfe12, a porada przyznaje Mohiuddinaemu rolę zgłaszającego. Mohiuddin twierdzi, że zgłosił to 2 września 2026, że maintainerzy odpowiedzieli z adresu tangerangkota.go.id oraz że projekt jest utrzymywany przez rząd miasta Tangerang w Indonezji.

Rapid7 wpis w bazie podatności CVE-2026-97228 opisuje wstrzyknięcie zapytania GraphQL w wersjach Rapid7 Bulk Export MCP od 0.2.5 do 0.6.1, w którym niezweryfikowany eksportargument id narzędzia MCP jest wstawiany bezpośrednio do zapytania GraphQL. Rapid7 ocenia go na 2,7, niski, w skali CVSS 3.1, rekord opublikowano 25 września 2026 roku, i zauważa, że wstrzyknięte zapytania są wykonywane w ramach własnego zakresu API operatora i nie mogą przekroczyć granicy najemcy; wersja 0.6.2 naprawia problem, przekazując eksportid jako zmienną parametryzowaną. Mohiuddin twierdzi, że Rapid7 uznało go za odkrywcę.

Poza tymi przypadkami Mohiuddin informuje, że na dzień aktualizacji 16 advisory bezpieczeństwa GitHub opublikowanych przez własnych maintainerów projektów przyznaje mu status zgłaszającego; obejmują one SSRF oraz wstrzyknięcia poleceń, luki w uwierzytelnianiu, przejęcia sesji, wycieki poświadczeń i obejścia wcześniejszych poprawek, a także że jego poprawki zostały scalone w projektach takich jak github-mcp-server, mongodb-mcp-server i salesforce-mcp-server.

Nierozwiązane ustalenia rządowe

Mohiuddin informuje, że 2 września 2026 złożył pięć ustaleń jako prywatne advisory bezpieczeństwa GitHub, dotyczących serwerów MCP podlegających Technology Transformation Services GSA: serwera roszczeń świadczeń Departamentu ds. Weteranów, serwera CMS Blue Button, serwera regulations.gov, serwera USASpending oraz serwera CDC PLACES. Twierdzi, że wszystkie pięć pozostaje w fazie triage, nie zostały naprawione i nie są przedstawiane jako potwierdzone wyniki.

W przypadku VA, który opisuje jedynie na poziomie klasy, serwer zapisuje pełne ciało błędu upstream benefits‑API na poziomie ERROR bez redakcji; takie ciała mogą zawierać imię i nazwisko weterana, numer ubezpieczenia społecznego, datę urodzenia oraz adres, a on podaje, że typowe niepowodzenia walidacji wystarczają, aby wywołać takie logowanie w normalnym działaniu. Szczegóły na poziomie kodu wstrzymuje, dopóki serwery nie zostaną naprawione.

Informuje również, że 1 września 2026 powiadomił JPCERT, iż jgrants-mcp-server Japan Digital Agency nie posiada uwierzytelniania, a 7 września 2026 otworzył publiczny pull request wymagający wyraźnej zgody na powiązanie serwera z czymkolwiek innym niż pętla zwrotna oraz ograniczający rozmiar zapisu załączników. Pull request nie został scalony i nie przedstawia go jako potwierdzonego wyniku.

Pivotowanie protokołów i prelekcja na MCPCon

Mohiuddin definiuje Pivotowanie protokołów jako wieloetapowy atak, w którym przeciwnik wnika przez jeden protokół, wykorzystuje założenia zaufania, jakie protokoły mają względem siebie, i eskaluje do możliwości dostępnych wyłącznie przez inny protokół. Jego konkretny przykład umieszcza tekst przypominający instrukcję zadania A2A w wyjściu narzędzia MCP; agent koordynujący przekazuje go podagentowi jako zwykłe delegowanie, a podagent, ufając swojemu koordynatorowi, wykonuje go.

The oficjalny preprint, “Protocol Pivoting: Cross-Protocol Attack Escalation in Agentic AI Systems,” został opublikowany na Zenodo 24 maja 2026. Przedstawia trzy scenariusze: eskalację przywilejów MCP‑do‑A2A poprzez implicit trust delegation, wstrzyknięcie możliwości A2A‑do‑MCP poprzez podszywanie się pod złośliwego agenta oraz łańcuchy wstrzyknięć promptów między protokołami. Analizuje także, dlaczego istniejące środki obronne zawodzą wobec tej klasy oraz proponuje zunifikowane ramy bezpieczeństwa międzyprotokołowego z formalnym modelem granicy zaufania i trzema rozwiązaniami niezależnymi od protokołu.

Prace w maju rozpoczęły się od Microsoft’s playwright-mcp, którego narzędzie browser_navigate akceptowało dowolny URL podany przez agenta bez ochrony przed SSRF, umożliwiając skierowanie agenta do usługi metadanych instancji AWS pod adresem 169.254.169.254 oraz do jej poświadczeń. Mohiuddin zauważa, że zgłosił to jako publiczny issue na GitHub, że nie istnieje CVE ani potwierdzenie od dostawcy, a ocena nasilenia jest jego własną oceną.

Mohiuddin twierdzi, że analizy kompozycji oprogramowania i skanery zależności pomijają tę klasę, ponieważ niebezpieczne dane przychodzą przez transport jako argument narzędzia opisany w manifeście narzędzia, którego skaner nigdy nie odczytuje, więc graf wywołań zatrzymuje się na granicy transportu. Podaje, że stworzył mcp-safeguard, otwarto‑źródłowy skaner testujący serwery MCP poprzez ich wystawioną powierzchnię narzędziową bez potrzeby dostępu do kodu źródłowego, poszukujący sześciu klas: SSRF, nadmierne uprawnienia, powierzchnie wstrzyknięcia promptów, wycieki informacji, luki w uwierzytelnianiu i obejścia cyklu życia. Dodaje również, że narzędzia oparte na dopasowywaniu wzorców, w tym jego własne, pomijają dużą część tej klasy.

Mohiuddin informuje, że przedstawi wzorzec między dostawcami 23 października 2026 na MCPCon North America w San Jose, obejmując wszystkie ustalenia naprawione do tego czasu, oraz że ustalenia federalne pozostaną prywatne, dopóki nie zostaną naprawione.