Splunk MCP CVE-2026-76286: narzędzie API mogło ujawnić token użytkownika

7 października Splunk opublikował SVD-2026-1004 dotyczący CVE-2026-76286. W MCP Server wcześniejszym niż 1.2.1 własne narzędzie API mogło wysłać token platformy pod skonfigurowany adres. Producent zaleca wersję 1.2.1 lub nowszą; wskazanym obejściem jest wyłączenie albo usunięcie aplikacji MCP Server.

Rekomendacja Breachroad: połącz aktualizację z przeglądem właścicieli narzędzi, ich adresów docelowych oraz użytkowników wykonujących wywołania. Nazwa narzędzia widoczna w asystencie nie jest wystarczającą podstawą do oceny, gdzie trafiają poświadczenia.

Token należy do użytkownika wykonującego narzędzie

Rekord CVE opisuje przechwycenie tokenu osoby uruchamiającej narzędzie, gdy jego URL kontroluje inny użytkownik. Przechwycony token może pozwolić na dostęp do danych i działania jako ta osoba. Scenariusz wymaga uruchomienia odpowiednio skonfigurowanego narzędzia przez użytkownika z mcp_tool_execute.

Wniosek Breachroad: uprawnienie do korzystania z integracji i możliwość zmiany jej celu to dwa osobne elementy oceny. Zespół powinien wiedzieć, kto przygotował definicję, kto ją zatwierdził oraz czy od zatwierdzenia zmieniono adres lub parametry wykonania.

Nie przedstawiamy tej podatności jako ataku dostępnego dowolnej osobie bez konta. Zakres opisany przez producenta obejmuje role i wykonanie narzędzia. Dla administratora istotne jest odtworzenie tej ścieżki w konkretnej instancji, zamiast poprzestać na ogólnym stwierdzeniu, że firma używa MCP.

Rozdziel zarządzanie i wykonanie

Dokumentacja konfiguracji rozróżnia mcp_tool_admin, służące zarządzaniu narzędziami i tworzeniu tokenów, oraz mcp_tool_execute, umożliwiające korzystanie z narzędzi. Przejrzyj przydział obu capabilities do ról i użytkowników.

Proponujemy zapisać uzasadnienie dostępu oraz osobę zatwierdzającą zmiany. Użytkownik analizujący alerty nie musi automatycznie otrzymywać prawa do dodawania nowych integracji. Dla kont współdzielonych ustal, czy można wiarygodnie wskazać wykonawcę i ocenić jego zakres dostępu.

Przy przeglądzie sprawdź także role pozostałe po dawnym pilotażu. Decyzja o dostępie powinna odpowiadać obecnemu zadaniu, a nie tylko temu, że ktoś kiedyś konfigurował usługę. Właściciel powinien potrafić wskazać ścieżkę szybkiego wycofania niepotrzebnych uprawnień.

Zweryfikuj definicję narzędzia i wdrożoną wersję

Dokumentacja narzędzi własnych opisuje wykonanie SPL i API oraz pola takie jak cel, metoda i nagłówki. Te informacje są punktem wyjścia do przeglądu konfiguracji.

Nasza propozycja: dla każdego aktywnego narzędzia zapisz właściciela, uzgodniony cel, potrzebne poświadczenia i ostatnie zatwierdzenie. Oceń zmiany adresu razem z zespołem odpowiedzialnym za integrację. Nie testuj podejrzenia wycieku przez wysyłanie rzeczywistego tokenu do zewnętrznego serwisu.

Potwierdź wersję aplikacji MCP Server na instancji, która obsługuje użytkowników. W planie aktualizacji uwzględnij repliki lub klaster oraz kontrolę poprawnego działania dopuszczonych narzędzi. Jeżeli aktualizacja musi poczekać, przypisz właściciela wyjątku i uzgodnij wyłączenie aplikacji zgodnie z zaleceniem producenta.

Jeśli podejrzewasz wcześniejsze ujawnienie

Zalecamy zachować definicję narzędzia, historię jej zmian oraz dostępne ślady wywołań. Zespół reagowania powinien ustalić, czy narzędzie uruchomiono, na jaki adres i z jakim zakresem uprawnień. Przy podejrzeniu ujawnienia poświadczenia uwzględnij jego unieważnienie oraz ocenę wykonanych działań.

To rekomendacje Breachroad, nie potwierdzenie incydentu w Twoim środowisku. Jasne powiązanie użytkownika, konfiguracji i celu pomaga określić zakres zdarzenia. Szerszy kontekst znajdziesz w przewodniku po bezpieczeństwie MCP. Na szkoleniu z cyberbezpieczeństwa i bezpiecznego AI dla organizacji możemy przećwiczyć zatwierdzanie narzędzi, ocenę poświadczeń i zgłaszanie nieoczekiwanych działań asystenta.