CVE-2026-42223

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, 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.

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.

Nginx UI przed wersją 2.4.1 odrzuca w zwykłym API konfiguracji HTTP ograniczone dyrektywy Nginx, takie jak load_module, js_import i js_content. Jednak interfejs konfiguracji MCP pozwala uwierzytelnionemu użytkownikowi zapisać i zastosować równoważną ograniczoną zawartość konfiguracji. Umożliwia to załadowanie ngx_http_js_module.so, importowanie kontrolowanego przez atakującego JavaScriptu, przeładowanie Nginx i wykonanie NJS w kontekście workerów Nginx. Problem naprawiono w wersji 2.4.1.

Nginx UI od wersji 2.0.0-rc.6 do 2.4.1, narzędzie MCP nginx_config_add zapisuje pliki konfiguracyjne Nginx na dysk i wyzwala przeładowanie Nginx bez wywołania config.ValidateConfigFile. Identyczny przepływ w API REST (POST /api/configs) wywołuje tę funkcję i poprawnie odrzuca niebezpieczne dyrektywy. Uwierzytelniony atakujący może wykorzystać tę lukę do zapisania plików konfiguracyjnych zawierających dowolną zablokowaną dyrektywę (perl, js_import, load_module, user root itp.), omijając całą warstwę bezpieczeństwa nginx-ui. Na serwerze z modułem Perl, njs lub Lua Nginx jest to zdalne wykonanie kodu po uwierzytelnieniu. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1, wewnętrzny plik config/validation.go (ValidateConfigFile) jest kontrolą bezpieczeństwa blokującą niebezpieczne dyrektywy nginx — js_*, perl_*, load_module modułów njs/perl oraz user root. Jest egzekwowany na trzech z czterech ścieżek zapisu konfiguracji: api/config/add.go, api/config/modify.go i mcp/config/config_modify.go. Czwarta ścieżka — narzędzie MCP nginx_config_add (mcp/config/config_add.go) — NIE wywołuje tej funkcji: zapisuje dostarczoną przez wywołującego zawartość bezpośrednio na dysk i przeładowuje nginx. Uwierzytelniony wywołujący MCP (lub agent MCP zaindukowany przez prompt injection) może więc wstrzyknąć dokładnie te dyrektywy, które kontrola ma blokować, prowadząc do wykonania kodu nginx na wdrożeniach, gdzie dostępny jest moduł njs/perl (np. oficjalny obraz Docker). Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1, config.ValidateConfigDirectives dzieli konfigurację po nowych liniach i sprawdza tylko pierwszy token dyrektywy w każdej linii, mimo że Nginx dopuszcza wiele dyrektyw oddzielonych średnikami w jednej linii. Uwierzytelniony wywołujący może umieścić nieszkodliwą dyrektywę na początku, a później w tej samej linii ograniczoną dyrektywę load_module, js_import, perl lub user root, albo użyć nieograniczonej dyrektywy include do załadowania ograniczonej zawartości. Te mechanizmy omijają walidację na ścieżkach zapisu REST, nginx_config_modify, site i stream; gdy dostępny jest moduł wykonywalny, wstrzyknięta konfiguracja może wykonać kod w kontekście workerów Nginx. Problem naprawiono w wersji 2.4.1.