Przejdź do treści
INDEKS ANALIZ BREACHROAD / NOTA TECHNICZNA

Splunk publikuje 92 CVE: RCE w Enterprise, AI Toolkit, MCP i SOAR

Trzy biuletyny Splunk z 19 sierpnia obejmują 92 CVE. Analizujemy RCE, deserializację, SPL/SQL injection, role i praktyczny plan aktualizacji.

MATERIAŁ PUBLICZNY
AUTOR
/ CEO Breachroad · OSCP · PNPT
PUBLIKACJA
19 sierpnia 2026
CZAS CZYTANIA
19 min czytania
TEMAT
Podatności i CVE
Splunk publikuje 92 CVE: RCE w Enterprise, AI Toolkit, MCP i SOAR

Splunk opublikował 19 sierpnia 2026 roku trzy duże grupy poprawek bezpieczeństwa: 60 CVE dla Splunk Enterprise, 15 dla Splunk SOAR oraz 17 dla aplikacji i add-onów. Łącznie daje to 92 identyfikatory CVE w głównych biuletynach hardeningowych. Zakres obejmuje zdalne wykonanie kodu, błędy autoryzacji, SPL i SQL injection, path traversal, ujawnienie tokenów oraz niebezpieczną deserializację w Splunk AI Toolkit i Splunk MCP Server.

Ta liczba nie oznacza 92 nieuwierzytelnionych RCE. Wiele problemów wymaga określonej roli, capability, włączonej funkcji albo interakcji użytkownika. Część ma wpływ średni lub niski. Nie usprawiedliwia to opóźnienia: Splunk często przechowuje najbardziej wrażliwe logi organizacji, tokeny integracji i dane potrzebne do reagowania na incydenty. Przejęcie platformy obronnej osłabia widoczność i może umożliwić modyfikację dowodów.

SVD-2026-0801: 60 problemów w Splunk Enterprise

Biuletyn „Security Hardening Release for Splunk Enterprise — August 2026” ma najwyższy wynik CVSS 9,4. Splunk wskazuje wersje naprawione 10.4.2, 10.2.6, 10.0.9 i 9.4.14. Wspierane podatne zakresy należy porównać z macierzą produktu; samo posiadanie gałęzi 10.4 nie wystarcza, jeśli instancja działa na 10.4.0 lub 10.4.1.

Trzy krytyczne pozycje, CVE-2026-76310, CVE-2026-76311 i CVE-2026-76312, dotyczą nieprawidłowej kontroli dostępu przy raportach osadzonych, ich archiwach i dispatchu. Wynik 9,4 wskazuje bardzo poważny wpływ na poufność, integralność i dostępność w opisanym kontekście. Zespół powinien sprawdzić użycie embedded reports i nie zakładać, że ryzyko dotyczy wyłącznie administratora.

W grupie RCE znajdują się CVE-2026-76313 przez REST API, CVE-2026-76314 i CVE-2026-76335 przez konfigurację Splunk Web Manager oraz CVE-2026-76319 przez Federated Search. CVE-2026-76345 również opisuje RCE przez REST API, ale ma inne warunki i niższy wynik. Wspólna etykieta „RCE” nie oznacza wspólnej ekspozycji.

Biuletyn obejmuje także liczne SPL injection, SQL injection, path traversal, XSS, SSRF i problemy z tokenami. Szczególnie istotne są błędy w knowledge bundles, search head clustering, distributed search i konfiguracji alertów, bo działają w środowisku wielowęzłowym i mogą przekraczać granicę pojedynczego search heada.

Dodatkowe kroki dla wybranych CVE

Splunk zaznacza, że sama aktualizacja nie zamyka w pełni CVE-2026-76338 i CVE-2026-76352; wymagane są dodatkowe działania opisane w szczegółach advisory. To klasyczna pułapka automatyzacji: skaner zobaczy wersję naprawioną, lecz konfiguracja, token lub stan historyczny może pozostać ryzykowny.

