ServiceNow CVE-2026-6875: pre-auth RCE i sandbox escape

CVE-2026-6875 to krytyczna podatność ServiceNow AI Platform, która w określonych warunkach pozwala nieuwierzytelnionemu użytkownikowi uciec z piaskownicy skryptowej i wykonać kod. ServiceNow wdrożył aktualizacje do instancji hostowanych oraz przekazał poprawki klientom self-hosted i partnerom. 21 lipca pojawiły się doniesienia o próbach wykorzystania luki po publikacji analizy technicznej. Nie ma jednak wystarczających danych, aby każdą obserwowaną próbę uznać za atak przestępczy: przechwycony payload okazał się identyczny z publicznym materiałem badawczym, a ServiceNow nie potwierdził naruszenia hostowanych przez siebie instancji.

Taka niepewność nie jest argumentem za czekaniem. Rekord CVE-2026-6875 w NVD opisuje możliwość wykonania kodu bez uwierzytelnienia oraz pełny wpływ na poufność, integralność i dostępność. Oficjalny artykuł ServiceNow KB3137947 zawiera właściwe poprawki. Organizacja powinna najpierw potwierdzić wersję i stan aktualizacji, a następnie przeprowadzić kontrolowany hunting oznak wcześniejszego dostępu.

Co wiemy, a czego nie wiemy

ServiceNow opublikował advisory 13 lipca, a szczegółowa analiza Searchlight Cyber ukazała się 14 lipca. Badacze opisali łańcuch prowadzący od niezaufanego parametru używanego w zapytaniu GlideRecord, przez wykonanie JavaScript w ograniczonej piaskownicy, do ominięcia dodatkowych restrykcji. W ich środowisku skutkiem był dostęp pozwalający m.in. czytać tabele, tworzyć administratorów i oddziaływać na skonfigurowane serwery MID.

18 lipca firma Defused poinformowała o obserwowanej eksploatacji. Następnie sprostowała, że próbka nie korzystała z odmiennego wariantu, lecz była identyczna z opublikowanym proof of concept. ServiceNow przekazał SecurityWeek, że zna doniesienie, nie widzi dowodów dotyczących instancji hostowanych przez producenta i nadal zaleca zastosowanie poprawek. Nie ma publicznego potwierdzenia kampanii nazwanej grupy, kradzieży danych ani masowych przejęć.

Stwierdzenie	Status na 21.07.2026
luka umożliwia pre-auth RCE w określonych warunkach	potwierdzone przez CVE, producenta i badaczy
poprawki istnieją	potwierdzone przez ServiceNow
techniczna ścieżka została publicznie opisana	potwierdzone
w Internecie obserwowano próbkę wykorzystania	zgłoszone przez firmę threat-intelligence
próbkę używał przestępca	niepotwierdzone
hostowane instancje ServiceNow zostały przejęte	producent nie znalazł takich dowodów
luka znajduje się w CISA KEV	nie na moment publikacji

Dlaczego sandbox escape ma tak duży wpływ

ServiceNow posiada własną warstwę danych, kontrole ACL, API zapytań GlideRecord i silnik skryptowy. W wielu miejscach dane użytkownika trafiają do mechanizmu filtrowania. Sam fakt wykonania fragmentu JavaScript nie musi jeszcze oznaczać pełnego kompromisu, ponieważ środowisko stosuje dodatkową piaskownicę dla niezaufanych filtrów. Krytyczny charakter CVE-2026-6875 wynika z połączenia: dostęp przed uwierzytelnieniem, wykonanie skryptu oraz możliwość przejścia do kontekstu z dużo szerszymi możliwościami.

Piaskownica jest granicą bezpieczeństwa. Jeżeli mechanizm udostępnia funkcje lub biblioteki, które można połączyć w niezamierzony sposób, pojedyncze dozwolone operacje mogą stworzyć łańcuch ucieczki. To przypomina deserializację albo gadget chains: każda część może mieć legalne zastosowanie, lecz kompozycja otwiera ścieżkę do działania poza założoną polityką. Właśnie dlatego modelowanie zagrożeń musi obejmować nie tylko endpoint, lecz także interpretatory, includes, refleksję i granicę między sandboxem a hostem.

Nie publikujemy w tym materiale gotowego payloadu. Dla obrony ważniejsze jest rozpoznanie ekspozycji, poprawka, monitoring i analiza śladów. Publiczne szczegóły techniczne skracają czas potrzebny zarówno badaczom, jak i skanerom, dlatego priorytet aktualizacji rośnie po disclosure niezależnie od niepewnej atrybucji pierwszych prób.

Instancja SaaS a środowisko self-hosted

