ServiceNow opublikował poprawki dla czterech poważnych podatności dotyczących swojej platformy AI Platform. Szczególną uwagę zwracają trzy błędy ocenione maksymalną możliwą wartością CVSS 10.0, które w określonych warunkach mogły zostać wykorzystane przez nieuwierzytelnionego atakującego.
To właśnie brak konieczności posiadania konta w systemie sprawia, iż luki są szczególnie groźne. W zależności od wykorzystanego błędu możliwe było wykonanie dowolnego kodu, eskalacja uprawnień lub przeprowadzenie SQL Injection prowadzącego do odczytu i modyfikacji danych instancji.
27 sierpnia 2026 roku ServiceNow poinformował o podatnościach i udostępnił poprawki dla obsługiwanych wersji platformy. Producent przekazał również, iż nie posiada informacji wskazujących na aktywne wykorzystanie błędów w rzeczywistych atakach.
Trzy różne błędy, jeden bardzo poważny problem
Najważniejsze jest to, iż nie mamy tutaj do czynienia z jedną podatnością posiadającą kilka wariantów exploita. ServiceNow załatał trzy niezależne problemy występujące w różnych komponentach platformy.
Wszystkie trzy otrzymały maksymalną ocenę CVSS 10.0, co oznacza, iż według producenta łączą bardzo wysoką łatwość wykorzystania z potencjalnie pełnym wpływem na poufność, integralność i dostępność danych.
Podatności zostały oznaczone jako:
- CVE-2026-18885 – Code Injection w GraphQL Composite Data API,
- CVE-2026-18886 – problem związany z niewłaściwą kontrolą dostępu w procesorze obrazów konfiguracji,
- CVE-2026-74820 – SQL Injection umożliwiające wykonywanie dowolnych zapytań SQL.
Wspólnym elementem luk jest możliwość wykorzystania ich przez atakującego bez konieczności wcześniejszego uwierzytelnienia. To właśnie ten aspekt znacząco zwiększa potencjalne ryzyko, szczególnie w przypadku instancji dostępnych z Internetu.
CVE-2026-18885 – Code Injection w GraphQL API
Pierwsza z podatności, CVE-2026-18885, dotyczy mechanizmu Code Injection w komponencie GraphQL Composite Data API.
GraphQL jest coraz częściej wykorzystywany jako warstwa komunikacyjna pomiędzy aplikacjami a backendem. Pozwala klientowi precyzyjnie określić, jakie dane chce pobrać lub zmodyfikować. Jednocześnie rozbudowane implementacje GraphQL mogą posiadać bardzo szeroką powierzchnię ataku, szczególnie gdy dane przekazywane przez użytkownika są wykorzystywane przez dodatkowe mechanizmy backendowe.
W tym przypadku podatność mogła pozwolić nieuwierzytelnionemu atakującemu na wykonanie dowolnego kodu oraz dostęp do danych znajdujących się w instancji ServiceNow. W zależności od konfiguracji i dostępnych komponentów skutki takiego ataku mogły obejmować również modyfikację informacji przetwarzanych przez platformę.
Podatności typu Code Injection są szczególnie niebezpieczne w dużych platformach enterprise, ponieważ pojedynczy punkt wejścia może prowadzić do znacznie większej liczby usług działających wewnątrz tej samej infrastruktury. Atakujący nie musi wtedy szukać osobnego exploita dla każdej funkcji – wykonanie kodu na odpowiednim komponencie może otworzyć drogę do dalszej eskalacji.
CVE-2026-18886 – niewłaściwa kontrola dostępu
Druga podatność, CVE-2026-18886, została powiązana z komponentem odpowiedzialnym za przetwarzanie obrazów konfiguracji systemu.
Problem dotyczy niewystarczającej kontroli dostępu. W praktyce oznacza to sytuację, w której użytkownik lub zewnętrzny podmiot może wykonać operację, do której normalnie nie powinien posiadać uprawnień.
Według dostępnych informacji skuteczne wykorzystanie podatności mogło umożliwić nieuwierzytelnionemu atakującemu tworzenie lub modyfikowanie danych instancji poza zakresem przewidzianych uprawnień. Tego typu luki mogą prowadzić do eskalacji uprawnień, ponieważ atakujący zyskuje możliwość manipulowania elementami, które w normalnych warunkach powinny być dostępne wyłącznie dla zaufanych użytkowników lub procesów systemowych.
W środowiskach takich jak ServiceNow problem może być szczególnie istotny. Platforma często przechowuje dane dotyczące procesów biznesowych, zgłoszeń IT, infrastruktury, użytkowników i automatyzacji. Możliwość nieautoryzowanej modyfikacji takich danych może więc prowadzić nie tylko do klasycznego naruszenia bezpieczeństwa, ale również zakłócenia procesów biznesowych organizacji.
CVE-2026-74820 – klasyczny SQL Injection
Trzecia podatność, CVE-2026-74820, dotyczy SQL Injection. Mimo iż to jedna z najstarszych i najlepiej znanych klas podatności, przez cały czas regularnie pojawia się w dużych aplikacjach i platformach enterprise. W tym przypadku problem związany był z dynamicznym mechanizmem obsługi schematów i klauzulą ORDER BY.
Jeżeli dane kontrolowane przez użytkownika trafiają do dynamicznie budowanego zapytania SQL bez odpowiedniej walidacji lub parametryzacji, atakujący może spróbować zmienić logikę wykonywanego zapytania. W zależności od implementacji może to umożliwić odczyt danych, ich modyfikację, a w skrajnych przypadkach również usunięcie informacji.
Według opisu podatności skuteczny exploit mógł pozwolić nieuwierzytelnionemu atakującemu na wykonywanie dowolnych zapytań SQL względem bazy danych instancji ServiceNow.
To szczególnie poważny scenariusz, ponieważ baza danych platformy może zawierać ogromną ilość informacji biznesowych. W zależności od sposobu wykorzystania ServiceNow mogą znaleźć się tam dane użytkowników, zgłoszenia serwisowe, informacje o infrastrukturze, procesach wewnętrznych oraz konfiguracji organizacji.
Kto powinien się martwić?
ServiceNow poinformował, iż poprawki zostały wdrożone w hostowanych instancjach platformy, natomiast partnerzy oraz organizacje korzystające z instalacji zarządzanych samodzielnie powinny zweryfikować swoje środowiska i zastosować odpowiednie aktualizacje.
W szczególności administratorzy powinni sprawdzić, z jakiej rodziny wersji korzysta ich instancja oraz czy zawiera ona poprawki wydane w sierpniu 2026 roku. Dotyczy to między innymi obsługiwanych wydań Xanadu, Yokohama, Zurich oraz Australia.
W przypadku platform enterprise aktualizacja powinna być jednak tylko pierwszym krokiem. Warto również przeanalizować, czy w okresie poprzedzającym instalację poprawek nie wystąpiły nietypowe działania związane z API, konfiguracją instancji lub dostępem do danych.
Jak szukać potencjalnych śladów exploita?
Ponieważ podatności mogły być wykorzystywane bez uwierzytelnienia, szczególną uwagę warto zwrócić na nietypową aktywność pochodzącą bezpośrednio z Internetu.
Dobrym punktem startowym będzie analiza logów dostępu do API, zwłaszcza zapytań kierowanych do komponentów GraphQL. Warto szukać dużej liczby nietypowych żądań, prób wykorzystania nieoczekiwanych parametrów oraz zapytań wykonywanych z adresów IP, które wcześniej nie komunikowały się z instancją.
W przypadku potencjalnego SQL Injection warto przeanalizować błędy aplikacyjne i anomalie związane z zapytaniami do bazy danych. Charakterystyczne mogą być nietypowe komunikaty błędów, zwiększona liczba nieudanych żądań lub próby manipulacji parametrami odpowiadającymi za sortowanie danych.
Administratorzy powinni również sprawdzić historię zmian konfiguracji i danych. Nieoczekiwane utworzenie nowych rekordów, modyfikacje istniejących obiektów lub zmiany uprawnień mogą wskazywać na próbę wykorzystania podatności związanej z niewłaściwą kontrolą dostępu.
W środowiskach posiadających SIEM warto przygotować korelację pomiędzy nietypowym ruchem HTTP, błędami aplikacji a późniejszymi zmianami konfiguracji. Pojedyncze zdarzenie może nie wyglądać podejrzanie, ale połączenie wielu anomalii zaistniałych w krótkim czasie pozwoli na znacznie szybsze ujawnienie próby ataku.
Trzy CVSS 10.0 jednocześnie to sygnał alarmowy
Ocena CVSS nie zawsze odzwierciedla rzeczywiste ryzyko dla konkretnej organizacji. Podatność oceniona na 10.0 może być trudna do wykorzystania w określonej konfiguracji, podczas gdy teoretycznie mniej poważny błąd okaże się aktywnie wykorzystywany przez cyberprzestępców.
W tym przypadku kombinacja kilku czynników sprawia jednak, iż ostrzeżenie należy potraktować poważnie.
Mamy trzy niezależne podatności, maksymalną ocenę CVSS, możliwość ataku przez sieć, brak konieczności posiadania konta oraz potencjalny dostęp do kodu lub danych. Dodatkowo błędy dotyczą platformy wykorzystywanej przez wiele dużych organizacji do obsługi procesów biznesowych i automatyzacji.
To właśnie połączenie tych elementów sprawia, iż administratorzy ServiceNow powinni potraktować aktualizację jako działanie priorytetowe.
Podsumowanie
ServiceNow załatał cztery poważne podatności bezpieczeństwa, z których trzy otrzymały maksymalną ocenę CVSS 10.0. Błędy mogły pozwolić nieuwierzytelnionemu atakującemu na wykonanie kodu, eskalację uprawnień lub przeprowadzenie SQL Injection prowadzącego do zdobycia danych i możliwości ich modyfikacji.
Na razie producent nie posiada informacji wskazujących na aktywne wykorzystanie podatności w rzeczywistych atakach. Historia cyberbezpieczeństwa pokazuje jednak, iż publiczne ujawnienie szczegółów dotyczących krytycznych błędów często gwałtownie przyciąga uwagę zarówno badaczy, jak i cyberprzestępców.
W przypadku organizacji korzystających z ServiceNow najważniejszym działaniem pozostaje szybkie zastosowanie poprawek oraz przegląd logów pod kątem nietypowej aktywności. Szczególnie warto pamiętać, iż w tym przypadku potencjalny atakujący nie musiał zaczynać od phishingu, skradzionego hasła czy przejętego konta. Wystarczyło znaleźć podatny punkt wejścia.
Źródła:
https://www.cve.org/CVERecord?id=CVE-2026-18885
https://www.slcyber.io/research/smashing-the-servicenow-sandbox-pre-authentication-rce
https://thehackernews.com/2026/08/three-cvss-100-servicenow-flaws-could.html