Playbook powinien odczytać sekcję „Mitigations and Workarounds” per CVE, a nie tylko tabelę wersji. Jeżeli błąd mógł ujawnić token albo pozwolić na nieprawidłową autoryzację, potrzebne może być unieważnienie poświadczeń, przegląd ról, ponowne wygenerowanie kluczy lub usunięcie starego artefaktu. Dowodem zamknięcia jest wykonanie obu części.

SVD-2026-0804: 15 CVE w Splunk SOAR

Splunk SOAR otrzymał osobny hardening obejmujący 15 CVE i aktualizację do wersji 8.6.0. Najwyższy wynik w tej grupie to 8,1. CVE-2026-76356 opisuje obejście uwierzytelnienia związane ze spoofingiem adresu IP. CVE-2026-76357 dotyczy zdalnego wykonania kodu przez path traversal. CVE-2026-76363, 76364 i 76365 obejmują SQL injection, a CVE-2026-76366 może ujawniać token sesyjny.

SOAR nie jest zwykłym panelem. Uruchamia playbooki, komunikuje się z EDR, pocztą, chmurą, firewallami i systemami ticketowymi. Tożsamości używane przez platformę mogą izolować host, blokować konto, pobierać wiadomości i zmieniać polityki. Nawet błąd wymagający zalogowanego użytkownika może mieć wysoki skutek, jeżeli jego rola pozwala wyzwolić automatyzację.

Po aktualizacji trzeba przejrzeć tokeny aplikacji, konta usługowe i historię playbooków. Nietypowe wykonanie nie zawsze wygląda jak nowy proces na serwerze SOAR; może przejawiać się legalnym wywołaniem do systemu zewnętrznego wykonanym w złym kontekście.

SVD-2026-0808: AI Toolkit i niebezpieczny pickle

Grupa aplikacji i add-onów obejmuje 17 CVE. CVE-2026-76395 w Splunk AI Toolkit ma wynik 8,8 i dotyczy deserializacji nieufnych danych w formacie pickle podczas obsługi macierzy rzadkiej. Użytkownik z rolą power mógł doprowadzić do wykonania kodu na systemie. Naprawa znajduje się w AI Toolkit 6.0.1, a wyłączenie lub usunięcie aplikacji jest mitygacją, jeśli aktualizacja nie może zostać przeprowadzona.

Pickle zapisuje graf obiektów Pythona i podczas odczytu może uruchamiać funkcje potrzebne do ich odtworzenia. isinstance wykonane po deserializacji jest za późno: kod mógł już się uruchomić. Dane modelu, eksperymentu czy macierzy trzeba traktować jak wykonywalny artefakt. Bezpieczniejsze formaty tablicowe i jawne schematy redukują tę klasę ryzyka, ale nadal potrzebują limitów rozmiaru i parsera.

CVE-2026-76399 w AI Toolkit pokazuje drugi problem: rola power mogła modyfikować dostarczone z aplikacją zaplanowane wyszukiwania i uruchamiać SPL z uprawnieniami właściciela. Jest to confused deputy — platforma wykonuje legalną operację, ale na danych i w kontekście wybranym przez mniej uprzywilejowaną osobę.

CVE-2026-76404: krytyczne RCE w Splunk MCP Server

CVE-2026-76404 ma wynik 9,1 i dotyczy aplikacji Splunk MCP Server poniżej 1.2.1. Użytkownik z rolą admin mógł wykonać dowolne polecenia systemu operacyjnego. Przyczyną jest brak walidacji w komponencie zarządzania poświadczeniami, który deserializował przechowywane dane bez sprawdzenia oczekiwanego typu.

Wymóg roli administratora obniża prawdopodobieństwo przypadkowego wejścia, ale nie usuwa wpływu. Administrator Splunk nie zawsze powinien być administratorem systemu operacyjnego. Błąd łamie rozdzielenie obowiązków i zmienia przejęcie konta aplikacyjnego w wykonanie na hoście.

Aktualizacja do MCP Server 1.2.1 jest podstawą. Trzeba też ustalić, czy host aplikacji posiada tokeny do indeksów, vaulta, systemów zewnętrznych i innych search headów. Jeżeli istnieją oznaki nadużycia, rotacja dotyczy całego grafu poświadczeń osiągalnych z procesu, nie tylko hasła użytkownika Splunk.

