Ivanti Neurons for ITSM łata dwie luki umożliwiające utrzymanie dostępu i wyciek danych sesyjnych

Wprowadzenie do problemu / definicja

Ivanti usunęło dwie podatności w platformie Neurons for ITSM, obejmującej zarówno wdrożenia lokalne, jak i środowiska chmurowe. Luki dotyczą mechanizmów kontroli dostępu oraz bezpieczeństwa warstwy aplikacyjnej i mogą prowadzić do utrzymania dostępu po dezaktywacji konta lub do pozyskania ograniczonych informacji z sesji innych użytkowników.

Choć producent nie potwierdził aktywnego wykorzystania tych błędów, problem ma istotne znaczenie operacyjne dla organizacji korzystających z systemu do zarządzania usługami IT, incydentami i zgłoszeniami.

W skrócie

• Ivanti załatało dwie podatności o średnim poziomie ważności w Neurons for ITSM.
• CVE-2026-4913 może umożliwić uwierzytelnionemu atakującemu zachowanie dostępu po wyłączeniu konta.
• CVE-2026-4914 to luka typu stored XSS, która przy interakcji użytkownika może prowadzić do ujawnienia ograniczonych informacji z innych sesji.
• Poprawki dostarczono w wersji 2025.4, a środowiska chmurowe miały zostać zabezpieczone wcześniej po stronie dostawcy.

Kontekst / historia

Neurons for ITSM to platforma wykorzystywana do obsługi procesów zarządzania usługami IT, incydentami, zgłoszeniami i zasobami. Z tego powodu jej bezpieczeństwo ma bezpośredni wpływ na ciągłość działania zespołów IT oraz ochronę danych operacyjnych.

Produkty Ivanti pozostają pod szczególną obserwacją rynku bezpieczeństwa po wcześniejszych incydentach i kampaniach wykorzystujących podatności w rozwiązaniach tego producenta. W praktyce oznacza to, że nawet luki oceniane jako średnie powinny być analizowane priorytetowo, zwłaszcza jeśli dotyczą systemów wspierających kluczowe procesy wewnętrzne.

W opisywanym przypadku producent wskazał, że błędy nie dotyczą innych produktów Ivanti i nie ma informacji o ich wykorzystaniu w realnych atakach. Mimo to publikacja poprawek oznacza, że organizacje korzystające z wersji lokalnych powinny potraktować aktualizację jako pilny element procesu zarządzania podatnościami.

Analiza techniczna

CVE-2026-4913 została opisana jako niewłaściwa ochrona alternatywnej ścieżki. Tego typu problem zwykle oznacza, że aplikacja poprawnie egzekwuje ograniczenia w jednym przepływie logiki, ale pozostawia inną drogę, która omija część mechanizmów autoryzacyjnych lub walidacyjnych.

W praktyce może to prowadzić do sytuacji, w której dezaktywacja konta nie unieważnia wszystkich istniejących kontekstów dostępu, sesji lub tokenów. Dla systemu ITSM oznacza to ryzyko dalszego korzystania z aplikacji przez użytkownika, który formalnie powinien już utracić uprawnienia.

CVE-2026-4914 to podatność typu stored XSS. W takim scenariuszu złośliwy kod zostaje zapisany po stronie aplikacji, a następnie uruchamia się w przeglądarce ofiary, gdy ta otworzy spreparowaną zawartość. Jeżeli luka występuje w elementach interfejsu współdzielonych przez wielu użytkowników, możliwe staje się przechwycenie części danych kontekstowych sesji, odczyt wybranych informacji widocznych w interfejsie lub wykonywanie działań w granicach uprawnień ofiary.

Istotne jest również to, że obie podatności wymagają uwierzytelnionego dostępu. Najbardziej realistyczny scenariusz zagrożenia obejmuje więc nadużycie konta wewnętrznego, przejęte dane logowania, konto partnera zewnętrznego lub ruch boczny po wcześniejszym naruszeniu innego elementu infrastruktury.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją CVE-2026-4913 jest możliwość utrzymania dostępu po administracyjnym wyłączeniu konta. Taki przypadek podważa skuteczność procedur offboardingu, reagowania na incydent oraz kontroli dostępu uprzywilejowanego.

Jeśli organizacja zakłada, że dezaktywacja konta natychmiast odcina użytkownika od systemu, luka tego typu może tworzyć fałszywe poczucie bezpieczeństwa i wydłużać czas obecności atakującego w środowisku.

W przypadku CVE-2026-4914 ryzyko dotyczy przede wszystkim naruszenia poufności danych dostępnych w interfejsie aplikacji oraz potencjalnego wykonywania akcji w kontekście przeglądarki innego użytkownika. W systemie ITSM mogą to być dane zgłoszeń, informacje o incydentach, rekordy zasobów, notatki operacyjne lub inne elementy workflow.

Ryzyko biznesowe zależy również od modelu wdrożenia. Dla klientów chmurowych poprawka została wdrożona po stronie dostawcy, co ogranicza okno ekspozycji. W środowiskach lokalnych poziom zagrożenia zależy od szybkości aktualizacji, dojrzałości zarządzania sesjami oraz zakresu ekspozycji aplikacji.

Rekomendacje

Organizacje korzystające z Ivanti Neurons for ITSM w modelu on-premises powinny niezwłocznie przejść do wersji 2025.4 i potwierdzić skuteczne wdrożenie poprawki we wszystkich instancjach, w tym w środowiskach testowych, zapasowych i pomocniczych.

Samo zainstalowanie aktualizacji nie powinno jednak kończyć procesu ograniczania ryzyka. Warto równolegle przeprowadzić dodatkowe działania weryfikacyjne i kontrolne.

• Przeanalizować aktywne sesje i wymusić ich unieważnienie po aktualizacji.
• Zweryfikować logi pod kątem dostępu z kont, które zostały wcześniej wyłączone lub ograniczone.
• Skontrolować pola i komponenty interfejsu użytkownika mogące przechowywać treści HTML lub skrypty.
• Ograniczyć ekspozycję paneli ITSM do zaufanych segmentów sieci oraz egzekwować MFA dla kont administracyjnych i uprzywilejowanych.
• Zrewidować procedury offboardingu tak, aby obejmowały także natychmiastowe unieważnianie sesji, tokenów i poświadczeń aplikacyjnych.
• Rozszerzyć monitoring o działania wykonywane po dezaktywacji kont oraz o anomalie w ruchu webowym mogące wskazywać na próbę wstrzyknięcia kodu.

Podsumowanie

Dwie załatane podatności w Ivanti Neurons for ITSM nie należą do kategorii krytycznych, ale ich charakter sprawia, że mają realne znaczenie dla bezpieczeństwa operacyjnego. Możliwość utrzymania dostępu po dezaktywacji konta uderza w podstawy kontroli tożsamości, a stored XSS w systemie ITSM może otworzyć drogę do wycieku danych kontekstowych i dalszych nadużyć.

Dla organizacji korzystających z wdrożeń lokalnych aktualizacja do wersji 2025.4 powinna być traktowana jako działanie pilne, połączone z przeglądem sesji, logów i polityk wycofywania dostępu.

Źródła

1. SecurityWeek — Two Vulnerabilities Patched in Ivanti Neurons for ITSM — https://www.securityweek.com/two-vulnerabilities-patched-in-ivanti-neurons-for-itsm/
2. Ivanti Advisory — Security Advisory: Ivanti Neurons for ITSM — https://hub.ivanti.com/