Zgłoszenie wpłynęło pierwszego kwietnia

1 kwietnia 2026 roku Adam Kues z Assetnote, badawczego ramienia Searchlight Cyber, przesłał ServiceNow raport opisujący sposób uruchomienia kodu na ServiceNow AI Platform całkowicie bez danych uwierzytelniających. Firma zareagowała szybko. We własnej relacji z ujawnienia zespół badawczy odnotowuje, że ServiceNow "wdrożył silne środki zaradcze na wszystkich instancjach chmurowych w ciągu 24 godzin od naszego zgłoszenia", a w kolejnych tygodniach dostarczył poprawki usuwające przyczyny problemu. Każdy klient korzystający z instancji hostowanej przez ServiceNow był chroniony już na początku kwietnia, bez konieczności podejmowania jakichkolwiek działań, a nawet bez wiedzy o sprawie.

Klienci utrzymujący własne instalacje nie usłyszeli nic aż do 13 lipca, gdy ServiceNow opublikował biuletyn bezpieczeństwa KB3137947 i wydał aktualizacje dla wdrożeń self-hosted. Podatność jest śledzona jako CVE-2026-6875. ServiceNow, występując jako własna CNA, przypisał jej ocenę CVSS 4.0 na poziomie 9,5 na 10. Wektor wskazuje wysoką złożoność ataku, ale żadnych wymaganych uprawnień i żadnej interakcji użytkownika, a właśnie ta kombinacja czyni instancję osiągalną z internetu interesującą dla kogoś, kto skanuje sieć na dużą skalę.

Między tymi dwiema datami leży 103 dni. Dla firmy SaaS jest to dobrze poprowadzone skoordynowane ujawnienie. Dla tej części jej klientów, która utrzymuje platformę samodzielnie, jest to kwartał z krytyczną luką sprzed uwierzytelnienia, którą dostawca zamknął już wcześniej we własnym środowisku.

Sandbox, który zgodził się wykonać JavaScript

Podatność tkwi w sandboxie ServiceNow AI Platform, czyli w warstwie izolacji, która ma pozwalać kodowi platformy działać bez sięgania tam, gdzie sięgać nie powinien. Punktem wejścia jest API GlideRecord, które obsługuje wykonywanie JavaScriptu wewnątrz filtrów zapytań. Dane wprowadzone przez użytkownika docierały do wywołania addQuery z przedrostkiem javascript:, a platforma je wykonywała.

Drugi sandbox miał przechwytywać dokładnie takie przypadki i blokować niebezpieczne funkcje. Badacze obeszli go łańcuchem gadżetów zbudowanym z Object.clone oraz Class.create.constructor, które razem dają dowolne wykonanie funkcji podczas script includes. Zademonstrowanym punktem wejścia był endpoint /assessment_thanks.do poprzez parametr sysparm_assessable_type, a żadne z tych działań nie wymagało zalogowania.

To, co zyskuje w ten sposób napastnik, nie jest przyczółkiem w bocznym zakątku produktu. Analiza Searchlight opisuje odczyt danych z tabel, zakładanie kont administratorów oraz uruchamianie poleceń powłoki na dowolnych skonfigurowanych serwerach pośredniczących MID Server, które, jak zauważają badacze, stoją zwykle wewnątrz sieci wewnętrznych firm. MID Server to element sięgający z powrotem w głąb środowiska, aby inwentaryzować zasoby i uruchamiać automatyzację. Jest mostem, a most jest osiągalny z poziomu tej luki.

Kto naprawdę ponosił ryzyko

Zwyczajowy odruch w europejskich zarządach mówi, że self-hosting to wybór ostrożny. Dane zostają na własnym sprzęcie, pytanie o miejsce ich przechowywania da się zamknąć w jednym zdaniu, a nadzorcy nie trzeba pokazywać kłopotliwego schematu. W regulowanych branżach Unii Europejskiej, w administracji publicznej, w bankowości i wśród większych grup typu Mittelstand właśnie ten odruch tłumaczy, dlaczego znacząca część środowisk ServiceNow nie działa w chmurze ServiceNow.

Ten biuletyn odwraca taką logikę. Klienci, którzy wybrali chmurę dostawcy, byli chronieni już w pierwszych dniach kwietnia przez środek zaradczy, o który nigdy nie musieli prosić. Klienci, którzy w imię kontroli wybrali samodzielne utrzymanie, ponosili ryzyko nieuwierzytelnionego zdalnego wykonania kodu przez kwiecień, maj, czerwiec i pół lipca, a informację otrzymali dopiero wtedy, gdy poprawka była gotowa do wydania. Kontrola nad wdrożeniem okazała się oznaczać własność okna ekspozycji.

Nic z tego nie czyni postępowania ServiceNow niewłaściwym. Wdrożenie środków zaradczych w środowisku prowadzonym przez samego dostawcę jest po prostu szybsze niż dostarczenie poprawek do środowiska cudzego, a wstrzymanie szczegółów biuletynu do czasu, aż klienci będą mogli działać, to standardowa praktyka, a nie ukrywanie faktów. Lekcja operacyjna jest węższa i bardziej użyteczna: "dostawca to naprawił" oraz "my mamy to naprawione" to dwa różne stwierdzenia, a w tym przypadku dzieliło je sto dni.

