Nginx UI CVE-2026-107808

Exploitable only against an Nginx UI account (versions 2.0.0 through 2.4.x) that has a registered passkey as its ONLY second factor (EnabledPasskey true with no TOTP secret configured), so Enabled2FA reports a second factor while the login path never enforces a WebAuthn assertion. The decisive prerequisite is that the attacker must already possess the account's valid password - the flaw converts a known-password condition into full account takeover by skipping the passkey step. Limiting factors: accounts protected by TOTP are not affected (the EnabledOTP check still applies); accounts with no 2FA are out of scope; and no exploitation is possible without the password, so this is not remote-unauthenticated against a default install despite the PR:N metric.

This is a genuine authentication-control flaw (CWE-287) rather than inflated CVSS noise, but its real-world priority is moderated by a hard precondition. The input provides no EPSS score, no CISA KEV listing, and no POC indicator, so there is no signal of active or probable exploitation - only the CVSS 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). The vector's PR:N technically marks it unauthenticated, yet exploitation is impossible without first obtaining the victim's valid password, which is why AC:H is correctly applied and why raw PR:N overstates ease of access - the 'privilege' is effectively a stolen credential, not system access. The CVSS network vector and description are consistent (the flaw is in the POST /api/login HTTP handler). No SSVC decision data was supplied. Net assessment: a serious defense-in-depth failure (2FA that silently does not enforce the second factor for passkey-only accounts) that becomes critical only after a password is compromised; treat as a high-priority patch for any Nginx UI instance using passkey-only accounts, but it is not a wormable, unauthenticated internet-wide risk.

An attacker who has already harvested an administrator's password (via phishing, reuse, or a prior leak) targets an Nginx UI account configured with a passkey as its only second factor. They send a single POST /api/login request with the valid password; because the server checks EnabledOTP but never demands a WebAuthn assertion for passkey-only accounts, a full authenticated session is issued and the attacker reaches administrative nginx-configuration functionality without ever presenting the passkey. No public exploit identified at time of analysis, and the attack leverages a simple authenticated API call (no special tooling required).