ServiceNow zabezpieczył własną chmurę w dobę. Klienci z instalacjami u siebie czekali trzy i pół miesiąca — a instrukcja obsługi ataku ukazała się w dniu, w którym dostali łatkę.

Wczoraj pisaliśmy o tym, jak państwo przestało ufać liczbie luk jako mierze ryzyka, i o dwudziestu godzinach, w które atakujący zamienili opis podatności w działający atak. Dziś przypadek, który pokazuje drugą stronę tego samego mechanizmu — nie prędkość napastnika, lecz to, że słowo „załatane" oznacza dziś dwie różne rzeczy dla dwóch grup klientów tego samego produktu.

1 kwietnia badacze z Searchlight Cyber zgłosili firmie ServiceNow krytyczną lukę w jej platformie AI, pozwalającą nieuwierzytelnionemu atakującemu uciec z piaskownicy i wykonać dowolny kod. ServiceNow zareagował wzorowo: w ciągu dwudziestu czterech godzin wdrożył mitygacje na wszystkich instancjach chmurowych, blokując możliwość modyfikacji kluczowych funkcji JavaScriptu. Klienci korzystający z hostingu producenta byli bezpieczni od początku kwietnia i nie musieli o tym wiedzieć.

Łatki dla klientów, którzy uruchamiają platformę u siebie, wyszły 13 lipca. Tego samego dnia Searchlight opublikował szczegółowy opis techniczny wraz z kodem demonstrującym atak. Pięć dni później, w piątek 18 lipca, firma Defused zaobserwowała pierwsze złośliwe ładunki w realnym ruchu.

Trzy i pół miesiąca różnicy w tym, kiedy dwie grupy klientów tego samego produktu przestały być podatne. I jedna data publikacji dla obu.

Mechanizm, w skrócie

Platforma ServiceNow uruchamia JavaScript w dwuwarstwowej piaskownicy. Warstwa zewnętrzna daje skryptom uprawnienia zbliżone do administratora platformy, ale odcina je od systemu operacyjnego. Warstwa wewnętrzna, nazywana piaskownicą skryptów, nakłada dodatkowe ograniczenia na dane pochodzące od użytkownika — w tym te przyjmowane bez uwierzytelnienia — blokując funkcje eval, konstruktor Function, deklaracje funkcji i większość dostępu do klas Javy.

Luka, oznaczona CVE-2026-6875 i oceniona na 9,5 punktu, mieszka w szczelinie między tymi warstwami. Interfejs zapytań GlideRecord akceptował w metodzie addQuery() prefiks javascript:, co powodowało, że platforma najpierw obliczała przekazane wyrażenie, a dopiero potem używała wyniku jako argumentu zapytania. Wywołanie gs.include() na odpowiednio dobranej bibliotece sprawiało z kolei, że własny kod ServiceNow rozszerzający klasy sięgał po konstruktor Function i uruchamiał treść kontrolowaną przez atakującego — już poza piaskownicą.

Punktem wejścia był endpoint /assessment_thanks.do, dostępny bez logowania. Po ucieczce atakujący czytał i zapisywał dowolną tabelę, tworzył konta administratorów i wydawał polecenia połączonym serwerom pośredniczącym MID — czyli sięgał w głąb sieci wewnętrznej klienta. Badacz Adam Kues opisał to jako pełne przejęcie instancji wraz ze wszystkimi podłączonymi serwerami pośredniczącymi, zaznaczając przy tym, że sam atak jest wysokiej złożoności.

Sprostowanie, które umknęło większości

Tu potrzebna jest chwila dyscypliny, bo przez media przeszła narracja, która najprawdopodobniej jest nieprawdziwa — a my ją wczoraj sami moglibyśmy powtórzyć.

Defused, ogłaszając obserwację ataków, napisał początkowo, że ładunki trafiają wprawdzie w ten sam nieuwierzytelniony punkt wejścia, który udokumentował Searchlight, ale osiągają wykonanie kodu inną drogą niż opublikowany kod demonstracyjny. Z tego wyciągnięto wniosek daleko idący i chwytliwy: atakujący błyskawicznie wymyślili własny wariant, więc organizacje, które zablokowały znaną technikę zamiast załatać, nie są chronione. Tę wersję powtórzyły kolejne serwisy.

Potem Defused wydał sprostowanie: przechwycony ładunek jednak odpowiada kodowi demonstracyjnemu opublikowanemu przez Searchlight. Historia o błyskawicznej innowacji atakujących rozpadła się, ale sprostowanie rozeszło się nieporównanie słabiej niż pierwotna teza.