ServiceNow poinformował, że aktualizacja została wdrożona do hostowanych instancji. Klient nie powinien jednak zakładać stanu wyłącznie na podstawie modelu SaaS. Trzeba sprawdzić konkretny release i patch level w panelu, komunikaty support oraz historię zmian. Instancje mogą mieć różne okna utrzymaniowe, partnerów i rozszerzenia.

Klienci self-hosted odpowiadają za zastosowanie właściwej poprawki. Rekord CVE wymienia dotknięte gałęzie Australia, Yokohama, Zurich i Brazil z odpowiadającymi poziomami patch. Ponieważ lista zawiera warianty hotfix i release, źródłem prawdy powinien być artykuł KB oraz wsparcie producenta, a nie uproszczona tabela z zewnętrznego bloga.

W obu modelach odpowiedzialność klienta obejmuje role, dane, integracje, konta i reakcję. Nawet jeśli platforma bazowa została zaktualizowana automatycznie, skradzione wcześniej tokeny, nieznany administrator lub zmieniona reguła integracji nie znikną od samego patcha. To klasyczna różnica między zamknięciem wektora a usunięciem skutków incydentu.

Dlaczego MID Server zwiększa potencjalny zasięg

MID Server pośredniczy między instancją ServiceNow a zasobami wewnętrznymi. Może wykonywać discovery, automatyzację, integrację i zadania orkiestracyjne. Zależnie od konfiguracji ma łączność do serwerów, urządzeń, chmur i systemów zarządzania. Badacze Searchlight wskazali, że uzyskany przez nich poziom dostępu mógł pozwolić uruchamiać polecenia na skonfigurowanych MID Serverach.

Nie znaczy to, że każda instalacja prowadzi automatycznie do całej domeny. Skutek zależy od ról konta usługi, segmentacji, allowlisty celów, możliwości uruchamiania skryptów i sposobu przechowywania poświadczeń. Zespół powinien potraktować MID jak uprzywilejowany workload i zastosować zasadę najmniejszych uprawnień, odrębne tożsamości oraz ograniczenia egress.

Test segmentacji sieci wewnętrznej powinien sprawdzić, czy kompromitacja MID pozwala dotrzeć do kontrolerów domeny, hypervisorów, backupu lub innych stref administracyjnych. Bezpieczny test wykorzystuje konta laboratoryjne i nieszkodliwe canary, a nie polecenia destrukcyjne.

Plan działań na pierwsze cztery godziny

1. Zbuduj listę instancji

Zidentyfikuj produkcję, test, development, demo, DR i instancje partnerów. Dodaj vanity domains, adresy publiczne, release family, patch level, model hostowania, właściciela i powiązane MID Server. Asset inventory jest ważniejszy niż pojedynczy skan domeny głównej.

2. Potwierdź poprawkę

Porównaj każdą instancję z KB3137947. Dla SaaS zachowaj dowód wersji i komunikat wdrożenia. Dla self-hosted pobierz pakiet z zaufanego kanału, zweryfikuj integralność, wykonaj backup oraz wdrożenie zgodnie z procedurą producenta. Nie testuj podatności agresywnym publicznym PoC na produkcji.

3. Ogranicz ekspozycję

Jeżeli poprawka nie może wejść natychmiast, skontaktuj się z ServiceNow w sprawie wspieranej mitygacji. Ogranicz publiczny dostęp tam, gdzie jest to biznesowo możliwe, wzmocnij WAF tylko jako warstwę czasową i monitoruj próby do endpointów przed uwierzytelnieniem. Reguła WAF nie zastępuje patcha, ponieważ kodowanie oraz warianty zapytania mogą ominąć sygnaturę.

4. Rozpocznij hunting

Zabezpiecz logi aplikacji, reverse proxy, WAF, systemu tożsamości, zmian administracyjnych, integracji oraz MID. Szukaj nowych administratorów, zmian ACL, nowych integracji, nietypowych zapytań do tabel, uruchomień z MID i eksportów danych. Koreluj czas, konto, adres źródłowy i identyfikator żądania. Jeżeli retencja jest krótka, najpierw eksportuj dane do chronionego repozytorium.

Jak odróżnić skan badawczy od kompromitacji

Pojedyncze żądanie podobne do PoC nie dowodzi powodzenia. Może pochodzić od legalnego skanera organizacji, dostawcy ASM, badacza albo napastnika. Dowód kompromitacji wymaga skutku: nietypowego procesu, zmiany konta, odczytu danych, operacji na MID lub ciągu żądań odpowiadających udanej eksploitacji.

Warto zbudować trzy poziomy:

