Nginx UI CVE-2026-84313

Requires the attacker to already possess a valid authenticated session (a stolen JWT) for the target user - exploitation is not possible unauthenticated (PR:L). The two vulnerable endpoints, POST /api/otp_enroll and POST /api/finish_passkey_register, were registered outside the RequireSecureSession middleware and do not re-verify the current password. For the TOTP path, a limiting precondition applies: the victim must NOT have already enabled TOTP, because that path relies on an existing-enrollment guard; the passkey registration path has no equivalent guard and is exploitable regardless of prior enrollment. No user interaction by the victim is needed. The principal limiting factor is the prerequisite theft of a live session token, so defenders should weigh JWT/session exposure (XSS, token leakage) as the true gating condition.

Signals are mixed and must be read together. The NVD CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N, C:H/I:H/A:H = 8.8) indicates a network-reachable, low-complexity flaw with high impact, but the PR:L metric is decisive: exploitation is NOT unauthenticated - it requires the attacker to already hold a valid victim session (a stolen JWT), as the description explicitly states. This makes the vulnerability a post-compromise persistence/account-takeover primitive rather than a standalone wormable entry point. No EPSS score, SSVC decision, or KEV status was supplied in the input, so widespread-exploitation probability cannot be quantified and there is no evidence of active exploitation. No public exploit code was identified; the only source-code artifact is the vendor's remediation commit, not a weaponized POC. Net assessment: a genuinely serious issue for anyone running Nginx UI (full management-panel takeover that survives a password change), but realistic urgency is gated by the prerequisite JWT theft and tempered by the absence of KEV/EPSS/POC signals. Treat as a high-priority patch for exposed Nginx UI instances while recognizing it is conditional, not drive-by. EPSS data is missing and should be checked before final prioritization.

An attacker who has obtained a legitimate user's JWT (e.g., via XSS, session theft, or a leaked token) sends a POST to /api/finish_passkey_register or /api/otp_enroll, which the server processes without re-verifying the current password or requiring a secure session. The attacker binds their own passkey (or a TOTP secret if the victim had none enrolled), establishing a second authentication factor they control. No public exploit code exists, but the attack is low-complexity and the fix commit reveals the exact unguarded endpoints.