Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
ServiceNow poinformował o incydencie bezpieczeństwa związanym z podatnością, która mogła umożliwiać nieautoryzowany dostęp do danych przechowywanych w instancjach klientów. Problem dotyczył warstwy API i wpisuje się w kategorię błędów kontroli dostępu, w których mechanizmy autoryzacji nie ograniczają dostępu zgodnie z założonym modelem bezpieczeństwa.
Z perspektywy organizacji korzystających z platform ITSM i workflow jest to szczególnie istotne zagrożenie, ponieważ systemy tego typu przetwarzają dane operacyjne, administracyjne i techniczne, często o wysokiej wartości dla napastników.
W skrócie
Producent wdrożył poprawkę bezpieczeństwa 5 czerwca 2026 r. po wykryciu anomalii sugerujących aktywne wykorzystanie luki. Według ujawnionych informacji atakujący mogli odpytywać tabele danych w środowiskach klientów, a problem miał dotyczyć głównie instancji działających na wydaniu Australia lub starszych wersjach z określonymi modyfikacjami konfiguracyjnymi.
ServiceNow kontaktuje się bezpośrednio z klientami, których środowiska zostały uznane za potencjalnie dotknięte incydentem. Dla zespołów bezpieczeństwa oznacza to potrzebę szybkiej weryfikacji ekspozycji, przeglądu logów i oceny, czy mogło dojść do wycieku danych.
Kontekst / historia
Platformy klasy ITSM od lat stanowią atrakcyjny cel dla cyberprzestępców, ponieważ skupiają w jednym miejscu dużą ilość informacji o procesach biznesowych, użytkownikach, zasobach i incydentach operacyjnych. W wielu organizacjach ServiceNow pełni rolę centralnej platformy obsługi zgłoszeń, automatyzacji procesów i zarządzania usługami.
W ostatnich latach szczególnego znaczenia nabrało bezpieczeństwo interfejsów API. To właśnie API odpowiadają za komunikację pomiędzy modułami aplikacji, integracjami zewnętrznymi oraz narzędziami automatyzacji. Jeżeli w tym obszarze pojawia się błąd logiczny lub zbyt szeroko otwarty endpoint, napastnik może uzyskać dostęp do danych bez klasycznego przejęcia konta użytkownika.
Analiza techniczna
Z dostępnych informacji wynika, że incydent był związany z podatnością typu unauthenticated access flaw w jednym z endpointów API. W określonych scenariuszach możliwe było wykonywanie zapytań do danych klienta bez prawidłowego uwierzytelnienia. Poprawka wdrożona przez producenta miała ograniczyć dostęp do tego mechanizmu wyłącznie do użytkowników uwierzytelnionych.
W analizach administratorów wskazywano na ścieżkę powiązaną z funkcją related_list_edit, a szczególną uwagę zwrócono na endpoint /api/now/related_list_edit/create. Tego rodzaju błąd może oznaczać naruszenie granicy zaufania na poziomie API: publicznie dostępny endpoint akceptuje żądania bez aktywnej sesji lub tokenu, a następnie wykonuje operacje na tabelach aplikacji.
W praktyce skutkiem może być enumeracja rekordów, odpytywanie relacji danych lub pobieranie informacji z obszarów, które powinny być chronione. Nawet jeśli nie dochodzi do pełnego przejęcia instancji, sam odczyt danych biznesowych lub administracyjnych może stanowić poważne naruszenie bezpieczeństwa i punkt wyjścia do kolejnych etapów ataku.
W publikowanych analizach pojawiły się także wskaźniki kompromitacji, w tym zapytania API pochodzące z adresu IP 51.159.98.241. Tego typu artefakty mogą pomóc zespołom SOC i administratorom w retrospektywnym przeglądzie logów oraz ustaleniu, czy podobna aktywność występowała w ich środowisku.
Konsekwencje / ryzyko
Najpoważniejsze ryzyko dotyczy ujawnienia danych przechowywanych w tabelach instancji ServiceNow. Mogą to być zgłoszenia helpdesk, dane użytkowników, szczegóły konfiguracji usług, dokumentacja operacyjna, informacje o aktywach czy wpisy związane z obsługą incydentów bezpieczeństwa.
Takie dane mają wysoką wartość wywiadowczą. W praktyce często zawierają nazwy hostów, identyfikatory usług, szczegóły integracji, tokeny API, hasła tymczasowe oraz inne informacje techniczne, które mogą zostać wykorzystane do phishingu ukierunkowanego, eskalacji uprawnień lub ruchu bocznego w infrastrukturze.
Ryzyko nie ogranicza się wyłącznie do poufności danych. Organizacje mogą zostać zmuszone do przeprowadzenia analizy zakresu naruszenia, przeglądu dokumentacji incydentowej, rotacji poświadczeń oraz oceny obowiązków regulacyjnych. W środowiskach podlegających rygorystycznym wymaganiom zgodności taki incydent może skutkować dodatkowymi obowiązkami raportowymi i audytowymi.
Rekomendacje
Organizacje korzystające z ServiceNow powinny przede wszystkim potwierdzić status swojej instancji oraz sprawdzić, czy otrzymały oficjalne powiadomienie od producenta. Niezależnie od tego warto przeprowadzić własną analizę logów i zweryfikować, czy w środowisku nie występowały podejrzane żądania do wskazanych ścieżek API.
- zweryfikować, czy instancja działa na wersji objętej ryzykiem lub zawiera niestandardowe zmiany konfiguracji;
- przeanalizować logi API i logi dostępu z okresu poprzedzającego 5 czerwca 2026 r.;
- sprawdzić żądania do ścieżek związanych z
/api/now/related_list_edit; - zidentyfikować rekordy, które mogły zostać odczytane przez nieautoryzowane zapytania;
- ocenić, czy w zgłoszeniach i notatkach znajdowały się sekrety techniczne lub dane uwierzytelniające;
- przeprowadzić rotację haseł, tokenów, kluczy API i innych potencjalnie ujawnionych poświadczeń;
- upewnić się, że monitoring i retencja logów API są włączone na odpowiednim poziomie;
- wdrożyć dodatkowe reguły detekcji dla nietypowych żądań do wrażliwych endpointów REST.
Długoterminowo incydent wzmacnia potrzebę regularnych audytów konfiguracji bezpieczeństwa aplikacji SaaS, testów kontroli dostępu w API oraz ograniczania ilości wrażliwych danych przechowywanych w systemach ticketowych i workflow.
Podsumowanie
Incydent w ServiceNow pokazuje, że nawet pozornie ograniczony błąd autoryzacji w API może prowadzić do realnego zagrożenia dla poufności danych klientów. W środowiskach enterprise dostęp do rekordów operacyjnych i administracyjnych bywa równie niebezpieczny jak przejęcie konta, ponieważ umożliwia budowę szerszego obrazu infrastruktury i procesów organizacji.
Dla firm korzystających z platformy kluczowe są dziś szybka weryfikacja zakresu ekspozycji, analiza logów, identyfikacja potencjalnie ujawnionych informacji oraz rotacja wrażliwych poświadczeń. Z perspektywy obronnej najważniejsze pozostają twarde wymuszanie uwierzytelnienia, monitoring API i ograniczanie przechowywania sekretów w systemach operacyjnych.