CVE-2026-84320

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.1 zawiera podatność, w której wygenerowane krótkie tokeny nie mają powiązanej długiej wartości Token, a funkcja DeleteUserTokens unieważnia wpisy w pamięci podręcznej tylko wtedy, gdy długie pole Token nie jest puste. Odwołany krótki token może pozostać w pamięci podręcznej i ponownie uwierzytelnić użytkownika, jeśli konto zostanie ponownie włączone przed wygaśnięciem wpisu, przywracając dostęp do tras HTTP lub WebSocket akceptujących uwierzytelnianie krótkim tokenem.