Nginx UI vulnerabilities

In Nginx UI from 2.0.0 until 2.5.0, ordinary authenticated users can access /api/nodes and /api/nodes/:id, whose responses serialize the node token field. The same token is accepted as X-Node-Secret by AuthRequired and maps the request to initUser, allowing the user to impersonate a trusted node against a reachable cluster member.

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.

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.

Nginx UI is a web user interface for the Nginx web server. From version 2.0.0 to before version 2.3.8, an unauthenticated network attacker can claim the initial administrator account on a fresh nginx-ui instance during the first-run setup window.

Nginx UI is a web user interface for the Nginx web server. From 2.3.8 until 2.5.0, an authenticated administrator with an active secure session can submit attacker-controlled portable backup key material and a matching manifest to POST /api/restore. The restore flow trusts the supplied key, decrypts attacker-controlled contents, and replaces the live app.ini, including protected nginx command settings such as TestConfigCmd. Triggering POST /api/nginx/test then executes the restored command in the Nginx UI runtime context, affecting confidentiality, integrity, and availability.

Nginx UI, a web user interface for the Nginx web server, prior to version 2.3.8, exposed a backup restore endpoint (POST /api/restore) that was completely unauthenticated during the first 10 minutes after process startup on any fresh installation. An unauthenticated remote attacker could upload a crafted backup archive that overwrote the application's configuration file and SQLite database.

Nginx UI prior to 2.4.1 uses a constant OAuth state value and does not verify state in CasdoorCallback, allowing an unauthenticated attacker to hijack a user's session.

Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, the HTTP configuration mutation routes require RequireSecureSession, but /mcp and /mcp_message require only ordinary authentication before exposing nginx_config_add and nginx_config_modify. An OTP-enabled user with a normal JWT but no valid X-Secure-Session-ID can therefore create or modify Nginx configuration and trigger reload behavior through MCP, bypassing the intended step-up control. This issue is fixed in version 2.4.1.

Nginx UI prior to version 2.4.1 contains a vulnerability where generated short tokens lack an associated long Token value, and DeleteUserTokens invalidates cache entries only when the long Token field is nonempty. A revoked short token can remain in the cache and re-authenticate if the account is re-enabled before the entry expires, restoring access to HTTP or WebSocket routes accepting short-token authentication.

Nginx UI prior to version 2.4.3 contains a vulnerability where AutoBackup.GetName returns a user-controlled name without rejecting path separators or parent-directory components, and downstream filename formatting embeds that result in the final archive filename. An authenticated user can cause filepath.Join to resolve the generated archive path outside the validated storage directory, allowing backup archives to be written with Nginx UI process privileges.

Nginx UI prior to 2.4.1 rejects restricted Nginx directives such as load_module, js_import, and js_content in the regular HTTP configuration API. However, the MCP configuration interface allows a secondary authenticated user to write and apply equivalent restricted configuration content. This allows the user to load ngx_http_js_module.so, import attacker-controlled JavaScript, reload Nginx, and execute NJS in the Nginx worker context. This issue is fixed in version 2.4.1.

Nginx UI from 2.0.0-rc.6 until 2.4.1, the MCP tool nginx_config_add writes nginx configuration files to disk and triggers an nginx reload without calling config.ValidateConfigFile. The identical flow in the REST API (POST /api/configs) does call that function and correctly rejects dangerous directives. An authenticated attacker can exploit this gap to write config files containing any blocked directive (perl, js_import, load_module, user root, etc.), bypassing nginx-ui's entire security layer. On a server with the nginx Perl, njs, or Lua module loaded, this is post-authentication Remote Code Execution. This issue is fixed in version 2.4.1.

Nginx UI prior to 2.4.1, internal/config/validation.go (ValidateConfigFile) is a security control that blocks dangerous nginx directives — js_*, perl_*, load_module of the njs/perl modules, and user root. It is enforced on three of the four config-write paths: api/config/add.go, api/config/modify.go, and mcp/config/config_modify.go. The fourth path — the MCP tool nginx_config_add (mcp/config/config_add.go) — does NOT call it: it writes the caller-supplied content straight to disk and reloads nginx. An authenticated MCP caller (or an MCP agent induced via prompt injection) can therefore inject exactly the directives the control is meant to block, leading to nginx code execution on deployments where the njs/perl module is available (e.g. the official Docker image). This issue is fixed in version 2.4.1.

Nginx UI prior to 2.4.1, config.ValidateConfigDirectives splits configuration by newline and checks only the first directive token on each line even though Nginx permits multiple semicolon-separated directives on one line. An authenticated caller can place a benign directive first and a restricted load_module, js_import, perl, or user root directive later on the same line, or can use an unrestricted include directive to load restricted content. These mechanisms bypass validation on REST, nginx_config_modify, site, and stream write paths; when an executable module is available, the injected configuration can execute code in the Nginx worker context. This issue is fixed in version 2.4.1.

Nginx UI prior to 2.4.1 does not apply RequireSecureSession to multiple authenticated mutation routes even though OTP-enabled users are expected to present a fresh X-Secure-Session-ID for sensitive actions. A stolen authenticated session can therefore create or alter automatic backups, DNS credentials and records, certificates and ACME users, Nginx control settings, and site or stream automation without completing the OTP or passkey step-up. This issue is fixed in version 2.4.1.

Nginx UI prior to 2.4.1, the POST /api/users/:id user-management endpoint permits an authenticated user to change another user's password without passing RequireSecureSession, even though the self-service password-change path requires that step-up. An attacker with an authenticated account can change the initial administrator's password, invalidate existing administrator tokens, and then authenticate as the administrator. This issue is fixed in version 2.4.1.

Nginx UI prior to 2.4.1, POST /api/otp_enroll and POST /api/finish_passkey_register are registered outside RequireSecureSession and accept a normal authenticated session without verifying the current password. An attacker with a stolen JWT can bind an attacker-controlled TOTP secret when the victim has not already enabled TOTP, or can register an attacker-controlled passkey because that path has no equivalent existing-enrollment guard. These changes create persistent account access that can survive a password change and interfere with the legitimate user's authentication. This issue is fixed in version 2.4.1.

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