To nie jest przygana pod adresem Defused — badacze publikujący obserwacje na gorąco mają prawo do korekty i wydali ją szybko. To jest przypomnienie, że w tygodniu, w którym wszyscy piszą o prędkości atakujących, najłatwiej uwierzyć w każdą historię o tym, jak szybcy się stali. Faktem pozostaje pięć dni od publikacji do eksploatacji. Nie jest faktem, że napastnicy w tym czasie cokolwiek wynaleźli — sięgnęli po gotowe.

Odpowiedź, którą warto odnotować

Od miesięcy opisujemy pękające piaskownice. Przy DuneSlide pokazaliśmy agenta nadpisującego własne więzienie, przy kolejnych przypadkach — bariery, które okazywały się cieńsze, niż zakładano. Ten przypadek zasługuje na odnotowanie, bo reakcja producenta była inna niż zwykle.

ServiceNow nie poprzestał na załataniu konkretnej drogi ucieczki. Wprowadził mechanizm nazwany Guarded Script, który zmienia to, co w piaskownicy da się w ogóle wyrazić. Kod przyjmowany od nieuwierzytelnionego użytkownika może odtąd być jednym prostym wyrażeniem — bez deklaracji zmiennych, bez przepływu sterowania, bez definicji funkcji, bez przypisań, bez wielu instrukcji obok siebie. Searchlight komentuje to jednoznacznie: takie ograniczenie składni czyni przyszłe ucieczki z piaskownicy znacznie mniej prawdopodobnymi.

To jest strukturalnie właściwa odpowiedź i warto ją nazwać, skoro tak często opisujemy odpowiedzi niewłaściwe. Łatanie kolejnych gadżetów ucieczki jest wyścigiem, w którym obrońca zawsze biegnie drugi, bo lista możliwych kombinacji jest dłuższa niż lista tych już znalezionych. Skurczenie języka, w którym atakujący może się w ogóle wypowiedzieć, wyścig kończy. Nie usuwa piaskownicy — zmniejsza to, co przez nią przechodzi.

Asymetria, która jest właściwym tematem

Wróćmy jednak do dat, bo tam leży rzecz najciekawsza.

Skoordynowane ujawnianie podatności opiera się na cichym założeniu, że istnieje jeden moment, w którym produkt przestaje być podatny — i że publikacja badań następuje po nim. Przy modelu, w którym ten sam produkt działa u części klientów jako usługa producenta, a u części na ich własnych serwerach, to założenie przestaje obowiązywać. Są dwa takie momenty, oddalone od siebie o miesiące, a badanie publikuje się w tym późniejszym.

Skutek jest niesymetryczny w sposób, który warto zobaczyć wyraźnie. Klient chmurowy dostał ochronę w ciągu doby, bez żadnego działania z własnej strony, i był bezpieczny przez cały okres, gdy o luce wiedział wyłącznie producent i zgłaszający. Klient z instalacją u siebie był podatny przez trzy i pół miesiąca, a potem otrzymał łatkę dokładnie tego dnia, w którym opublikowano ścieżkę ataku wraz z działającym kodem. Jego okno na aktualizację zaczęło się w chwili, gdy zaczęło się także okno atakującego — i było to okno pięciodniowe.

Ten, kto wybrał kontrolę nad wygodą, płaci więc podwójnie: czeka na łatkę dłużej i dostaje instrukcję ataku w momencie własnej maksymalnej ekspozycji. Nie jest to niczyja wina w potocznym sensie. ServiceNow zareagował szybko i naprawił rzecz strukturalnie, Searchlight wstrzymał publikację do czasu wydania łatek, czyli zrobił dokładnie to, czego wymaga dobra praktyka. Po prostu procedura zaprojektowana dla świata z jedną datą naprawy działa inaczej, gdy tych dat jest dwie.

Widać to też w pozornym sporze wokół samej eksploatacji. Defused mówi o atakach w realnym ruchu; ServiceNow odpowiada, że nie widzi dowodów, by dotyczyły one instancji, które sam hostuje, a w oficjalnym komunikacie podtrzymuje, że nie ma wiedzy o atakach na instancje ServiceNow. Te dwa zdania nie są sprzeczne. Są potwierdzeniem asymetrii: atak celuje tam, gdzie łatka przyszła później i gdzie ktoś musiał ją nałożyć ręcznie.

Co z tego wynika dla obrońcy

