CVE-2026-107811

In Nginx UI from 2.0.0 until 2.5.0, the api/cluster router exposes node and namespace mutation operations and cluster-wide Nginx reload or restart operations with AuthRequired but without RequireSecureSession. An authenticated OTP-enabled user possessing a stolen or persisted JWT can perform node CRUD, read or replace node credentials, change namespaces, and invoke reload/restart without a fresh second-factor step-up.

In Nginx UI from 2.0.0 until 2.5.0, the self-upgrade mechanism validates a downloaded binary only with a same-origin digest obtained from the same upgrade mirror. A compromised mirror or network attacker able to alter both responses can supply a malicious executable and matching digest, and the application installs and runs the attacker-controlled code in the Nginx UI process context on the next upgrade.

In Nginx UI from 2.0.0 until 2.5.0, internal/backup/restore.go extracts inner archives before applying the restore_nginx and restore_nginx_ui flags and permits symlinks targeting the live Nginx configuration path. An authenticated user who can create and restore backups can craft a valid backup that places a symlink in the staging tree and then writes a regular file through that link, even when both restore flags are false.

In Nginx UI from 2.0.0 until 2.5.0, AuthRequired accepts a browser-managed token cookie as an API credential after the front end stores the JWT in that cookie. Because management endpoints do not universally require a CSRF token or perform Origin or Referer validation, a remote attacker can induce a logged-in administrator's browser to submit authenticated cross-site state-changing requests, including POST /api/configs.

In Nginx UI from 2.0.0 until 2.5.0, POST /api/login checks EnabledOTP but does not require a WebAuthn assertion when EnabledPasskey is true and no TOTP secret is configured. A passkey-only account is therefore issued a session after password verification, despite Enabled2FA reporting that the account has a second factor.

In Nginx UI from 2.0.0 until 2.5.0, Nginx UI accepts the Node.Secret master credential through the node_secret query parameter in HTTP and WebSocket authentication paths instead of requiring the X-Node-Secret header. The credential can consequently appear in access logs, proxy logs, browser history, Referer headers, configuration URLs, and deployment environment data.

Nginx UI from 2.5.0 until 2.6.0 performs temporary file staging of an attacker-controlled request body and synchronizes it before validating the body digest and cryptographic signature. An unauthenticated remote client can consume temporary filesystem capacity, disk I/O, and request-processing resources before rejection. This is fixed in version 2.6.0.

Nginx UI is a web user interface for the Nginx web server. From 2.2.0 until 2.6.0, the bundled reverse proxy does not preserve the external client identity used by Gin because the backend has no trusted proxy configuration. Management requests can be attributed to loopback and pass the IP allowlist loopback exception, although valid credentials are still required. Failed logins from different external clients are also attributed to the same loopback address, allowing an unauthenticated attacker to trigger a shared temporary login ban for password or OTP authentication without invalidating existing sessions. This issue is fixed in version 2.6.0.

Nginx UI is a web user interface for the Nginx web server. In versions 2.3.4 and earlier, an authenticated user can perform Server-Side Request Forgery (SSRF) by creating a cluster node pointing to an arbitrary internal URL.

In version 2.3.5 of the Nginx user interface (nginx-ui), there is an unauthenticated bootstrap takeover vulnerability during the initial installation exposed by POST /api/install.