Authentication Bugs

When a user logs out, their session token or authentication cookie should be invalidated server-side. If the server only clears client-side state but does not revoke the session, the old token continues to work — allowing the user, or anyone who obtained the token, to access protected resources after logout.

A password reset link contains a one-time token that should be invalidated immediately after the password is changed. If the token is not marked as used, anyone with access to the original reset link — via email forwarding, a shared inbox, or a previously intercepted email — can trigger another password reset and take over the account.

The login endpoint POST /api/auth/login accepts an unlimited number of credential attempts per client with no rate limiting, no account lockout, and no CAPTCHA. An attacker can automate thousands of password guesses per minute against any account without triggering any throttle or block.

A TOTP one-time code used to complete an MFA login can be submitted again in a second login attempt within the same 30-second validity window and still passes verification. The server validates the code against the current time window but does not record that this specific code has already been consumed, allowing an attacker who intercepted the code to replay it.

When a user requests a second password reset link, the server issues a new token without invalidating the first one. Both tokens remain valid until they expire or are used. An attacker who previously captured the first reset email — via phishing, a shared inbox, or forwarded mail — can still use that token to take over the account even after the user issued a fresh request.

A JSON Web Token's payload contains sensitive information — full personal data, internal flags, or secrets. Because a JWT is signed but not encrypted, anyone holding the token can decode and read the payload, so anything placed there is effectively exposed to the client and to anyone who captures the token.