Pozostałe aplikacje i dodatki

Biuletyn zawiera poprawki między innymi dla Splunk Connect for Kafka, Splunk On-Call oraz innych dodatków. Wersja Connect for Kafka 2.2.7 naprawia problemy dotyczące retry, ReDoS, SSRF i walidacji certyfikatów. Splunk On-Call 1.0.43 poprawia przechowywanie klucza API. Każda aplikacja ma własny cykl wersji, niezależny od Splunk Enterprise.

To oznacza, że aktualizacja core do 10.4.2 nie aktualizuje automatycznie AI Toolkit, MCP Server ani konektora Kafka. CMDB musi przechowywać listę aplikacji z wersjami per instancja. Search head cluster wymaga spójnego bundle i kontrolowanej dystrybucji; ręczna zmiana na jednym węźle może zostać nadpisana.

Priorytetyzacja według ścieżki, nie tylko CVSS

Najpierw wyznacz powierzchnie internetowe: Splunk Web, REST API, management port, embedded reports, SOAR API i dostępne konektory. Następnie znajdź role admin, power, custom capabilities, konta automatyzacji i tokeny użytkowników. Trzecia warstwa to topologia: search head cluster, indexery, deployment server, heavy forwardery, federated search i aplikacje.

Praktyczna kolejność:

  1. zaktualizuj zewnętrznie osiągalne Enterprise do wspieranej wersji naprawionej;
  2. wdroż SOAR 8.6.0 i sprawdź połączenia aplikacyjne;
  3. zaktualizuj AI Toolkit do 6.0.1 oraz MCP Server do 1.2.1 albo wyłącz aplikacje;
  4. wykonaj dodatkowe kroki dla CVE-2026-76338 i 76352;
  5. przejrzyj role, capabilities, scheduled searches i właścicieli obiektów;
  6. zrotuj tokeny wskazane przez ślady dostępu lub klasy podatności;
  7. ponownie wdroż poprawiony bundle na wszystkich węzłach i potwierdź wersję procesu.

W okresie przejściowym ogranicz management port i REST do sieci administracyjnych, wyłącz nieużywane aplikacje oraz oddziel użytkowników od kont usługowych. Nie wykonuj testów RCE ani deserializacji na produkcji. Walidację prowadź przez wersję, konfigurację, syntetyczne dane w laboratorium i przegląd logów.

Hunting po aktualizacji

Szukaj zmian konfiguracji Manager, nietypowego tworzenia lub modyfikacji scheduled searches, wywołań REST przez role, które zwykle ich nie używają, błędów deserializacji oraz nowych procesów potomnych usługi Splunk. Skoreluj to z modyfikacjami plików w $SPLUNK_HOME, połączeniami wychodzącymi, wydaniem tokenu i aktywnością w systemach zintegrowanych.

Dla SOAR przejrzyj playbooki uruchomione poza zwykłym harmonogramem, nowe assety, modyfikacje credentials i wywołania destrukcyjne. Dla AI Toolkit zbadaj importy artefaktów, historię eksperymentów i wykonania przez rolę power. Dla MCP sprawdź zarządzanie credentialami oraz procesy OS powiązane czasowo z żądaniem aplikacji.

Fakty producenta i wnioski Breachroad

Liczby 60, 15 i 17, wersje naprawione, wymagane role oraz opisy CVE pochodzą z advisory Splunk. Nie ma podstaw, by przedstawiać wszystkie 92 jako jedną nieuwierzytelnioną kampanię. Priorytetyzacja po topologii, rotacja grafu sekretów i reguły huntingu są wnioskami Breachroad.

Ponieważ SIEM i SOAR są częścią obrony, ich właściciele powinni przećwiczyć aktualizację bez utraty telemetrii. Szkolenia cyberbezpieczeństwa dla organizacji pomagają SOC, platformie i administratorom uzgodnić reakcję, a audyt bezpieczeństwa IT może zweryfikować role, segmentację, aplikacje oraz dowody patchowania.

Źródła

UDOSTĘPNIJ / KOPIUJ