Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
ServiceNow opublikował alert bezpieczeństwa po wykryciu nietypowej aktywności związanej z problemem, który w określonych warunkach mógł umożliwić nieautoryzowany dostęp do informacji w instancjach klientów. Początkowe sygnały mogły sugerować próbę naruszenia środowisk produkcyjnych, jednak dalsza analiza wskazała, że obserwowane działania były najprawdopodobniej efektem badań prowadzonych w ramach programów bug bounty.
To zdarzenie pokazuje, jak trudno w praktyce odróżnić legalne testy bezpieczeństwa od rzeczywistej aktywności ofensywnej, zwłaszcza gdy badacze wykonują sekwencje zapytań przypominające rekonesans lub walidację podatności.
W skrócie
ServiceNow wykrył anomalię dotyczącą dostępu do wybranych tabel w części instancji klientów i 5 czerwca 2026 roku wdrożył poprawkę bezpieczeństwa. Problem dotyczył środowisk działających na wydaniu Australia oraz niektórych starszych instancji z określonymi zmianami konfiguracyjnymi.
- wykryta słabość mogła umożliwić dostęp do informacji użytkownikowi nieuwierzytelnionemu,
- zakres wpływu nie obejmował wszystkich wdrożeń,
- producent ograniczył dostęp do endpointu wyłącznie dla użytkowników uwierzytelnionych,
- późniejsze ustalenia wskazały, że aktywność najpewniej pochodziła od badaczy bezpieczeństwa lub klientów prowadzących własne testy.
Kontekst / historia
Z ujawnionych informacji wynika, że podobne zgłoszenie trafiło do programu bug bounty ServiceNow już 22 kwietnia 2026 roku. Następnie 3 i 4 czerwca 2026 roku klienci zaczęli przekazywać zgłoszenia do własnych programów bug bounty dotyczące tego samego problemu.
5 czerwca 2026 roku wdrożono aktualizację bezpieczeństwa dla hostowanych instancji klientów. Dwa dni później, 7 czerwca, do programu bug bounty producenta wpłynął kolejny raport od dwóch badaczy, co dodatkowo wsparło hipotezę, że wykryta aktywność miała charakter badawczy, a nie była elementem potwierdzonej kampanii ataków.
Początkowa komunikacja była ostrożna i zakładała możliwość wykorzystania luki przeciwko środowiskom klientów. W kolejnej aktualizacji ServiceNow doprecyzował jednak, że dotychczasowe ustalenia wskazują raczej na działania uprawnionych badaczy bezpieczeństwa lub klientów prowadzących własną analizę.
Analiza techniczna
Problem dotyczył konfiguracji endpointu, który przed wdrożeniem poprawki mógł w określonych okolicznościach pozwolić użytkownikowi nieuwierzytelnionemu na uzyskanie niepożądanego dostępu do informacji przechowywanych w instancjach ServiceNow. Według producenta możliwe było skuteczne odpytywanie wybranych tabel należących do podzbioru klientów.
Najważniejszym elementem remediacji była zmiana konfiguracji ograniczająca dostęp do tego endpointu wyłącznie do użytkowników uwierzytelnionych. Wskazuje to, że źródłem problemu była niewystarczająca kontrola dostępu na poziomie ekspozycji interfejsu lub API, a nie klasyczna eskalacja uprawnień po zalogowaniu.
Istotne jest również to, że podatność nie miała charakteru uniwersalnego. Ryzyko dotyczyło przede wszystkim środowisk na wydaniu Australia oraz instancji starszych wersji platformy, w których wprowadzono określone zmiany konfiguracyjne. To typowy scenariusz dla rozbudowanych platform SaaS, gdzie wspólna baza technologiczna współistnieje z bardzo zróżnicowaną powierzchnią ataku zależną od konfiguracji konkretnego klienta.
Z perspektywy operacyjnej przypadek pokazuje także ograniczenia samej detekcji. Aktywność badaczy bug bounty mogła wyglądać jak standardowy rekonesans: powtarzalne zapytania, sprawdzanie zachowania endpointów, walidacja uprawnień i potwierdzanie zakresu odczytu. Bez kontekstu telemetrycznego takie działania łatwo zaklasyfikować jako potencjalny incydent bezpieczeństwa.
Konsekwencje / ryzyko
Najważniejszym ryzykiem była możliwość uzyskania niezamierzonego dostępu do informacji przez użytkownika nieuwierzytelnionego. Nawet jeśli zakres wpływu był ograniczony, samo odpytywanie wybranych tabel w środowisku enterprise może prowadzić do ujawnienia danych operacyjnych, metadanych systemowych lub informacji przydatnych w dalszych etapach potencjalnej kompromitacji.
Incydent ma także wymiar organizacyjny. Poza błędną kontrolą dostępu pojawia się ryzyko analityczne: legalna aktywność badawcza może uruchomić procedury reagowania, eskalację do SOC, wewnętrzne dochodzenia oraz komunikację kryzysową z klientami. To zwiększa koszty operacyjne i obciąża zespoły bezpieczeństwa.
Dla klientów korzystających z platform SaaS oznacza to konieczność traktowania konfiguracji jako integralnej części modelu bezpieczeństwa. Nawet przy usługach zarządzanych przez dostawcę niestandardowe ustawienia po stronie klienta mogą realnie wpływać na ekspozycję danych i poziom ryzyka.
Rekomendacje
Organizacje korzystające z ServiceNow powinny w pierwszej kolejności potwierdzić, czy ich instancje zostały objęte poprawką wdrożoną 5 czerwca 2026 roku oraz czy otrzymały bezpośrednie powiadomienie od producenta. Warto też przeprowadzić przegląd konfiguracji publicznie dostępnych endpointów i mechanizmów autoryzacji.
- zweryfikować logi dostępu do endpointów i zapytań do tabel pod kątem nietypowych odczytów,
- skorelować wykrytą aktywność z wewnętrznymi i zewnętrznymi programami bug bounty,
- przeanalizować niestandardowe zmiany konfiguracyjne w starszych instancjach,
- egzekwować zasadę domyślnego braku dostępu dla endpointów udostępniających dane,
- wdrożyć reguły detekcyjne odróżniające badania bezpieczeństwa od realnej eksploatacji,
- zaktualizować runbooki SOC i procedury triage o scenariusze obejmujące autoryzowane testy badaczy.
Dobrą praktyką jest również formalne uzgodnienie kanałów komunikacji między właścicielem programu bug bounty, zespołem bezpieczeństwa i operatorem platformy. Pozwala to szybciej odróżnić dozwolone testy od rzeczywistych prób naruszenia, szczególnie w środowiskach chmurowych i wielodostępnych.
Podsumowanie
Sprawa ServiceNow pokazuje, że granica między legalnym badaniem bezpieczeństwa a symptomami potencjalnego ataku bywa bardzo cienka. Wykryta słabość dotyczyła kontroli dostępu do endpointu i mogła umożliwić niepożądany dostęp do informacji w części instancji klientów.
Producent wdrożył poprawkę, zawęził dostęp do użytkowników uwierzytelnionych i wskazał, że zaobserwowana aktywność była najprawdopodobniej związana z badaniami bug bounty. Dla zespołów bezpieczeństwa to wyraźny sygnał, że skuteczna ochrona usług SaaS wymaga zarówno ścisłej kontroli konfiguracji, jak i dojrzałej analizy telemetrycznej.