Nginx UI EUVD-2026-97862

Exploitation requires the attacker to already hold any valid authenticated Nginx UI account (PR:L) on an instance running a version prior to 2.4.1 in its default configuration - no special feature or non-default setting must be enabled; the flaw is that the POST /api/users/:id user-management endpoint omits the RequireSecureSession step-up that the self-service password-change path enforces. The limiting factor is the need for a pre-existing low-privilege account: single-admin deployments that never provision secondary users have no untrusted principal to abuse, whereas any multi-user deployment is directly exposed. No user interaction and no 2FA/secure-session step-up are needed once a low-privilege session exists.

This is a credible, prioritizable vulnerability rather than a paper-high score. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 8.7 (High) score are internally consistent with the description: a network-reachable, low-complexity authorization flaw (CWE-285) exploitable by any authenticated low-privilege user with no victim interaction. The VC:H/VI:H/VA:H impact is well justified because successful exploitation yields full takeover of the initial administrator account - effectively total control of the Nginx UI instance and, by extension, the managed Nginx configuration. The one tempering signal is PR:L: the attacker must already hold a valid authenticated account, so this is privilege escalation, not fully unauthenticated compromise, which lowers the realistic blast radius for instances that do not provision low-trust user accounts. No CISA KEV listing and no public exploit code are present in the provided data, so there is no evidence of active exploitation; the only exploitation-adjacent artifact is the vendor patch/commit, which is remediation evidence, not a POC. EPSS and SSVC data were not supplied and cannot be reasoned about. Net: treat as a high-priority patch for any multi-user Nginx UI deployment, but widespread opportunistic exploitation is unproven.

An organization runs Nginx UI (pre-2.4.1) with more than one account - for example a read-only operator account. That low-privilege user sends a POST to /api/users/:id targeting the administrator's ID to set a new password, bypassing the RequireSecureSession step-up that the self-service password-change path enforces. Existing admin tokens are invalidated and the attacker logs in as administrator with full control. No public exploit code is identified in the provided data, though the fixed release and patch commit are published.