Summary
Nginx Proxy Manager through version 2.16.0 does not sufficiently limit authentication attempts on its login and two-factor authentication endpoints. An unauthenticated attacker may repeatedly guess account passwords and TOTP codes, potentially obtaining a valid session and administrative access.
Affected context
The vulnerability occurs in deployments exposing Nginx Proxy Manager authentication endpoints such as /api/tokens and /api/tokens/2fa. Risk is higher when these endpoints are reachable over the network, accounts use weak or reused credentials, and no external controls limit repeated password or TOTP attempts.
Exploit preconditions
- Attack surface: Network-accessible authentication API endpoints
- Required access: No prior authentication is required
- Trigger point: Repeated password attempts against
/api/tokens, followed by repeated TOTP attempts against/api/tokens/2fa - Why exploitation is possible: Authentication endpoints lack effective rate limiting or equivalent attempt controls, allowing high-volume credential and code guessing
Why this happens
The underlying flaw is insufficient restriction of repeated authentication attempts. Without server-side throttling, lockout, progressive delays, or comparable controls, an attacker can submit unlimited password and second-factor guesses. This behavior maps to CWE-307: Improper Restriction of Excessive Authentication Attempts, because the application does not adequately constrain repeated attempts against authentication mechanisms.
Potential impact
- An attacker may take over accounts with guessable or reused passwords
- Successful password guessing could enable subsequent TOTP-code guessing
- A compromised account could provide access to a valid application session
- An administrative account compromise could allow proxy, host, or user-management changes
- The incident could result in unauthorized access to services routed through the manager
General mitigation guidance
Mitigation generally focuses on enforcing layered controls around authentication attempts and reducing the value of guessed credentials.
Common defensive patterns include:
- Applying server-side rate limits separately to password and TOTP verification attempts
- Using progressive delays, bounded lockouts, or risk-based challenges after repeated failures
- Enforcing strong, unique passwords and phishing-resistant or appropriately protected second factors
- Restricting administrative authentication endpoints through trusted network controls where practical
- Ensuring session tokens are short-lived, securely scoped, and invalidated after suspicious authentication activity
- Applying least privilege so compromised accounts cannot make unrestricted administrative changes
- Monitoring and alerting on distributed, repeated, or geographically anomalous authentication failures
How teams detect issues like this
Detection can combine application, infrastructure, and source-code review signals:
- Review authentication handlers for missing throttling, lockout, delay, or attempt-budget logic
- Use static analysis and code review checks for password and TOTP verification paths that lack abuse controls
- Inspect reverse-proxy and application logs for repeated failures against the same account, endpoint, or source range
- Monitor for distributed guessing patterns involving many addresses or accounts
- Enforce security policies requiring rate limiting on all credential and second-factor verification endpoints
- Use controlled security testing to verify that repeated failures trigger the intended protections without exposing account state
