W skrócie. Organizacje korzystające z oprogramowania Verint Verba do nagrywania rozmów lub monitoringu jakości są zagrożone. Nieuwierzytelniony atakujący może zostawić w logach „cyfrową minę”, która wybuchnie, gdy administrator spróbuje sprawdzić, kto logował się do systemu. Skutkiem może być kradzież danych, przejęcie kontroli nad platformą, a nawet dalszy ruch wewnątrz sieci firmowej. Konieczna jest natychmiastowa aktualizacja.

TL;DR

  • Rodzina: Stored XSS (CWE-79) 1 umożliwiający wykonanie kodu JavaScript w przeglądarce administratora.
  • Produkt: Verint Verba 2 3 — system rejestracji rozmów stosowany w contact center i sektorze finansowym.
  • CVE: CVE-2026-21730 4, zgłoszenie koordynowane przez CERT Polska 5.
  • Wektor: wstrzyknięcie skryptu w polu nazwy użytkownika na ekranie logowania; kod zapisuje się w logach bez sanityzacji 6 7 i wykonuje przy ich przeglądaniu 8.
  • Uwierzytelnienie: nie jest wymagane 9.
  • Wersje podatne / poprawka: wszystkie poniżej 10.0.6; poprawka w wersji 10.0.6 10 11.

Wektor ataku

Podatność oznaczona identyfikatorem CVE (Common Vulnerabilities and Exposures, identyfikator publicznie znanej luki) CVE-2026-21730 4 dotyczy oprogramowania Verba 2 od producenta Verint 3. Jest to system często wykorzystywany w contact center i instytucjach finansowych do rejestracji i analizy interakcji z klientami. Luka została sklasyfikowana jako CWE-79 (Improper Neutralization of Input During Web Page Generation) 1, szerzej znana jako Stored XSS (Cross-site Scripting).

Atak typu Stored XSS polega na umieszczeniu przez atakującego złośliwego skryptu na serwerze docelowym w taki sposób, aby został on później wykonany w przeglądarce innej ofiary. W tym konkretnym przypadku ofiarą jest administrator systemu Verba, a miejscem przechowywania skryptu są logi aplikacji.

Przebieg ataku jest następujący:

  1. Próba logowania: Zdalny, nieuwierzytelniony atakujący przechodzi do panelu logowania systemu Verba 9.
  2. Wstrzyknięcie payloadu: W polu przeznaczonym na nazwę użytkownika atakujący wprowadza złośliwy kod JavaScript, opakowany w tagi HTML. W polu hasła może wpisać dowolną wartość.
  3. Zapis w logach: System Verba, rejestrując nieudaną próbę logowania, zapisuje podaną przez atakującego nazwę użytkownika w bazie danych logów 6, 12. Kluczowym elementem luki jest fakt, że dane te nie są w żaden sposób filtrowane ani „oczyszczane” (proces ten nazywamy sanityzacją) 7, 13. System zapisuje więc w logach pełny, złośliwy skrypt.
  4. Uruchomienie przez administratora: W momencie, gdy administrator systemu zaloguje się i otworzy panel przeglądania logów, aplikacja webowa pobiera zapisane dane i wyświetla je w przeglądarce 8, 14. Ponieważ złośliwy kod jest częścią danych, przeglądarka administratora interpretuje go i wykonuje.

Skutki wykonania takiego kodu w kontekście sesji administratora mogą być poważne. Atakujący może:

  • Przejąć sesję administratora: Kradnąc pliki cookie sesji, atakujący może zalogować się do systemu jako administrator bez znajomości hasła.
  • Wykonać akcje administracyjne: Zmienić konfigurację systemu, dodać nowych użytkowników lub usunąć istniejących.
  • Wykraść dane: Uzyskać dostęp do wrażliwych informacji przetwarzanych przez system Verba, takich jak nagrania rozmów, dane klientów czy wewnętrzne metadane.
  • Przeprowadzić dalsze ataki: Wykorzystać przejęte konto jako punkt startowy do ataków na inne systemy wewnątrz sieci firmowej (tzw. ruch lateralny).

Podatne są wszystkie wersje oprogramowania Verba poniżej 10.0.6 10.

Wskaźniki kompromitacji

Ten typ ataku nie generuje typowych wskaźników kompromitacji (IoC — Indicators of Compromise), takich jak hashe plików czy adresy IP serwerów C2 (Command and Control — serwer kontrolujący zainfekowane maszyny). Wskaźnikiem jest sama obecność nietypowych danych w logach systemowych.

Administratorzy powinni przeszukać logi nieudanych prób logowania pod kątem obecności fragmentów kodu HTML i JavaScript. Można to zrobić, wyszukując w logach charakterystycznych ciągów znaków, takich jak:

<script
onerror=
onload=
<svg
<img src
javascript:

Nie publikujemy działającego ładunku XSS. Należy zwrócić uwagę na każdą próbę logowania, w której nazwa użytkownika zawiera znaczniki HTML, procedury obsługi zdarzeń albo znaki < i >.

Co zrobić w 24-48h

