Nginx Ui
Monthly
Nginx UI versions prior to 2.4.1 let an authenticated, OTP-enabled user holding only an ordinary JWT - without the X-Secure-Session-ID step-up header - create or modify Nginx configuration and trigger reload behavior by calling the nginx_config_add and nginx_config_modify tools through the /mcp and /mcp_message endpoints, which were protected by ordinary authentication alone. The equivalent HTTP configuration mutation routes correctly enforced the RequireSecureSession middleware, so the MCP channel constituted an alternate path around that control (CWE-288). Per the CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, impact is limited to integrity and availability with high severity driven by unconstrained config writes; exploitation requires an existing low-privilege authenticated session on a pre-2.4.1 instance, and no public exploit code or confirmed active exploitation was identified at time of analysis. The issue is fixed in version 2.4.1, and the upstream commit additionally hardened backup-related routes with RequireSecureSession.
Configuration validation bypass in Nginx UI (nginx-ui) prior to 2.4.1 lets an authenticated user with configuration-write privileges inject restricted Nginx directives by placing a benign directive first on a single line and appending a semicolon-separated restricted directive such as load_module, js_import, perl, or user root, because ValidateConfigDirectives only inspects the first token of each newline-split line. The flaw affects the REST, nginx_config_modify, site, and stream write paths and can escalate to arbitrary code execution in the Nginx worker context when a loadable Nginx module is already present on the host, a precondition that limits practical impact. No public exploit code was identified at the time of analysis, and the vendor released patch version 2.4.1.
Nginx UI installations before 2.4.1 expose two account-security endpoints, POST /api/otp_enroll and POST /api/finish_passkey_register, that let an attacker holding a stolen, valid JWT bind an attacker-controlled TOTP secret or register an attacker-controlled passkey against the victim's account, producing persistent access that survives a password change. The CVSS vector (AV:N/AC:L/PR:L/UI:N) confirms exploitation requires an authenticated session rather than being unauthenticated, and no public exploit code has been identified at time of analysis. The TOTP path only succeeds if the victim has not already enabled TOTP, because it relies on an existing-enrollment guard, whereas the passkey registration path has no equivalent guard and is exploitable regardless of prior enrollment.
Nginx UI deployments that use Casdoor OAuth/SSO for authentication can issue a valid application session for an attacker-chosen identity on versions prior to 2.4.1, because the OAuth 'state' value is a fixed constant (the configured Casdoor application name) and the callback never binds it to the browser session that started the login. An unauthenticated attacker who persuades a victim to open a crafted Casdoor authorization link can have the victim's browser complete the attacker-controlled authorization flow, after which the callback mints an Nginx UI session for the identity returned by that authorization code - yielding high confidentiality impact with limited integrity impact (CVSS 3.1 7.1, AV:N/AC:L/PR:N/UI:R). The flaw is conditionally gated: it only applies to instances with Casdoor OAuth configured and requires victim interaction, so it is a genuine authentication-bypass issue rather than a universally exploitable one; no public exploit code was identified at time of analysis, and a vendor-released patch in version 2.4.1 is available.
Privilege escalation in Nginx UI lets any holder of an authenticated account take over the built-in administrator by changing the admin's password through POST /api/users/:id, which omits the RequireSecureSession step-up that the self-service password-change path enforces. Successful abuse silently invalidates the legitimate administrator's existing tokens, and the attacker can then authenticate as the administrator with full control over the Nginx configuration managed by the UI. All releases prior to 2.4.1 are affected; the vendor-released fix is version 2.4.1, and no public exploit code has been identified at time of analysis, though the assessed CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects complete loss of confidentiality, integrity, and availability. The practical exposure is gated by the need for a pre-existing low-privilege account, so multi-user deployments are directly at risk while single-admin instances that never provision secondary users have no untrusted principal to abuse.
Configuration-validation bypass in Nginx UI (versions 2.0.0-rc.6 through 2.4.0) lets an authenticated low-privilege user write arbitrary nginx configuration directives through the MCP tool nginx_config_add, which persists the file and triggers an nginx reload without ever calling config.ValidateConfigFile - the guard the REST endpoint POST /api/configs does invoke. Because blocked directives such as perl, js_import, load_module and user root can therefore be injected, an attacker on a host with the nginx Perl, njs or Lua module loaded can escalate this into post-authentication remote code execution; on hosts without a scripting module the effect is arbitrary config tampering and reload. The issue is fixed in Nginx UI 2.4.1, and no public exploit code or confirmed active exploitation has been identified at time of analysis.
Nginx UI versions prior to 2.4.1 fail to enforce the RequireSecureSession step-up check on multiple authenticated mutation endpoints, so an attacker who already holds a valid session token for an OTP- or passkey-enabled account can create or modify automatic backups, DNS credentials and records, certificates and ACME users, Nginx control settings, and site or stream automation without ever supplying a fresh X-Secure-Session-ID. The flaw is a missing-authorization-check class issue (CWE-862) rated CVSS 3.1 base 8.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H): it requires a stolen or otherwise obtained authenticated session (PR:L) but no user interaction, giving high integrity and availability impact. No public exploit code was identified at time of analysis and there is no indication the issue is being actively exploited; the upstream fix is available in release 2.4.1.
Missing second-factor step-up enforcement in the Nginx UI cluster API (versions 2.0.0 through 2.4.x) allows anyone holding a valid session token to perform node CRUD operations, read or replace stored node credentials, change namespaces, and trigger cluster-wide Nginx reload or restart actions without re-verifying a one-time password. The api/cluster router is protected by AuthRequired but omits RequireSecureSession, so a stolen or persisted JWT belonging to an OTP-enabled user is sufficient; the flaw is an incomplete fix for CVE-2026-84315 and was corrected in version 2.5.0. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and exposure is limited to clustered/multi-node deployments reachable on the network, so this is a high-priority issue for that specific population rather than a mass-internet emergency.
Attackers who control the Nginx UI upgrade mirror - or hold a man-in-the-middle position on the path to it - can get arbitrary code installed and executed by Nginx UI 2.0.0 through 2.4.x, because the self-upgrade routine verifies the downloaded binary only against a same-origin digest fetched from that same mirror, leaving no independent trust anchor. Exploitation requires two simultaneous conditions: the attacker's mirror/network position must let them alter BOTH the binary and its digest response, and an operator must manually trigger the self-upgrade, at which point the swapped payload is installed and runs in the Nginx UI process context. The issue is rated CVSS 7.5 (AV:N/AC:H/PR:N/UI:R) and is fixed in 2.5.0, which introduces minisign signature verification; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the high network-position prerequisite plus the required operator action substantially narrow realistic exploitation.
Ordinary authenticated users of clustered Nginx UI deployments can read the cluster node token from the JSON responses of /api/nodes and /api/nodes/:id and replay it in the X-Node-Secret header to be authenticated as a trusted peer node, crossing the node-to-node authentication boundary. Because the leaked secret is accepted by AuthRequired and mapped to the synthetic initUser principal, the attacker can reach sensitive management operations on any network-reachable cluster member, including configuration synchronization and service restarts. Affected versions are 2.0.0 through 2.4.x; the issue is fixed in Nginx UI 2.5.0. No public exploit code or confirmed active exploitation was identified at time of analysis, although the upstream fix commit is publicly visible.
Authenticated users of Nginx UI 2.0.0 through 2.4.x who hold permission to create and restore backups can persistently inject modified Nginx configuration or Nginx UI configuration files by crafting a backup archive that carries a symlink pointing at the live configuration path, achieving this even when the restore_nginx and restore_nginx_ui flags are both false. The flaw (CWE-59, link following) stems from the restore path extracting inner archives and materializing symlinks before the restore flags are enforced, so a regular file subsequently written through the staged link lands in the live configuration tree; the resulting tampering takes effect only when those files are later consumed by Nginx, and can produce denial of service. Rated CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H), this requires a valid backup-capable login (PR:L) and is not a remote-unauthenticated attack, and no public exploit code was identified at time of analysis; vendor-released patch: 2.5.0 fully remediates the issue.
Cross-site request forgery in Nginx UI versions 2.0.0 through 2.4.x lets a remote attacker drive a logged-in administrator's browser into performing authenticated, state-changing management operations - including rewriting Nginx configuration through POST /api/configs, triggering config reloads, and invoking other admin endpoints - because the AuthRequired middleware accepts the browser-managed JWT cookie as a valid API credential while management routes generally enforce neither a CSRF token nor Origin/Referer validation. Exploitation requires the victim to be a currently logged-in administrator who is induced to visit an attacker-controlled page (UI:R); per the CVSS vector the attacker needs no credentials of their own (PR:N), but a targeted account protected by OTP/Passkey step-up, or an endpoint requiring secure-session proof, is not exploitable. The attacker cannot read cross-origin responses, so impact is blind configuration tampering and service disruption rather than data exfiltration; the issue is fixed in 2.5.0, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Account takeover in Nginx UI versions 2.0.0 through 2.4.x affects accounts configured with a passkey as their only second factor: the POST /api/login handler checks EnabledOTP but never requires a WebAuthn assertion when EnabledPasskey is true and no TOTP secret exists, so a valid password alone yields a fully authenticated session despite the account reporting a second factor. An attacker who already holds the account password can reach administrative Nginx UI functionality without possessing the registered passkey; accounts protected by TOTP, and accounts with no 2FA configured, are unaffected. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV, though the CVSS 3.1 score is 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H), with the AC:H metric reflecting the hard password precondition rather than any exploit complexity.
Credential exposure in Nginx UI 2.0.0 through 2.4.x allows anyone who recovers the Node.Secret master credential to bypass password, JWT, session, and second-factor checks and obtain persistent administrative API access to configuration and secret material. Versions in that range accept the Node.Secret through the node_secret query parameter on HTTP and WebSocket authentication paths instead of requiring the X-Node-Secret header, so the credential can leak into access logs, reverse-proxy logs, browser history, Referer headers, configuration URLs, and deployment environment data. Exploitation is conditional rather than trivial: node/cluster authentication must actually be in use, the secret must have been transmitted as a query parameter in practice, and the attacker must have read access to one of those sinks; no public exploit code has been identified at time of analysis, and the vendor rates this 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) while our independent assessment scores it AV:N/AC:H/PR:N/UI:N with the same High confidentiality, integrity, and availability impact.
Authenticated administrators of Nginx UI releases 2.3.8 through 2.4.x can achieve remote code execution on the host by abusing the backup restore endpoint to overwrite live configuration with attacker-controlled nginx command settings. The attacker submits attacker-controlled portable backup key material along with a matching manifest to POST /api/restore; because the restore flow trusts the supplied key and treats the backup as 'portable', it decrypts the attacker's payload and replaces the live app.ini, including the protected TestConfigCmd value, after which a call to POST /api/nginx/test executes the restored command inside the Nginx UI runtime. The issue is rated CVSS 9.4 (CVSS 4.0) and CVSS 3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, is fixed in version 2.5.0, and at time of analysis there is no public exploit identified and no confirmed active exploitation (not listed in CISA KEV); the practical barrier is the high-privilege authenticated session required, so exposure is limited to instances where an admin account or session can be obtained by an untrusted party.
Unauthenticated remote clients that can reach the Nginx UI node-signature authentication API on versions 2.5.0 through pre-2.6.0 can force the server to stage attacker-controlled request bodies to temporary files and flush them to disk before any digest or cryptographic signature validation occurs, allowing exhaustion of temporary filesystem capacity, disk I/O, and request-processing resources. The impact is availability-only (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) - authentication is not bypassed and there is no confidentiality or integrity impact. No public exploit code was identified at time of analysis and the flaw is not confirmed as actively exploited (no CISA KEV listing); vendor-released patch: 2.6.0, which caps staged node request bodies at 128 MiB and adds a pre-read ContentLength check.
Server-side request forgery in Nginx UI through 2.3.4 lets any authenticated user redirect API requests to an attacker-chosen internal URL, exposing localhost-bound services, internal networks, and cloud metadata endpoints to credential theft and reconnaissance. The flaw requires a valid Nginx UI account and use of the cluster-node proxy path; the independent assessment rates confidentiality high, integrity low, and availability none. No vendor-fixed version is listed, a public PoC reference exists but is not verified as working exploit code, KEV does not list it, EPSS is 0.03% (8th percentile), and the vuln.today priority is act_now.
Remote code execution as root in nginx-ui versions before 2.3.8 via unauthenticated backup restore within 10-minute startup window. Attackers exploit the completely unauthenticated /api/restore endpoint during initial installation to upload malicious backup archives that overwrite app.ini configuration with injected OS commands in TestConfigCmd setting. After automatic application restart, command injection triggers with privileges of the nginx-ui process - typically root in Docker deployments. EPSS data not available; no active exploitation reported but publicly disclosed via GitHub Security Advisory GHSA-4pvg-prr3-9cxr. Patch released in version 2.3.8.
Unauthenticated bootstrap takeover in Nginx UI 2.3.5: any remote client that can reach a still-uninitialized instance during the roughly 10-minute first-run setup window can claim it outright, because POST /api/install accepts attacker-supplied bootstrap data and sets the JWT secret, node secret, certificate email and the initial administrator username and password, after which the attacker simply logs in as the first administrator. Exposure is confined to fresh, rebuilt, ephemeral, LAN-reachable or temporarily exposed deployments - once installation is locked the path closes, so there is no persistent post-install takeover. The vendor advisory ships a standalone proof-of-concept script that was reproduced against the 2.3.5 Docker image, and no public patch was available at time of publication; EPSS is low at 0.04% (12th percentile) but the vuln.today decision label is act_now and SSVC rates technical impact as total.
Unauthenticated attackers who can reach a fresh, uninitialized Nginx UI instance before version 2.3.8 during its first-run setup window can set the initial administrator credentials and permanently take over the application. Despite the 9.8 severity and an act_now priority, exploitation requires the instance to still be uninstalled and the request to arrive within the roughly 10-minute startup window; already-provisioned instances and installations past that window reject the request, which keeps real-world exposure narrow. The issue is patched in 2.3.8; a public PoC reference exists but is not verified as working exploit code, and EPSS is low at 0.08% (24th percentile).
Disabled user accounts in Nginx UI versions before 2.3.4 retain full API access through previously issued JWT tokens for the entire token lifetime, allowing attackers with stolen credentials to maintain persistent access and create new accounts even after administrative remediation attempts. This authentication bypass enables continued confidentiality and integrity compromise of Nginx configurations despite account lockout. Reported by GitHub security advisories; no evidence of active exploitation (not in CISA KEV), but the token-reuse mechanism makes exploitation straightforward for attackers who have already obtained credentials.
Unauthenticated backup download and RCE in Nginx UI before 2.3.3. EPSS 1.0%. PoC available.
Revoked short-tokens in Nginx UI prior to 2.4.1 can be replayed to regain authenticated access to HTTP and WebSocket routes that accept short-token authentication, because token deletion fails to invalidate the corresponding short_token cache entry. Exploitation is authenticated and tightly conditioned: the attacker must already hold a previously issued short token (CVSS PR:L), the account must be disabled and then re-enabled before the stale cache entry expires, and the surviving cache record is then resolved by GetTokenUserByShortToken - a timing-dependent, opportunistic flaw rather than a reliably reproducible one. There is no public exploit identified at time of analysis and no evidence of confirmed active exploitation (no CISA KEV listing); the vendor-released patch is Nginx UI 2.4.1.
Path traversal in Nginx UI (0xJacky) before 2.4.3 allows an authenticated user who can create or modify an automatic backup to write backup archive files - and, when the backup is configured as an encrypted configuration backup, the adjacent encryption key file - outside the validated storage directory, with the privileges of the Nginx UI process. Exploitation requires a valid Nginx UI account with backup-management permissions (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L, 6.3 per the independent assessment) and only takes effect when the configured automatic backup actually runs; the attacker influences the generated archive/key filename rather than arbitrary file content. The issue is fixed in version 2.4.3, and no public exploit code was identified at time of analysis.
Nginx UI versions 2.2.0 up to but not including 2.6.0 mis-attribute client identity when the application is reached through its bundled reverse proxy without trusted-proxy configuration, so every request appears to originate from loopback. The practical unauthenticated impact (CVSS 5.3, PR:N) is a shared, temporary login ban: failed password or OTP attempts from different external clients are all counted against 127.0.0.1, letting an attacker lock out the login endpoint for legitimate users without invalidating existing sessions. A separate consequence is that management requests can satisfy the loopback exception in the IP allowlist, but this path is strongly limited because valid credentials are still required, so it does not amount to authentication bypass or account takeover. No public exploit code has been identified at time of analysis, and the issue is fixed in version 2.6.0.
nginx-ui versions prior to 2.3.8 expose 40+ protected configuration fields through the GetSettings API to authenticated users, including JwtSecret (auth token forgery), NodeSecret (cluster impersonation), and OIDC ClientSecret (OAuth takeover). The protected tag is enforced only during writes but completely ignored during reads, allowing authenticated attackers to extract sensitive secrets and IP whitelist configurations without requiring additional privileges or user interaction.
nginx-ui prior to version 2.3.8 exposes sensitive configuration values including node.secret via an authenticated GET /api/settings endpoint, allowing an authenticated user to retrieve the shared authentication secret and subsequently impersonate the init administrative user by sending requests with the stolen node.secret via the X-Node-Secret header or node_secret query parameter. This enables privilege escalation and full administrative access to the Nginx configuration interface without additional authentication.
nginx-ui before version 2.3.5 allows Cross-Site WebSocket Hijacking (CSWSH) attacks due to improper WebSocket origin validation and insecurely configured authentication cookies. An attacker can trick a logged-in administrator into visiting a malicious webpage that establishes authenticated WebSocket connections to the target nginx-ui instance, enabling information disclosure and administrative actions without explicit user consent. Version 2.3.5 patches the issue; no public exploit code or active exploitation confirmed at time of analysis.
Nginx UI is a web user interface for the Nginx web server. Rated high severity (CVSS 8.9), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Nginx UI is a web user interface for the Nginx web server. Rated medium severity (CVSS 5.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Nginx UI is a web user interface for the Nginx web server. Rated high severity (CVSS 7.7), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Nginx-UI is a web interface to manage Nginx configurations. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Nginx-UI is a web interface to manage Nginx configurations. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Nginx-UI is a web interface to manage Nginx configurations. Rated high severity (CVSS 7.1), this vulnerability is remotely exploitable. Public exploit code available and EPSS exploitation probability 16.0%.
Nginx-UI is an online statistics for Server Indicators Monitor CPU usage, memory usage, load average, and disk usage in real-time. Rated high severity (CVSS 7.0), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
Nginx-ui is online statistics for Server Indicators Monitor CPU usage, memory usage, load average, and disk usage in real-time. Rated high severity (CVSS 7.7), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
Nginx UI versions prior to 2.4.1 let an authenticated, OTP-enabled user holding only an ordinary JWT - without the X-Secure-Session-ID step-up header - create or modify Nginx configuration and trigger reload behavior by calling the nginx_config_add and nginx_config_modify tools through the /mcp and /mcp_message endpoints, which were protected by ordinary authentication alone. The equivalent HTTP configuration mutation routes correctly enforced the RequireSecureSession middleware, so the MCP channel constituted an alternate path around that control (CWE-288). Per the CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, impact is limited to integrity and availability with high severity driven by unconstrained config writes; exploitation requires an existing low-privilege authenticated session on a pre-2.4.1 instance, and no public exploit code or confirmed active exploitation was identified at time of analysis. The issue is fixed in version 2.4.1, and the upstream commit additionally hardened backup-related routes with RequireSecureSession.
Configuration validation bypass in Nginx UI (nginx-ui) prior to 2.4.1 lets an authenticated user with configuration-write privileges inject restricted Nginx directives by placing a benign directive first on a single line and appending a semicolon-separated restricted directive such as load_module, js_import, perl, or user root, because ValidateConfigDirectives only inspects the first token of each newline-split line. The flaw affects the REST, nginx_config_modify, site, and stream write paths and can escalate to arbitrary code execution in the Nginx worker context when a loadable Nginx module is already present on the host, a precondition that limits practical impact. No public exploit code was identified at the time of analysis, and the vendor released patch version 2.4.1.
Nginx UI installations before 2.4.1 expose two account-security endpoints, POST /api/otp_enroll and POST /api/finish_passkey_register, that let an attacker holding a stolen, valid JWT bind an attacker-controlled TOTP secret or register an attacker-controlled passkey against the victim's account, producing persistent access that survives a password change. The CVSS vector (AV:N/AC:L/PR:L/UI:N) confirms exploitation requires an authenticated session rather than being unauthenticated, and no public exploit code has been identified at time of analysis. The TOTP path only succeeds if the victim has not already enabled TOTP, because it relies on an existing-enrollment guard, whereas the passkey registration path has no equivalent guard and is exploitable regardless of prior enrollment.
Nginx UI deployments that use Casdoor OAuth/SSO for authentication can issue a valid application session for an attacker-chosen identity on versions prior to 2.4.1, because the OAuth 'state' value is a fixed constant (the configured Casdoor application name) and the callback never binds it to the browser session that started the login. An unauthenticated attacker who persuades a victim to open a crafted Casdoor authorization link can have the victim's browser complete the attacker-controlled authorization flow, after which the callback mints an Nginx UI session for the identity returned by that authorization code - yielding high confidentiality impact with limited integrity impact (CVSS 3.1 7.1, AV:N/AC:L/PR:N/UI:R). The flaw is conditionally gated: it only applies to instances with Casdoor OAuth configured and requires victim interaction, so it is a genuine authentication-bypass issue rather than a universally exploitable one; no public exploit code was identified at time of analysis, and a vendor-released patch in version 2.4.1 is available.
Privilege escalation in Nginx UI lets any holder of an authenticated account take over the built-in administrator by changing the admin's password through POST /api/users/:id, which omits the RequireSecureSession step-up that the self-service password-change path enforces. Successful abuse silently invalidates the legitimate administrator's existing tokens, and the attacker can then authenticate as the administrator with full control over the Nginx configuration managed by the UI. All releases prior to 2.4.1 are affected; the vendor-released fix is version 2.4.1, and no public exploit code has been identified at time of analysis, though the assessed CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects complete loss of confidentiality, integrity, and availability. The practical exposure is gated by the need for a pre-existing low-privilege account, so multi-user deployments are directly at risk while single-admin instances that never provision secondary users have no untrusted principal to abuse.
Configuration-validation bypass in Nginx UI (versions 2.0.0-rc.6 through 2.4.0) lets an authenticated low-privilege user write arbitrary nginx configuration directives through the MCP tool nginx_config_add, which persists the file and triggers an nginx reload without ever calling config.ValidateConfigFile - the guard the REST endpoint POST /api/configs does invoke. Because blocked directives such as perl, js_import, load_module and user root can therefore be injected, an attacker on a host with the nginx Perl, njs or Lua module loaded can escalate this into post-authentication remote code execution; on hosts without a scripting module the effect is arbitrary config tampering and reload. The issue is fixed in Nginx UI 2.4.1, and no public exploit code or confirmed active exploitation has been identified at time of analysis.
Nginx UI versions prior to 2.4.1 fail to enforce the RequireSecureSession step-up check on multiple authenticated mutation endpoints, so an attacker who already holds a valid session token for an OTP- or passkey-enabled account can create or modify automatic backups, DNS credentials and records, certificates and ACME users, Nginx control settings, and site or stream automation without ever supplying a fresh X-Secure-Session-ID. The flaw is a missing-authorization-check class issue (CWE-862) rated CVSS 3.1 base 8.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H): it requires a stolen or otherwise obtained authenticated session (PR:L) but no user interaction, giving high integrity and availability impact. No public exploit code was identified at time of analysis and there is no indication the issue is being actively exploited; the upstream fix is available in release 2.4.1.
Missing second-factor step-up enforcement in the Nginx UI cluster API (versions 2.0.0 through 2.4.x) allows anyone holding a valid session token to perform node CRUD operations, read or replace stored node credentials, change namespaces, and trigger cluster-wide Nginx reload or restart actions without re-verifying a one-time password. The api/cluster router is protected by AuthRequired but omits RequireSecureSession, so a stolen or persisted JWT belonging to an OTP-enabled user is sufficient; the flaw is an incomplete fix for CVE-2026-84315 and was corrected in version 2.5.0. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and exposure is limited to clustered/multi-node deployments reachable on the network, so this is a high-priority issue for that specific population rather than a mass-internet emergency.
Attackers who control the Nginx UI upgrade mirror - or hold a man-in-the-middle position on the path to it - can get arbitrary code installed and executed by Nginx UI 2.0.0 through 2.4.x, because the self-upgrade routine verifies the downloaded binary only against a same-origin digest fetched from that same mirror, leaving no independent trust anchor. Exploitation requires two simultaneous conditions: the attacker's mirror/network position must let them alter BOTH the binary and its digest response, and an operator must manually trigger the self-upgrade, at which point the swapped payload is installed and runs in the Nginx UI process context. The issue is rated CVSS 7.5 (AV:N/AC:H/PR:N/UI:R) and is fixed in 2.5.0, which introduces minisign signature verification; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the high network-position prerequisite plus the required operator action substantially narrow realistic exploitation.
Ordinary authenticated users of clustered Nginx UI deployments can read the cluster node token from the JSON responses of /api/nodes and /api/nodes/:id and replay it in the X-Node-Secret header to be authenticated as a trusted peer node, crossing the node-to-node authentication boundary. Because the leaked secret is accepted by AuthRequired and mapped to the synthetic initUser principal, the attacker can reach sensitive management operations on any network-reachable cluster member, including configuration synchronization and service restarts. Affected versions are 2.0.0 through 2.4.x; the issue is fixed in Nginx UI 2.5.0. No public exploit code or confirmed active exploitation was identified at time of analysis, although the upstream fix commit is publicly visible.
Authenticated users of Nginx UI 2.0.0 through 2.4.x who hold permission to create and restore backups can persistently inject modified Nginx configuration or Nginx UI configuration files by crafting a backup archive that carries a symlink pointing at the live configuration path, achieving this even when the restore_nginx and restore_nginx_ui flags are both false. The flaw (CWE-59, link following) stems from the restore path extracting inner archives and materializing symlinks before the restore flags are enforced, so a regular file subsequently written through the staged link lands in the live configuration tree; the resulting tampering takes effect only when those files are later consumed by Nginx, and can produce denial of service. Rated CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H), this requires a valid backup-capable login (PR:L) and is not a remote-unauthenticated attack, and no public exploit code was identified at time of analysis; vendor-released patch: 2.5.0 fully remediates the issue.
Cross-site request forgery in Nginx UI versions 2.0.0 through 2.4.x lets a remote attacker drive a logged-in administrator's browser into performing authenticated, state-changing management operations - including rewriting Nginx configuration through POST /api/configs, triggering config reloads, and invoking other admin endpoints - because the AuthRequired middleware accepts the browser-managed JWT cookie as a valid API credential while management routes generally enforce neither a CSRF token nor Origin/Referer validation. Exploitation requires the victim to be a currently logged-in administrator who is induced to visit an attacker-controlled page (UI:R); per the CVSS vector the attacker needs no credentials of their own (PR:N), but a targeted account protected by OTP/Passkey step-up, or an endpoint requiring secure-session proof, is not exploitable. The attacker cannot read cross-origin responses, so impact is blind configuration tampering and service disruption rather than data exfiltration; the issue is fixed in 2.5.0, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Account takeover in Nginx UI versions 2.0.0 through 2.4.x affects accounts configured with a passkey as their only second factor: the POST /api/login handler checks EnabledOTP but never requires a WebAuthn assertion when EnabledPasskey is true and no TOTP secret exists, so a valid password alone yields a fully authenticated session despite the account reporting a second factor. An attacker who already holds the account password can reach administrative Nginx UI functionality without possessing the registered passkey; accounts protected by TOTP, and accounts with no 2FA configured, are unaffected. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV, though the CVSS 3.1 score is 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H), with the AC:H metric reflecting the hard password precondition rather than any exploit complexity.
Credential exposure in Nginx UI 2.0.0 through 2.4.x allows anyone who recovers the Node.Secret master credential to bypass password, JWT, session, and second-factor checks and obtain persistent administrative API access to configuration and secret material. Versions in that range accept the Node.Secret through the node_secret query parameter on HTTP and WebSocket authentication paths instead of requiring the X-Node-Secret header, so the credential can leak into access logs, reverse-proxy logs, browser history, Referer headers, configuration URLs, and deployment environment data. Exploitation is conditional rather than trivial: node/cluster authentication must actually be in use, the secret must have been transmitted as a query parameter in practice, and the attacker must have read access to one of those sinks; no public exploit code has been identified at time of analysis, and the vendor rates this 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) while our independent assessment scores it AV:N/AC:H/PR:N/UI:N with the same High confidentiality, integrity, and availability impact.
Authenticated administrators of Nginx UI releases 2.3.8 through 2.4.x can achieve remote code execution on the host by abusing the backup restore endpoint to overwrite live configuration with attacker-controlled nginx command settings. The attacker submits attacker-controlled portable backup key material along with a matching manifest to POST /api/restore; because the restore flow trusts the supplied key and treats the backup as 'portable', it decrypts the attacker's payload and replaces the live app.ini, including the protected TestConfigCmd value, after which a call to POST /api/nginx/test executes the restored command inside the Nginx UI runtime. The issue is rated CVSS 9.4 (CVSS 4.0) and CVSS 3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, is fixed in version 2.5.0, and at time of analysis there is no public exploit identified and no confirmed active exploitation (not listed in CISA KEV); the practical barrier is the high-privilege authenticated session required, so exposure is limited to instances where an admin account or session can be obtained by an untrusted party.
Unauthenticated remote clients that can reach the Nginx UI node-signature authentication API on versions 2.5.0 through pre-2.6.0 can force the server to stage attacker-controlled request bodies to temporary files and flush them to disk before any digest or cryptographic signature validation occurs, allowing exhaustion of temporary filesystem capacity, disk I/O, and request-processing resources. The impact is availability-only (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) - authentication is not bypassed and there is no confidentiality or integrity impact. No public exploit code was identified at time of analysis and the flaw is not confirmed as actively exploited (no CISA KEV listing); vendor-released patch: 2.6.0, which caps staged node request bodies at 128 MiB and adds a pre-read ContentLength check.
Server-side request forgery in Nginx UI through 2.3.4 lets any authenticated user redirect API requests to an attacker-chosen internal URL, exposing localhost-bound services, internal networks, and cloud metadata endpoints to credential theft and reconnaissance. The flaw requires a valid Nginx UI account and use of the cluster-node proxy path; the independent assessment rates confidentiality high, integrity low, and availability none. No vendor-fixed version is listed, a public PoC reference exists but is not verified as working exploit code, KEV does not list it, EPSS is 0.03% (8th percentile), and the vuln.today priority is act_now.
Remote code execution as root in nginx-ui versions before 2.3.8 via unauthenticated backup restore within 10-minute startup window. Attackers exploit the completely unauthenticated /api/restore endpoint during initial installation to upload malicious backup archives that overwrite app.ini configuration with injected OS commands in TestConfigCmd setting. After automatic application restart, command injection triggers with privileges of the nginx-ui process - typically root in Docker deployments. EPSS data not available; no active exploitation reported but publicly disclosed via GitHub Security Advisory GHSA-4pvg-prr3-9cxr. Patch released in version 2.3.8.
Unauthenticated bootstrap takeover in Nginx UI 2.3.5: any remote client that can reach a still-uninitialized instance during the roughly 10-minute first-run setup window can claim it outright, because POST /api/install accepts attacker-supplied bootstrap data and sets the JWT secret, node secret, certificate email and the initial administrator username and password, after which the attacker simply logs in as the first administrator. Exposure is confined to fresh, rebuilt, ephemeral, LAN-reachable or temporarily exposed deployments - once installation is locked the path closes, so there is no persistent post-install takeover. The vendor advisory ships a standalone proof-of-concept script that was reproduced against the 2.3.5 Docker image, and no public patch was available at time of publication; EPSS is low at 0.04% (12th percentile) but the vuln.today decision label is act_now and SSVC rates technical impact as total.
Unauthenticated attackers who can reach a fresh, uninitialized Nginx UI instance before version 2.3.8 during its first-run setup window can set the initial administrator credentials and permanently take over the application. Despite the 9.8 severity and an act_now priority, exploitation requires the instance to still be uninstalled and the request to arrive within the roughly 10-minute startup window; already-provisioned instances and installations past that window reject the request, which keeps real-world exposure narrow. The issue is patched in 2.3.8; a public PoC reference exists but is not verified as working exploit code, and EPSS is low at 0.08% (24th percentile).
Disabled user accounts in Nginx UI versions before 2.3.4 retain full API access through previously issued JWT tokens for the entire token lifetime, allowing attackers with stolen credentials to maintain persistent access and create new accounts even after administrative remediation attempts. This authentication bypass enables continued confidentiality and integrity compromise of Nginx configurations despite account lockout. Reported by GitHub security advisories; no evidence of active exploitation (not in CISA KEV), but the token-reuse mechanism makes exploitation straightforward for attackers who have already obtained credentials.
Unauthenticated backup download and RCE in Nginx UI before 2.3.3. EPSS 1.0%. PoC available.
Revoked short-tokens in Nginx UI prior to 2.4.1 can be replayed to regain authenticated access to HTTP and WebSocket routes that accept short-token authentication, because token deletion fails to invalidate the corresponding short_token cache entry. Exploitation is authenticated and tightly conditioned: the attacker must already hold a previously issued short token (CVSS PR:L), the account must be disabled and then re-enabled before the stale cache entry expires, and the surviving cache record is then resolved by GetTokenUserByShortToken - a timing-dependent, opportunistic flaw rather than a reliably reproducible one. There is no public exploit identified at time of analysis and no evidence of confirmed active exploitation (no CISA KEV listing); the vendor-released patch is Nginx UI 2.4.1.
Path traversal in Nginx UI (0xJacky) before 2.4.3 allows an authenticated user who can create or modify an automatic backup to write backup archive files - and, when the backup is configured as an encrypted configuration backup, the adjacent encryption key file - outside the validated storage directory, with the privileges of the Nginx UI process. Exploitation requires a valid Nginx UI account with backup-management permissions (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L, 6.3 per the independent assessment) and only takes effect when the configured automatic backup actually runs; the attacker influences the generated archive/key filename rather than arbitrary file content. The issue is fixed in version 2.4.3, and no public exploit code was identified at time of analysis.
Nginx UI versions 2.2.0 up to but not including 2.6.0 mis-attribute client identity when the application is reached through its bundled reverse proxy without trusted-proxy configuration, so every request appears to originate from loopback. The practical unauthenticated impact (CVSS 5.3, PR:N) is a shared, temporary login ban: failed password or OTP attempts from different external clients are all counted against 127.0.0.1, letting an attacker lock out the login endpoint for legitimate users without invalidating existing sessions. A separate consequence is that management requests can satisfy the loopback exception in the IP allowlist, but this path is strongly limited because valid credentials are still required, so it does not amount to authentication bypass or account takeover. No public exploit code has been identified at time of analysis, and the issue is fixed in version 2.6.0.
nginx-ui versions prior to 2.3.8 expose 40+ protected configuration fields through the GetSettings API to authenticated users, including JwtSecret (auth token forgery), NodeSecret (cluster impersonation), and OIDC ClientSecret (OAuth takeover). The protected tag is enforced only during writes but completely ignored during reads, allowing authenticated attackers to extract sensitive secrets and IP whitelist configurations without requiring additional privileges or user interaction.
nginx-ui prior to version 2.3.8 exposes sensitive configuration values including node.secret via an authenticated GET /api/settings endpoint, allowing an authenticated user to retrieve the shared authentication secret and subsequently impersonate the init administrative user by sending requests with the stolen node.secret via the X-Node-Secret header or node_secret query parameter. This enables privilege escalation and full administrative access to the Nginx configuration interface without additional authentication.
nginx-ui before version 2.3.5 allows Cross-Site WebSocket Hijacking (CSWSH) attacks due to improper WebSocket origin validation and insecurely configured authentication cookies. An attacker can trick a logged-in administrator into visiting a malicious webpage that establishes authenticated WebSocket connections to the target nginx-ui instance, enabling information disclosure and administrative actions without explicit user consent. Version 2.3.5 patches the issue; no public exploit code or active exploitation confirmed at time of analysis.
Nginx UI is a web user interface for the Nginx web server. Rated high severity (CVSS 8.9), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Nginx UI is a web user interface for the Nginx web server. Rated medium severity (CVSS 5.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Nginx UI is a web user interface for the Nginx web server. Rated high severity (CVSS 7.7), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Nginx-UI is a web interface to manage Nginx configurations. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Nginx-UI is a web interface to manage Nginx configurations. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Nginx-UI is a web interface to manage Nginx configurations. Rated high severity (CVSS 7.1), this vulnerability is remotely exploitable. Public exploit code available and EPSS exploitation probability 16.0%.
Nginx-UI is an online statistics for Server Indicators Monitor CPU usage, memory usage, load average, and disk usage in real-time. Rated high severity (CVSS 7.0), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
Nginx-ui is online statistics for Server Indicators Monitor CPU usage, memory usage, load average, and disk usage in real-time. Rated high severity (CVSS 7.7), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.