Oba stwierdzenia są prawdziwe jednocześnie

W weekend 18 i 19 lipca grupa wywiadu o zagrożeniach Defused zgłosiła aktywne wykorzystanie podatności, przy czym pierwsze próby zaobserwowano w piątek 17 lipca. Biuletyn ServiceNow, według stanu na poniedziałek rano, nadal stwierdza, że firma "nie ma obecnie wiedzy o wykorzystaniu wymierzonym w instancje ServiceNow". Czytane obok siebie wygląda to na dostawcę opieszałego w przyznawaniu racji.

Sprawa jest ciekawsza, a jej wyjaśnienie stanowi sedno tej historii. Obie strony mierzą różne populacje. ServiceNow dysponuje bezpośrednią telemetrią ze środowiska, które hostuje, a to środowisko jest zabezpieczone od początku kwietnia, więc naprawdę nic nie jest tam wykorzystywane. Defused obserwuje ruch w całym internecie, czyli tam, gdzie żyją instancje self-hosted. Populacja, której dostawca nie widzi, to dokładnie ta populacja, która wciąż pozostaje bez poprawki.

Zdanie dostawcy jest zatem prawdziwe i jednocześnie bezużyteczne jako dana wejściowa o ryzyku dla Państwa organizacji. "Brak potwierdzonego wykorzystania" ze strony dostawcy SaaS to stwierdzenie o środowisku samego dostawcy, o ile nie powiedziano wyraźnie inaczej. Przy samodzielnym utrzymaniu oprogramowania jedynym stanem wykorzystania, który opisuje rzeczywistą sytuację, jest ten wyprowadzony z własnych dzienników.

Exploit nie czekał na proof of concept

Defused precyzyjnie opisał to, co zaobserwował. Ładunki, jak podano, "trafiają w ten sam punkt sprzed uwierzytelnienia, który udokumentował @SLCyberSec (/assessment_thanks.do), ale gadżet ucieczki z sandboxa osiąga ten sam prymityw wykonania kodu inną drogą niż ich opublikowany PoC". Napastnicy nie odtwarzali exploita badaczy. Osiągnęli ten sam prymityw niezależnie, wykonując własną pracę od tego samego punktu wyjścia.

Ten szczegół rozbiera nawyk planistyczny rozpowszechniony w organizacjach ze sformalizowanym zarządzaniem zmianą, czyli traktowanie publikacji publicznego proof of concept jako momentu uruchomienia zegara i łatanie w kolejnym oknie serwisowym. Tutaj niezależna zdolność pojawiła się równocześnie z publiczną analizą, a nie po niej, a sam biuletyn z 13 lipca był ostatnim wiarygodnym ostrzeżeniem, jakie ktokolwiek miał otrzymać.

Co sprawdzić przed wtorkiem

Zacząć należy od rodziny wydania, ponieważ nazwy poprawek nie są intuicyjne. Wersje z poprawką to Brazil EA i Brazil GA, Australia Patch 2, Zurich Patch 7b lub Zurich Patch 9 oraz Yokohama Patch 12 Hot Fix 1b lub Yokohama Patch 13. Wszystko poniżej właściwej granicy pozostaje podatne, a instancja self-hosted, która od 13 lipca nie miała okna serwisowego, nie została przez nikogo naprawiona w imieniu jej właściciela.

Następnie warto przyjąć założenie, że okno ekspozycji miało znaczenie. Należy wyciągnąć dzienniki dostępu dla /assessment_thanks.do i przyjrzeć się szczególnie parametrowi sysparm_assessable_type. Zakładanie kont administratorów trzeba przejrzeć w całym okresie, a nie tylko w ostatnich dwóch tygodniach, ponieważ luka pozwala napastnikowi takie konto utworzyć. Potem przychodzi kolej na serwery MID, gdzie należy poszukać nieoczekiwanego uruchamiania procesów i pamiętać, że te maszyny stoją wewnątrz sieci wewnętrznej, a nie przed nią, co zamienia błąd platformy w problem ruchu poprzecznego.

Jeśli cokolwiek się znajdzie, zegar jest nie tylko techniczny, ale i regulacyjny. Dla podmiotów kluczowych i ważnych w Unii Europejskiej dyrektywa NIS2 wymaga wczesnego ostrzeżenia skierowanego do krajowego CSIRT w ciągu 24 godzin od powzięcia wiedzy o poważnym incydencie oraz pełniejszego zgłoszenia w ciągu 72 godzin. W Wielkiej Brytanii, gdzie NIS2 nie obowiązuje, drogą zgłoszenia pozostaje NCSC, a ta sama praca dowodowa decyduje o tym, czy zgłoszenie ma wartość.

Czytaj dalej: Jedno żądanie mogło przejąć twoją witrynę WordPress  |  Łatanie SharePointa już nie zamyka drzwi