Z uwagi na prostotę eksploatacji i potencjalnie wysokie ryzyko, rekomendujemy podjęcie natychmiastowych działań.

  1. Priorytet 1: Aktualizacja oprogramowania. Jedynym skutecznym i trwałym rozwiązaniem jest aktualizacja instancji Verint Verba do wersji 10.0.6 lub nowszej 11, 15. W tej wersji problem braku sanityzacji danych wejściowych został naprawiony.

  2. Priorytet 2: Audyt logów. Niezależnie od aktualizacji, należy przeprowadzić audyt logów nieudanych prób logowania. Celem jest ustalenie, czy podatność nie została już wykorzystana. Należy przeszukać logi pod kątem obecności kodu HTML/JavaScript w polach nazw użytkowników. Jeśli znajdzie się takie wpisy, należy założyć, że doszło do kompromitacji i rozpocząć procedurę reagowania na incydent.

  3. Priorytet 3: Ograniczenie dostępu (środek tymczasowy). Jeśli natychmiastowa aktualizacja jest niemożliwa, należy jako środek zaradczy ograniczyć dostęp sieciowy do panelu administracyjnego Verba wyłącznie do zaufanych adresów IP (np. wewnętrznej sieci SOC lub biurowego VPN). To nie eliminuje luki, ale znacząco utrudnia jej wykorzystanie przez zewnętrznego atakującego.

  4. Priorytet 4: Unieważnienie sesji. Po wdrożeniu aktualizacji rekomendujemy unieważnienie wszystkich aktywnych sesji administracyjnych, aby upewnić się, że żadna przejęta sesja nie pozostaje aktywna.

Dla polskich firm, zwłaszcza z sektora finansowego i obsługi klienta, gdzie systemy typu Verba są kluczowe dla zgodności z regulacjami i kontroli jakości, incydent tego typu może mieć poważne konsekwencje biznesowe i prawne, włączając w to naruszenie RODO (Rozporządzenie o Ochronie Danych Osobowych).

Atrybucja

Nie posiadamy informacji o aktywnych kampaniach wykorzystujących tę podatność. Analiza dotyczy samej luki w oprogramowaniu.

Zgłoszenie podatności zostało dokonane przez polskiego badacza bezpieczeństwa, Jana Czerlunczakiewicza z firmy STM Cyber 16. Proces odpowiedzialnego ujawniania informacji (responsible disclosure) był koordynowany przez zespół CERT Polska 5.

Co istotne, według publicznych informacji, producent oprogramowania, firma Verint, została wcześnie poinformowana o luce, jednak nie odpowiedziała na próby kontaktu ze strony zgłaszających 17. Mimo to, ostatecznie wydano poprawioną wersję oprogramowania.

Źródła

Zobacz też

Przypisy

  1. Typ podatności to Improper Neutralization of Input During Web Page Generation (XSS or ‘Cross-site Scripting’) (CWE-79). — cert.pl › CVE 2026 21730 ↩ ↩2

  2. Nazwa podatnego oprogramowania to Verba. — cert.pl › CVE 2026 21730 ↩ ↩2

  3. Producentem podatnego oprogramowania jest Verint. — cert.pl › CVE 2026 21730 ↩ ↩2

  4. Podatność CVE-2026-21730 została opublikowana 14 maja 2026 roku. — cert.pl › CVE 2026 21730 ↩ ↩2

  5. Zgłoszenie podatności do CERT Polska koordynowało proces ujawniania informacji. — cert.pl › CVE 2026 21730 ↩ ↩2

  6. Gdy zdalny, nieuwierzytelniony atakujący spróbuje się zalogować, używając niepoprawnej kombinacji nazwy użytkownika i hasła, nazwa użytkownika zostaje zapisana w logach aplikacji. — cert.pl › CVE 2026 21730 ↩ ↩2

  7. Z powodu braku sanityzacji danych wejściowych atakujący może wstrzyknąć złośliwy payload w polu nazwy użytkownika. — cert.pl › CVE 2026 21730 ↩ ↩2

  8. Payload zostanie wykonany w kontekście przeglądarki administratora w momencie, gdy administrator otworzy widok logów aplikacji. — cert.pl › CVE 2026 21730 ↩ ↩2

  9. Nieuwierzytelniony zdalny atakujący może próbować zalogować się używając niepoprawnej nazwy użytkownika i hasła. — nvd.nist.gov › CVE 2026 21730 ↩ ↩2

  10. Podatne są wszystkie wersje oprogramowania Verba poniżej 10.0.6. — cert.pl › CVE 2026 21730 ↩ ↩2

  11. Problem został naprawiony w wersji 10.0.6. — cert.pl › CVE 2026 21730 ↩ ↩2

  12. Wartość podanej nazwy użytkownika jest zapisywana w logach aplikacji. — nvd.nist.gov › CVE 2026 21730 ↩

  13. Brak sanityzacji danych wejściowych pozwala atakującemu na wstrzyknięcie złośliwego payloadu XSS w polu nazwy użytkownika. — nvd.nist.gov › CVE 2026 21730 ↩

  14. Payload zostanie wykonany w kontekście przeglądarki administratora, gdy administrator uzyska dostęp do przeglądarki logów aplikacji. — nvd.nist.gov › CVE 2026 21730 ↩

  15. Problem został naprawiony w wersji 10.0.6. — nvd.nist.gov › CVE 2026 21730 ↩

  16. Za zgłoszenie podatności podziękowano Janowi Czerlunczakiewiczowi (STM Cyber). — cert.pl › CVE 2026 21730 ↩

  17. Dostawca został wcześnie powiadomiony o tej podatności, ale nie odpowiedział na wiadomości. — nvd.nist.gov › CVE 2026 21730 ↩