CVE-2026-22704: Stored XSS w HAX CMS 24.x zagraża sesjom administratorów - Security Bez Tabu

CVE-2026-22704: Stored XSS w HAX CMS 24.x zagraża sesjom administratorów

Cybersecurity news

Wprowadzenie do problemu / definicja

Podatność CVE-2026-22704 dotyczy HAX CMS 24.x i została sklasyfikowana jako Stored Cross-Site Scripting. Ten typ luki polega na trwałym zapisaniu złośliwego kodu w aplikacji, a następnie jego wykonaniu w przeglądarce kolejnych użytkowników, którzy otworzą spreparowaną treść. W analizowanym przypadku problem wynika z możliwości przesłania pliku HTML zawierającego aktywny kod, który nie jest odpowiednio oczyszczany przed publikacją.

Z perspektywy bezpieczeństwa to scenariusz szczególnie groźny, ponieważ atak nie wymaga bezpośredniej interakcji między napastnikiem a ofiarą w czasie rzeczywistym. Wystarczy jednorazowe umieszczenie złośliwego zasobu w systemie, aby kolejne odwiedziny użytkowników uprzywilejowanych mogły doprowadzić do wykonania kodu w kontekście ich sesji.

W skrócie

CVE-2026-22704 umożliwia uwierzytelnionemu użytkownikowi o ograniczonych uprawnieniach przesłanie pliku HTML z osadzonym skryptem. Jeżeli taki plik zostanie później otwarty przez innego użytkownika, w tym administratora, kod może wykonać się w ramach zaufanego origin aplikacji.

  • dotyczy linii HAX CMS 24.x,
  • wektor ataku opiera się na uploadzie pliku HTML,
  • warunkiem wykorzystania jest brak skutecznej sanitizacji treści,
  • skutkiem może być przejęcie sesji lub wykonanie działań w imieniu ofiary,
  • zagrożenie rośnie, gdy pliki użytkowników są serwowane w tej samej domenie co panel administracyjny.

Kontekst / historia

Systemy CMS od lat pozostają częstym celem ataków opartych na XSS, zwłaszcza gdy umożliwiają użytkownikom przesyłanie i publikowanie treści o aktywnym charakterze. Funkcje uploadu są wygodne operacyjnie, ale w praktyce często stają się źródłem podatności, jeśli aplikacja dopuszcza formaty takie jak HTML lub SVG bez pełnej walidacji i bezpiecznego modelu publikacji.

W przypadku HAX CMS publiczny opis luki wskazuje na podatność w linii 24.x oraz istnienie proof-of-concept potwierdzającego realność ataku. Sama technika nie jest nowa, jednak jej znaczenie pozostaje wysokie, ponieważ trwały XSS w środowisku zarządzania treścią może szybko stać się punktem wyjścia do przejęcia kont uprzywilejowanych, modyfikacji zawartości serwisu lub dalszego rozwoju incydentu.

Analiza techniczna

Mechanizm wykorzystania luki jest stosunkowo prosty. Atakujący loguje się do aplikacji i korzysta z funkcji uploadu plików. Następnie przesyła dokument HTML zawierający osadzony ładunek JavaScript. Jeżeli aplikacja zapisze plik i udostępni go bez neutralizacji aktywnej zawartości, otwarcie takiego zasobu przez inną osobę spowoduje wykonanie kodu po stronie przeglądarki.

Klucz problemu wynika z połączenia kilku czynników: aplikacja akceptuje pliki HTML, nie sanitizuje ich zawartości w wystarczającym stopniu i publikuje je w sposób umożliwiający uruchomienie kodu. Gdy dodatkowo plik jest dostępny w tej samej domenie co panel administracyjny, złośliwy skrypt działa w kontekście zaufanej aplikacji.

W praktyce umożliwia to między innymi odczyt danych dostępnych w interfejsie, wykonywanie żądań jako ofiara, manipulowanie elementami panelu czy przygotowanie dalszych etapów ataku. W zależności od architektury wdrożenia i dodatkowych zabezpieczeń możliwe są następujące scenariusze:

  • pozyskanie tokenów lub danych dostępnych w drzewie DOM,
  • wykonywanie akcji administracyjnych z użyciem aktywnej sesji ofiary,
  • modyfikacja interfejsu w celu phishingu wewnętrznego,
  • dodanie nowych kont lub zmiana konfiguracji systemu,
  • utrwalenie dostępu do środowiska po skutecznym wykorzystaniu sesji administratora.