Pierwsza rzecz jest natychmiastowa. Jeśli utrzymujesz ServiceNow we własnej infrastrukturze i nie nałożyłeś aktualizacji z 13 lipca, zrób to teraz i przejrzyj logi pod kątem żądań do /assessment_thanks.do od tej daty. Aktywna eksploatacja dotyczy właśnie instancji zarządzanych samodzielnie.

Druga jest planistyczna i dotyczy każdego oprogramowania utrzymywanego u siebie, nie tylko tego jednego. Warto przyjąć jako regułę, że dzień publikacji łatki dla wersji samodzielnie hostowanej jest zarazem dniem, w którym najprawdopodobniej ukaże się analiza techniczna — bo badacze świadomie czekają z publikacją do momentu, gdy poprawka jest dostępna dla wszystkich. Oznacza to, że w takich przypadkach nie masz tygodnia na zaplanowanie okna serwisowego. Masz tyle, ile zajmie komuś przeczytanie opublikowanego badania. W tym przypadku było to pięć dni.

Trzecia jest architektoniczna i wynika z tego, co atakujący robił po ucieczce. Sięgał do serwerów pośredniczących MID, czyli do komponentów łączących platformę z siecią wewnętrzną. Przejęcie systemu zarządzania przepływami pracy nie kończy się na tym systemie — to jest ten sam wzorzec, który opisywaliśmy przy platformach AI trzymających klucze do wszystkiego, co łączą. Pytanie brzmi nie „czy ta platforma jest załatana", lecz „do czego sięga jej tożsamość, gdy ktoś już w niej jest".

Jedna myśl na koniec

Skoordynowane ujawnianie podatności wymyślono w czasach, gdy producent wydawał jedną łatkę i wszyscy klienci nakładali ją mniej więcej wtedy, kiedy chcieli — a badacz czekał z publikacją, żeby dać im szansę. Ta procedura zakłada, że istnieje wspólny moment, w którym świat staje się bezpieczniejszy. Model hybrydowy ten moment rozdzielił na dwa i ustawił publikację przy tym drugim. Producent chroni swoją chmurę natychmiast, bo może; klient chroni siebie wtedy, gdy dostanie łatkę i zdąży ją nałożyć — a instrukcję, jak go zaatakować, ma już wtedy każdy. To nie jest zarzut wobec nikogo z uczestników. To jest obserwacja, że reguła, którą wszyscy grają uczciwie, przestała rozkładać ryzyko równo — i że najgorszy moment na bycie klientem samodzielnie hostowanym to dziś dokładnie ten, w którym producent ogłasza, że problem został rozwiązany.

Źródła

Searchlight Cyber — oryginalne badanie „Smashing the ServiceNow Sandbox", z opisem dwuwarstwowej architektury piaskownicy, mechanizmu ucieczki przez GlideRecord.addQuery() i gs.include(), osią czasu zgłoszenia z 1 kwietnia 2026 oraz opisem wprowadzonego przez ServiceNow mechanizmu Guarded Script: https://slcyber.io/research-center/smashing-the-servicenow-sandbox-pre-authentication-rce/

Help Net Security — relacja z obserwacji eksploatacji w realnym ruchu, z osią czasu wydania łatek 13 lipca i pierwszych ataków 18 lipca oraz stanowiskiem ServiceNow o braku dowodów na ataki wobec instancji hostowanych przez producenta: https://www.helpnetsecurity.com/2026/07/20/servicenow-cve-2026-6875-exploited/

The Hacker News — omówienie zawierające sprostowanie firmy Defused, według którego przechwycony ładunek odpowiada jednak kodowi demonstracyjnemu opublikowanemu przez Searchlight Cyber, wbrew pierwotnej informacji o odmiennej ścieżce ucieczki: https://thehackernews.com/2026/07/critical-servicenow-ai-platform-flaw.html

BleepingComputer — pierwotna relacja z obserwacji Defused wraz z cytatem z komunikatu badaczy oraz informacją, że w oficjalnym komunikacie ServiceNow podtrzymuje brak wiedzy o atakach na swoje instancje: https://www.bleepingcomputer.com/news/security/critical-servicenow-code-execution-flaw-now-exploited-in-attacks/

SecurityWeek — potwierdzenie, że aktualizacja dla instancji hostowanych przez producenta została wdrożona wcześniej, a klienci samodzielnie hostujący musieli nałożyć łatki własnoręcznie: https://www.securityweek.com/exploitation-of-servicenow-vulnerability-seen-days-after-disclosure/