CVE-2024-49368

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