Publicznie opisany proof-of-concept nie oznacza automatycznie pełnej kompromitacji każdej instalacji, ale potwierdza, że wektor wejściowy jest realistyczny, a sama luka może zostać wykorzystana przy relatywnie niskim poziomie złożoności ataku.

Konsekwencje / ryzyko

Wpływ podatności zależy od tego, kto w danej instancji HAX CMS może przesyłać pliki oraz jakie uprawnienia mają potencjalne ofiary. Jeżeli upload jest dostępny dla autorów, redaktorów lub innych użytkowników niskiego poziomu, luka może zostać wykorzystana zarówno przez osobę działającą wewnętrznie, jak i przez napastnika, który przejął konto o ograniczonych uprawnieniach.

Najpoważniejsze konsekwencje obejmują przejęcie sesji administratora, nieautoryzowaną zmianę treści i ustawień, naruszenie poufności danych obsługiwanych w panelu oraz wykorzystanie systemu do dalszych ataków na innych użytkowników. Szczególnie niebezpieczny jest trwały charakter podatności: złośliwy plik pozostaje aktywny do momentu jego wykrycia i usunięcia.

Ryzyko rośnie w środowiskach, które nie stosują restrykcyjnej polityki Content Security Policy, nie izolują plików użytkowników od głównej aplikacji lub nie prowadzą monitoringu podejrzanych uploadów. W takich warunkach Stored XSS może stać się praktycznym wektorem eskalacji incydentu.

Rekomendacje

Organizacje korzystające z HAX CMS powinny potraktować tę lukę priorytetowo i zweryfikować, czy używana instancja należy do podatnej linii wersji. Niezależnie od dostępności oficjalnej poprawki warto wdrożyć działania ograniczające ekspozycję już na poziomie konfiguracji oraz kontroli dostępu.

  • sprawdzić, czy środowisko działa na podatnej wersji HAX CMS 24.x,
  • ograniczyć lub czasowo wyłączyć możliwość przesyłania plików HTML przez użytkowników nieuprzywilejowanych,
  • wymusić walidację typu i zawartości pliku po stronie serwera,
  • blokować publikację aktywnej zawartości HTML, SVG i podobnych formatów, jeśli nie są niezbędne,
  • serwować pliki użytkowników z odseparowanej domeny lub subdomeny,
  • wdrożyć silną politykę CSP ograniczającą wykonywanie nieautoryzowanych skryptów,
  • przeanalizować uprawnienia związane z uploadem i edycją treści,
  • monitorować logi pod kątem plików HTML i nietypowych rozszerzeń,
  • przejrzeć historię przesłanych zasobów i usunąć podejrzane pliki,
  • zresetować aktywne sesje administracyjne w przypadku podejrzenia wykorzystania luki.

Z długofalowej perspektywy warto przyjąć model, w którym treści użytkowników są konwertowane do bezpiecznych formatów pasywnych, a strefa aplikacyjna jest wyraźnie oddzielona od strefy plików przesyłanych przez użytkowników. To właśnie brak takiej separacji najczęściej powoduje, że pozornie prosty błąd uploadu przeradza się w incydent wysokiego ryzyka.

Podsumowanie

CVE-2026-22704 pokazuje, że funkcja uploadu plików może stać się krytycznym wektorem ataku, jeśli aplikacja dopuszcza publikację aktywnej zawartości bez odpowiednich zabezpieczeń. W HAX CMS 24.x problem dotyczy trwałego XSS uruchamianego przez przesłany plik HTML, co może prowadzić do przejęcia sesji, nadużycia uprawnień i dalszej kompromitacji środowiska.

Dla administratorów i zespołów bezpieczeństwa najważniejsze są szybka weryfikacja ekspozycji, ograniczenie możliwości uploadu aktywnych formatów oraz wdrożenie warstwowych zabezpieczeń, które uniemożliwią wykonywanie niezaufanego kodu w kontekście aplikacji.

Źródła