Podatności Meta Ads MCP

W Meta Ads MCP przed wersją 1.0.115 narzędzie upload_ad_image w meta_ads_mcp/core/ads.py przekazuje kontrolowany przez atakującego image_url do try_multiple_download_methods() w meta_ads_mcp/core/utils.py, gdzie httpx.AsyncClient używa follow_redirects=True i wykonuje żądania HTTP bez walidacji schematu, hosta lub rozwiązanego adresu IP. W wdrożeniu streamable-http wywołujący sieciowy może użyć dowolnej niepustej wartości autoryzacji, ponieważ walidacja poświadczeń Meta następuje po pobraniu obrazu, a następnie skierować serwer do usług loopback, adresów sieci prywatnej, punktów końcowych metadanych chmury lub łańcuchów przekierowań do celów wewnętrznych. Wynikające z tego SSRF może ujawnić dane wewnętrzne, wywołać usługi wewnętrzne zmieniające stan lub zakłócić osiągalne usługi. Problem naprawiono w wersji 1.0.115.

Serwer Meta Ads MCP w wersjach przed 1.0.115 zawiera błąd w mechanizmie uwierzytelniania AuthInjectionMiddleware, który odrzuca żądania HTTP tylko gdy brakuje obu tokenów, a funkcja extract_token_from_headers() nie rozpoznaje nagłówka X-Pipeboard-Token jako głównego poświadczenia. Zdalny atakujący przez transport streamable-http może wysłać dowolną wartość tego nagłówka, ominąć zabezpieczenie i spowodować użycie przez serwer tokenu META_ACCESS_TOKEN operatora.

Meta Ads MCP przed wersją 1.0.109 ma podatność w AuthInjectionMiddleware.dispatch(), która bezwarunkowo przekazuje nieuwierzytelnione żądania Streamable HTTP do handlerów narzędzi MCP bez zwracania odpowiedzi 401, co pozwala każdemu wywołującemu z sieci na wywoływanie narzędzi MCP bez uwierzytelnienia. Gdy brakuje poświadczeń, handlery używają zmiennej środowiskowej META_ACCESS_TOKEN, a gdy wywołanie Meta Graph API nie powiedzie się, odpowiedź JSON-RPC zawiera surowy URL żądania z tokenem dostępu, co ujawnia poświadczenia nieuwierzytelnionemu wywołującemu.