Summary
Nginx UI may allow an authenticated session to enroll an attacker-controlled TOTP secret or passkey without requiring the user's current password or an equivalent secure-session check. If an attacker obtains a valid JWT and the relevant enrollment conditions are met, they could establish persistent access that may survive a password change or disrupt the legitimate user's login.
Nginx UI may allow an authenticated session to enroll an attacker-controlled TOTP secret or passkey without requiring the user's current password or an equivalent secure-session check. If an attacker obtains a valid JWT and the relevant enrollment conditions are met, they could establish persistent access that may survive a password change or disrupt the legitimate user's login.
Affected context
The issue occurs in Nginx UI deployments where the OTP enrollment and passkey registration endpoints are accessible through a normal authenticated session rather than a session requiring recent credential reauthentication. The risk is higher when JWTs can be stolen or reused and when enrollment operations do not consistently verify an existing factor or require confirmation of the current password.
The issue occurs in Nginx UI deployments where the OTP enrollment and passkey registration endpoints are accessible through a normal authenticated session rather than a session requiring recent credential reauthentication. The risk is higher when JWTs can be stolen or reused and when enrollment operations do not consistently verify an existing factor or require confirmation of the current password.
Exploit preconditions
- Attack surface: Authenticated HTTP API endpoints for OTP and passkey enrollment
- Required access: A valid, stolen, or otherwise misused JWT associated with a victim account
- Trigger point: A request to enroll an attacker-controlled TOTP secret or passkey
- Additional condition: OTP enrollment may be possible when the victim has not already enabled TOTP; passkey registration lacks an equivalent existing-enrollment guard
- Why exploitation is possible: Enrollment operations accept ordinary authenticated sessions without consistently requiring recent authentication or verification of the current password
- Attack surface: Authenticated HTTP API endpoints for OTP and passkey enrollment
- Required access: A valid, stolen, or otherwise misused JWT associated with a victim account
- Trigger point: A request to enroll an attacker-controlled TOTP secret or passkey
- Additional condition: OTP enrollment may be possible when the victim has not already enabled TOTP; passkey registration lacks an equivalent existing-enrollment guard
- Why exploitation is possible: Enrollment operations accept ordinary authenticated sessions without consistently requiring recent authentication or verification of the current password
Why this happens
The underlying flaw is an inconsistent authentication policy across sensitive account-enrollment endpoints. By placing enrollment handlers outside the stronger secure-session requirement and omitting equivalent verification of the current password or existing factor, the application treats possession of a reusable session token as sufficient authority to change authentication state. This maps primarily to CWE-287, Improper Authentication, and also relates to CWE-306, Missing Authentication for Critical Function.
The underlying flaw is an inconsistent authentication policy across sensitive account-enrollment endpoints. By placing enrollment handlers outside the stronger secure-session requirement and omitting equivalent verification of the current password or existing factor, the application treats possession of a reusable session token as sufficient authority to change authentication state. This maps primarily to CWE-287, Improper Authentication, and also relates to CWE-306, Missing Authentication for Critical Function.
Potential impact
- An attacker may bind a TOTP secret or passkey to the victim's account
- Unauthorized access may persist after the victim changes their password
- The legitimate user could be locked out of or interfered with during authentication
- Account data and administrative capabilities may be exposed or modified
- Compromised accounts could be used to affect Nginx configurations or other connected resources
- An attacker may bind a TOTP secret or passkey to the victim's account
- Unauthorized access may persist after the victim changes their password
- The legitimate user could be locked out of or interfered with during authentication
- Account data and administrative capabilities may be exposed or modified
- Compromised accounts could be used to affect Nginx configurations or other connected resources
General mitigation guidance
Mitigation generally focuses on treating authentication-factor enrollment as a high-risk account operation. Sensitive enrollment and replacement actions should require recent authentication, verification of the current password or an existing factor, and explicit user confirmation. Secure-by-default endpoint policies should apply consistently to every enrollment path, while token scope, lifetime, revocation, and storage should reduce trust in reusable session credentials. Account permissions should follow least privilege, and recovery or administrative workflows should provide controlled factor-removal and rollback mechanisms.
Mitigation generally focuses on treating authentication-factor enrollment as a high-risk account operation. Sensitive enrollment and replacement actions should require recent authentication, verification of the current password or an existing factor, and explicit user confirmation. Secure-by-default endpoint policies should apply consistently to every enrollment path, while token scope, lifetime, revocation, and storage should reduce trust in reusable session credentials. Account permissions should follow least privilege, and recovery or administrative workflows should provide controlled factor-removal and rollback mechanisms.
How teams detect issues like this
Detection can include static analysis and code review checks for sensitive enrollment routes that bypass shared authentication middleware, recent-login checks, or existing-factor verification. Reviewers can compare all password, TOTP, passkey, recovery, and factor-removal endpoints for consistent policy enforcement. Runtime monitoring can flag factor enrollments without a recent reauthentication event, unusual JWT use, new authenticators from unfamiliar clients, and authentication changes followed by password resets or failed logins. Automated API authorization tests and policy-as-code checks can help identify inconsistent endpoint protections.
Detection can include static analysis and code review checks for sensitive enrollment routes that bypass shared authentication middleware, recent-login checks, or existing-factor verification. Reviewers can compare all password, TOTP, passkey, recovery, and factor-removal endpoints for consistent policy enforcement. Runtime monitoring can flag factor enrollments without a recent reauthentication event, unusual JWT use, new authenticators from unfamiliar clients, and authentication changes followed by password resets or failed logins. Automated API authorization tests and policy-as-code checks can help identify inconsistent endpoint protections.
