CVE-2026-107813

W Nginx UI od wersji 2.0.0 do 2.5.0 mechanizm samodzielnej aktualizacji weryfikuje pobrany plik binarny wyłącznie za pomocą skrótu pochodzącego z tego samego serwera aktualizacji. Skompromitowane lustro lub atakujący w sieci mogą dostarczyć złośliwy plik wykonywalny wraz z pasującym skrótem, a aplikacja zainstaluje i uruchomi ten kod w kontekście procesu Nginx UI przy następnej aktualizacji.

W Nginx UI od wersji 2.0.0 do 2.5.0 zwykli uwierzytelnieni użytkownicy mogą uzyskać dostęp do /api/nodes i /api/nodes/:id, których odpowiedzi zawierają pole tokenu węzła. Ten sam token jest akceptowany jako X-Node-Secret przez AuthRequired i mapuje żądanie na initUser, co pozwala użytkownikowi podszyć się pod zaufany węzeł wobec osiągalnego członka klastra.

W Nginx UI od wersji 2.0.0 do 2.5.0 plik internal/backup/restore.go rozpakowuje wewnętrzne archiwa przed zastosowaniem flag restore_nginx i restore_nginx_ui oraz zezwala na dowiązania symboliczne wskazujące na aktywną ścieżkę konfiguracji Nginx. Uwierzytelniony użytkownik mogący tworzyć i przywracać kopie zapasowe może przygotować kopię, która umieszcza dowiązanie symboliczne w drzewie tymczasowym, a następnie zapisuje przez nie zwykły plik, nawet gdy obie flagi przywracania są wyłączone.

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.

W Nginx UI od wersji 2.0.0 do 2.5.0 punkt końcowy POST /api/login sprawdza EnabledOTP, ale nie wymaga asercji WebAuthn, gdy EnabledPasskey jest prawdziwe i nie skonfigurowano sekretu TOTP. Konto korzystające wyłącznie z passkey otrzymuje sesję po weryfikacji hasła, mimo że Enabled2FA wskazuje na posiadanie drugiego czynnika.

W Nginx UI od wersji 2.0.0 do 2.5.0 aplikacja akceptuje główne poświadczenie Node.Secret poprzez parametr zapytania node_secret w ścieżkach uwierzytelniania HTTP i WebSocket, zamiast wymagać nagłówka X-Node-Secret. Poświadczenie może pojawić się w logach dostępu, logach proxy, historii przeglądarki, nagłówkach Referer, adresach URL konfiguracji i danych środowiskowych wdrożenia.

Nginx UI w wersjach od 2.5.0 do 2.6.0 wykonuje tymczasowe zapisywanie treści żądania kontrolowanej przez atakującego i synchronizuje ją na dysk przed weryfikacją skrótu i podpisu kryptograficznego. Nieuwierzytelniony zdalny klient może wyczerpać miejsce na dysku, operacje wejścia/wyjścia oraz zasoby przetwarzania żądań, zanim żądanie zostanie odrzucone. Problem został naprawiony w wersji 2.6.0.

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.