Nginx UI: Authentication bypass: password login does not enforce a passkey-only second factor (2FA bypass)

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

Nginx UI is a web user interface for the Nginx web server. From 2.0.0 until 2.5.0, POST /api/login checks EnabledOTP but does not require a WebAuthn assertion when EnabledPasskey is true and no TOTP secret is configured. A passkey-only account is therefore issued a session after password verification, despite Enabled2FA reporting that the account has a second factor. An attacker who obtains the password can take over the account and reach administrative functionality without the registered passkey. This issue is fixed in version 2.5.0.

Source published

9 Oct 2026 15:11:44 UTC

Source modified

9 Oct 2026 17:19:53 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 8.1 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Nginx UI is a web user interface for the Nginx web server. From 2.0.0 until 2.5.0, POST /api/login checks EnabledOTP but does not require a WebAuthn assertion when EnabledPasskey is true and no TOTP secret is configured. A passkey-only account is therefore issued a session after password verification, despite Enabled2FA reporting that the account has a second factor. An attacker who obtains the password can take over the account and reach administrative functionality without the registered passkey. This issue is fixed in version 2.5.0.

Source published

Oct 9, 2026, 3:11:44 PM (timezone not stated)

Source modified

Oct 9, 2026, 5:19:53 PM (timezone not stated)

Observed here

7 Nov 2026 05:38:27 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 8.1 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Nginx UI is a web user interface for the Nginx web server. From 2.0.0 until 2.5.0, POST /api/login checks EnabledOTP but does not require a WebAuthn assertion when EnabledPasskey is true and no TOTP secret is configured. A passkey-only account is therefore issued a session after password verification, despite Enabled2FA reporting that the account has a second factor. An attacker who obtains the password can take over the account and reach administrative functionality without the registered passkey. This issue is fixed in version 2.5.0.

Source published

9 Oct 2026 16:17:25 UTC

Source modified

20 Oct 2026 15:24:07 UTC

Observed here

25 Oct 2026 05:17:13 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 8.1 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

## Summary nginx-ui supports two second-factor methods — TOTP (OTP) and WebAuthn passkeys — and reports an account as 2FA-enabled when **either** is configured. However, the password login endpoint (`POST /api/login`) only enforces a second factor when a **TOTP secret** is present. An account that has registered a **passkey but no TOTP** is logged in after password verification alone — the passkey is never requested. This silently downgrades a passkey-protected account to single-factor (password-only) authentication. ## Details The account's 2FA policy treats passkeys as a valid factor (`model/user.go`): ```go func (u *User) EnabledOTP() bool { return len(u.OTPSecret) != 0 } func (u *User) EnabledPasskey() bool { /* true if a passkey row exists */ } func (u *User) Enabled2FA() bool { return u.EnabledOTP() || u.EnabledPasskey() } func (u *User) AfterFind(_ *gorm.DB) error { u.EnabledTwoFA = u.Enabled2FA() // exposed to the UI as `enabled_2fa` return nil } ``` But the login handler only checks `EnabledOTP()` (`api/user/auth.go`, `Login`): ```go u, err := user.Login(json.Name, json.Password) ... if u.EnabledOTP() { // <-- only TOTP is enforced if json.OTP == "" && json.RecoveryCode == "" { c.JSON(http.StatusOK, LoginResponse{Message: "The user has enabled 2FA", Code: Enabled2FA}) // 199 user.BanIP(clientIP) return } if _, err = user.VerifyOTP(u, json.OTP, json.RecoveryCode); err != nil { /* ... */ } secureSessionID = user.SetSecureSessionID(u.ID) } // Passkey-only accounts fall through to here and receive a full session token: accessToken, err := user.GenerateJWT(u) ``` No branch requires a WebAuthn assertion during password login when `EnabledPasskey()` is true. The root cause is the mismatch between the **policy definition** (`Enabled2FA()` = OTP **or** passkey) and the **enforcement check** (`EnabledOTP()` only). The same `EnabledOTP()`-only gating in `RequireSecureSession()` (`internal/middleware/secure_session.go`) means passkey-only users are also exempted from step-up on sensitive actions. ## Proof of Concept Tested against nginx-ui built from source (`go build -tags unembed`) on `127.0.0.1:9000`, with WebAuthn configured and a victim account that has a registered passkey and **no** TOTP. The vulnerable code is identical on the production `main` branch (`api/user/auth.go` `Login` gates on `u.EnabledOTP()` only; verified at commit `6c86e5a`, 2026-05-17). Account state advertised by `GET /api/2fa_status`: ```json {"enabled":true,"otp_status":false,"passkey_status":true, ...} ``` Attacker logs in with **password only** (`POST /api/login`, encrypted params as the client normally sends): ``` HTTP 200 {"message":"ok","code":200,"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."} ``` `code: 200` + a valid JWT = an authenticated session, with the passkey never used. For comparison, the identical account with a TOTP secret instead correctly returns the second-factor challenge: ``` HTTP 200 {"message":"The user has enabled 2FA","code":199} ``` | Account state | `POST /api/login` (password only) | |---|---| | Passkey registered, no TOTP | `code 200` + JWT — **2FA NOT enforced** | | TOTP registered | `code 199` — 2FA challenge enforced | This isolates the defect: the login path enforces OTP but ignores passkeys. ## Impact - Any account protected **only** by a passkey is reduced to password-only authentication. An attacker who obtains the password (phishing, reuse, leak) gains full access despite the registered security key. - In nginx-ui all authenticated users are effectively administrators and the terminal feature grants a host shell, so account takeover leads to full control of the managed nginx instance / host. - Users are given a false sense of security: the UI shows the account as 2FA-enabled while the second factor is not enforced at login. ## Remediation - Gate the second-factor decision on `u.Enabled2FA()` (not `u.EnabledOTP()`) in `Login`, in both SSO callbacks, and in `RequireSecureSession()`. - For a passkey-only user logging in with a password, return a "passkey assertion required" challenge and complete login only after a successful WebAuthn assertion (the `begin_passkey_login` / `finish_passkey_login` flow already exists and should be required as the second step). - Centralize session-token issuance so no login entry point can skip the 2FA decision. ## Affected components - `api/user/auth.go` — `Login` - `model/user.go` — `EnabledOTP`, `EnabledPasskey`, `Enabled2FA`, `AfterFind` - `api/user/2fa.go` — `get2FAStatus` - `internal/middleware/secure_session.go` — `RequireSecureSession`

Source published

9 Oct 2026 17:08:15 UTC

Source modified

19 Oct 2026 21:41:12 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Publisher rating · HIGH

Nginx UI: Authentication bypass: password login does not enforce a passkey-only second factor (2FA bypass) in github.com/0xJacky/Nginx-UI

Source published

19 Oct 2026 21:08:26 UTC

Source modified

19 Oct 2026 21:31:49 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.