NginxProxyManager Nginx Proxy Manager authentication endpoints permit unrestricted credential guessing

Nginx Proxy Manager through 2.16.0 lacks rate-limiting on authentication endpoints, allowing unauthenticated attackers to make unlimited password guesses against any account. Attackers can brute-force login credentials via POST /api/tokens and subsequently guess TOTP codes via POST /api/tokens/2fa to gain full session access and administrative control.

• NginxProxyManager nginx-proxy-manager: versions from 0 through and including 2.16.0 are marked affected in the normalized record. • The same record sets default_status to unaffected, but the listed version range has affected status and should be used when assessing deployed instances. • An upstream project pull request proposes rate limiting for both authentication endpoints, but the reviewed sources do not confirm a specific released version containing the fix. • No separate later or parallel release branch is established by the available evidence.

The flaw is classified as CWE-307 and resides in the authentication routes. The POST /api/tokens flow accepts identity and password material and, for a TOTP-enabled account, issues a short-lived challenge token. POST /api/tokens/2fa verifies the supplied code and returns a full token when the code is valid. The affected implementation lacks effective rate limiting on these authentication endpoints, so an unauthenticated network client can repeat guesses without an application-enforced attempt ceiling. Reachability requires the management API to be exposed to the attacker's network; the available evidence does not establish whether a reverse proxy, deployment topology, or external control adds compensating limits.

• Reachability: The attack is network-based when the authentication endpoints are reachable from the attacker's network. • Authentication: No account or prior privilege is required. • User interaction: No user action is required. • Attack path: The attacker repeatedly submits password guesses to POST /api/tokens and can then submit TOTP guesses to POST /api/tokens/2fa when the target account requires 2FA. • Status: The supplied record marks public exploit as false and provides no known-exploited designation. This does not prove that exploitation is impossible or will not occur.

• The direct technical outcome is online password and TOTP guessing without effective application-level attempt limits on the authentication endpoints. • If the guesses succeed, the attacker can obtain a full session for the target account. Resulting privileges depend on that account's role, so compromise of an administrator may provide broad management control. • TOTP does not remove this attack path because the TOTP verification endpoint is also described as lacking rate limiting. • Confidentiality and integrity impacts may be high after account takeover, but the evidence does not establish a direct availability impact or a specific data incident.

Successful exploitation can result in takeover of any targeted account whose password and, when enabled, TOTP code are guessed. If the compromised account is an administrator, the attacker may gain control of the Nginx Proxy Manager management plane and make changes consistent with that account's privileges. This could expose or alter account data and managed configuration. The available evidence does not establish a direct availability impact or a specific data breach.

1. Install the official Nginx Proxy Manager release that contains the fix for both POST /api/tokens and POST /api/tokens/2fa as soon as the vendor publishes a confirmed fixed release. The record reports that a patch is available, but the reviewed upstream source shows the change as an open pull request rather than a confirmed released version.
2. Until an appropriate release is deployed, place the management API behind trusted access controls and add rate limiting at a reverse proxy or WAF for both endpoints. Treat this as an external compensating control, not as confirmation that the product itself is fixed.
3. If guessing is suspected, reset passwords for at-risk accounts, review and revoke active sessions according to deployment procedures, and investigate administrative changes made after the suspected activity.
4. Keep TOTP enabled and do not disable 2FA as a workaround. Validate that any adopted fix is enabled in production, because the proposed change includes bypass conditions for CI or test environments.

1. Inventory deployed Nginx Proxy Manager versions and identify instances whose management API is reachable from the Internet or other untrusted networks.
2. Review access, reverse-proxy, and audit logs where available for repeated requests to POST /api/tokens or POST /api/tokens/2fa, especially sequences of failed authentication attempts followed by a successful login.
3. Compare the deployed authentication route code or package contents with the vendor fix to verify that both endpoints enforce attempt limits and that no environment setting disables the control.
4. Review successful logins, account changes, and administrative configuration changes after suspicious authentication sequences.
5. These are precautionary monitoring checks, not confirmed indicators of compromise. The absence of suspicious log evidence does not prove that an instance is safe.