CVE-2026-84321

W Nginx UI od wersji 2.0.0 do 2.5.0 mechanizm AuthRequired akceptuje token cookie zarządzany przez przeglądarkę jako poświadczenie API, po tym jak front end zapisze JWT w tym cookie. Ponieważ punkty końcowe zarządzania nie wymagają powszechnie tokenu CSRF ani nie wykonują walidacji Origin lub Referer, zdalny atakujący może nakłonić przeglądarkę zalogowanego administratora do wysłania uwierzytelnionych żądań zmieniających stan z innej witryny, w tym POST /api/configs.

Nginx UI to internetowy interfejs użytkownika dla serwera Nginx. Od wersji 2.2.0 do 2.6.0, wbudowany odwrotny proxy nie zachowuje tożsamości zewnętrznego klienta używanej przez Gin, ponieważ backend nie ma konfiguracji zaufanego proxy. Żądania zarządzania mogą być przypisywane do loopback i przechodzić wyjątek listy dozwolonych IP dla loopback, chociaż nadal wymagane są prawidłowe poświadczenia. Nieudane logowania z różnych zewnętrznych klientów są również przypisywane do tego samego adresu loopback, co pozwala nieuwierzytelnionemu atakującemu na wywołanie wspólnego tymczasowego banu logowania dla uwierzytelniania hasłem lub OTP bez unieważniania istniejących sesji. Problem został naprawiony w wersji 2.6.0.

Nginx UI to interfejs webowy dla serwera Nginx. W wersjach 2.3.4 i wcześniejszych, uwierzytelniony użytkownik może przeprowadzić atak typu Server-Side Request Forgery (SSRF) poprzez utworzenie węzła klastra wskazującego na dowolny wewnętrzny adres URL.

W wersji 2.3.5 interfejsu użytkownika Nginx (nginx-ui) występuje podatność na nieautoryzowane przejęcie podczas początkowej instalacji, która jest eksponowana przez POST /api/install.

Nginx UI to interfejs webowy dla serwera Nginx. W wersjach od 2.0.0 do przed 2.3.8, nieautoryzowany atakujący sieciowy może przejąć początkowe konto administratora na świeżej instancji nginx-ui podczas pierwszej konfiguracji.

Nginx UI to interfejs webowy dla serwera Nginx. Od wersji 2.3.8 do 2.5.0 uwierzytelniony administrator z aktywną sesją może przesłać kontrolowany przez atakującego materiał klucza kopii zapasowej i pasujący manifest do POST /api/restore. Proces przywracania ufa dostarczonemu kluczowi, odszyfrowuje kontrolowaną treść i zastępuje plik app.ini, w tym chronione ustawienia poleceń nginx, takie jak TestConfigCmd. Wywołanie POST /api/nginx/test wykonuje przywrócone polecenie w kontekście środowiska Nginx UI.

Nginx UI, interfejs webowy dla serwera Nginx, przed wersją 2.3.8, udostępniał punkt końcowy przywracania kopii zapasowej (POST /api/restore), który był całkowicie nieautoryzowany przez pierwsze 10 minut po uruchomieniu procesu na świeżej instalacji. Nieautoryzowany zdalny atakujący mógł przesłać spreparowaną archiwum kopii zapasowej, co prowadziło do nadpisania pliku konfiguracyjnego aplikacji oraz bazy danych SQLite.

Nginx UI przed wersją 2.4.1 używa stałej wartości OAuth state w GetCasdoorUri i nie weryfikuje stanu w CasdoorCallback, co pozwala nieuwierzytelnionemu atakującemu na przejęcie sesji użytkownika.

Nginx UI to interfejs webowy dla serwera Nginx. Przed wersją 2.4.1 trasy mutacji konfiguracji HTTP wymagają RequireSecureSession, ale /mcp i /mcp_message wymagają tylko zwykłego uwierzytelnienia przed udostępnieniem nginx_config_add i nginx_config_modify. Użytkownik z włączonym OTP, posiadający zwykły JWT, ale bez ważnego X-Secure-Session-ID, może tworzyć lub modyfikować konfigurację Nginx i wywoływać przeładowanie przez MCP, omijając zamierzoną kontrolę step-up. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.3 zawiera podatność polegającą na tym, że funkcja AutoBackup.GetName zwraca nazwę kontrolowaną przez użytkownika bez odrzucania separatorów ścieżek lub komponentów katalogu nadrzędnego, a dalsze formatowanie nazwy pliku osadza ten wynik w końcowej nazwie archiwum. Uwierzytelniony użytkownik może spowodować, że filepath.Join rozwiąże wygenerowaną ścieżkę archiwum poza zwalidowanym katalogiem przechowywania, umożliwiając zapis archiwów kopii zapasowych z uprawnieniami procesu Nginx UI.