Description
When brute-force detection locks an account after repeated failed login attempts, a token refresh from an already-authenticated session on the same account resets the lockout state. This allows an attacker to resume password guessing before the lockout period expires, provided the legitimate user is actively using their account during the attack window. The attacker still must guess the correct password — this is a counter reset, not a bypass of password verification.
Version affected
26.5.7, 26.6.2
Expected behavior
A successful cookie-based or token-refresh authentication from an existing session should not alter the brute-force lockout state. The lockout counter and timer should only be affected by explicit password-based authentication attempts. Existing sessions should remain active (locking them would enable attacker-triggered DoS), but they should be neutral with respect to lockout state.
Actual behavior
When the locked account's legitimate user performs an action that triggers a token refresh (e.g., page reload in an already-authenticated browser), the "Temporarily locked" flag is cleared in the admin console and the lockout period is effectively cancelled. A subsequent login attempt from a different browser succeeds with the correct password despite the lockout window not having expired.
Steps to reproduce
- Configure brute-force detection on a realm (e.g., max login failures: 5, lockout duration: 15 minutes).
- In Browser A, authenticate as the target user and remain logged in.
- In Browser B, submit failed login attempts for the same account until the lockout threshold is reached.
- In Browser B, confirm the account is locked by attempting to log in with the correct password — login is denied.
- In Browser A, perform any action that triggers a token refresh (e.g., reload the page).
- In Browser A, verify in the admin console that the "Temporarily locked" toggle is now disabled.
- In Browser B, attempt to log in again with the correct password — login succeeds despite the lockout period not having expired.
This issue was originally tracked in the private repository. Migrated by @abstractj.
Description
When brute-force detection locks an account after repeated failed login attempts, a token refresh from an already-authenticated session on the same account resets the lockout state. This allows an attacker to resume password guessing before the lockout period expires, provided the legitimate user is actively using their account during the attack window. The attacker still must guess the correct password — this is a counter reset, not a bypass of password verification.
Version affected
26.5.7, 26.6.2
Expected behavior
A successful cookie-based or token-refresh authentication from an existing session should not alter the brute-force lockout state. The lockout counter and timer should only be affected by explicit password-based authentication attempts. Existing sessions should remain active (locking them would enable attacker-triggered DoS), but they should be neutral with respect to lockout state.
Actual behavior
When the locked account's legitimate user performs an action that triggers a token refresh (e.g., page reload in an already-authenticated browser), the "Temporarily locked" flag is cleared in the admin console and the lockout period is effectively cancelled. A subsequent login attempt from a different browser succeeds with the correct password despite the lockout window not having expired.
Steps to reproduce
This issue was originally tracked in the private repository. Migrated by @abstractj.