próba — żądanie pasujące do techniki, bez potwierdzonego skutku;
prawdopodobne powodzenie — odpowiedź i kolejne zachowanie wskazują na wykonanie;
potwierdzony incydent — artefakt platformy, konto, proces, dane albo operacja powstała w wyniku nieautoryzowanego działania.

Taka klasyfikacja zapobiega zarówno bagatelizowaniu, jak i fałszywemu komunikatowi o włamaniu. Proces cyber threat intelligence powinien przechowywać poziom pewności i źródło każdej oceny.

Co zbadać po znalezieniu śladów

Najpierw zabezpiecz dowody i unikaj zmian niszczących timeline. Eksportuj logi audytowe, listę użytkowników i ról, historię konfiguracji, aktywność integracji, tokeny OAuth, skrypty, zadania oraz dane MID. Następnie unieważnij podejrzane sesje i tokeny, ale zachowaj identyfikatory potrzebne do korelacji.

Zakres rotacji powinien wynikać z możliwego dostępu. Jeżeli platforma przechowywała poświadczenia do systemów wewnętrznych lub mogła wywoływać MID, rotacja tylko hasła administratora ServiceNow jest niewystarczająca. Trzeba ocenić vault, konta discovery, klucze API, certyfikaty integracji i sekrety chmurowe.

Po oczyszczeniu przeprowadź ponowną walidację: patch level, brak nieznanych kont, integralność krytycznych reguł i kontrolowany test, że podatna ścieżka nie działa. Plan reagowania na incydent powinien określać, kto decyduje o odłączeniu MID i zawiadomieniu klientów lub organów.

Długoterminowe utwardzenie ServiceNow

Ogranicz publiczne endpointy i funkcje do wymaganych przypadków.
Stosuj MFA odporne na phishing dla administratorów i support.
Rozdziel role tworzenia skryptów, publikacji i audytu.
Nadaj MID osobne konta dla różnych stref i zadań.
Ogranicz egress i cele MID za pomocą allowlist.
Eksportuj logi krytycznych zmian do niezależnego systemu.
Wykrywaj tworzenie administratorów, masowy odczyt i nowe integracje.
Utrzymuj testową instancję do bezpiecznej walidacji poprawek.
Prowadź tabletop obejmujący kompromitację SaaS i automatyzacji.

Weryfikacja ról i integracji jest naturalną częścią porównania pentestu, audytu i skanu. Platforma workflow często łączy IT, HR, finanse i operacje, więc błąd w jednym miejscu może przekroczyć granice wielu procesów biznesowych.

Warto zachować kompletny pakiet dowodowy z okna serwisowego: eksport wersji przed i po zmianie, sumy kontrolne paczek, listę węzłów, wynik testów regresji oraz osobę zatwierdzającą. Taki zapis ułatwia audyt, pozwala szybko wyjaśnić późniejsze alarmy i zapobiega sytuacji, w której dashboard pokazuje stan zgodny, lecz ruch nadal trafia do zapomnianej instancji.

FAQ

Czy CVE-2026-6875 jest aktywnie wykorzystywane?

Istnieje publiczne zgłoszenie obserwowanej próby. Po korekcie wiadomo, że payload był identyczny z opublikowanym materiałem badawczym. Nie ustalono, czy wykonał go napastnik, badacz czy skaner. ServiceNow nie potwierdził naruszenia swoich hostowanych instancji. Ryzyko pozostaje wysokie z powodu pre-auth RCE i publicznych szczegółów.

Czy instancje SaaS są już bezpieczne?

Producent deklaruje wdrożenie aktualizacji do hostowanych instancji, lecz klient powinien zweryfikować swoją wersję i komunikaty support. Patch zamyka lukę, ale nie wyklucza dostępu sprzed aktualizacji.

Czy WAF wystarczy?

Nie. Może ograniczyć część prób, lecz nie jest trwałą poprawką dla błędu logiki interpretera i sandboxa. Priorytetem pozostaje wspierany patch oraz analiza logów.

Najważniejszy wniosek

W CVE-2026-6875 krytyczne są trzy elementy: dostęp przed logowaniem, ucieczka z granicy bezpieczeństwa i możliwość dotarcia do wysoko uprzywilejowanej automatyzacji. Nie trzeba czekać na potwierdzoną kampanię, aby aktualizować. Trzeba natomiast precyzyjnie opisywać dowody: próba wykorzystania nie jest jeszcze potwierdzonym włamaniem.

Masz ServiceNow lub MID Server w krytycznej części środowiska? BreachRoad może pomóc przeprowadzić defensywną walidację ekspozycji, hunting i przegląd segmentacji bez uruchamiania destrukcyjnego PoC. Skontaktuj się z nami, aby ustalić zakres.