Snipe-IT's TOTP is Brute-Forceable Due to Missing Rate Limiting on `POST /two-factor`
Impact
POST /two-factor had no rate limiting, lockout, or attempt counter. An attacker with valid credentials can submit unlimited TOTP guesses. The TOTP implementation accepts the current code plus one step on either side (config/google2fa.php window=1), so at any instant 3 of 1,000,000 codes are accepted.
Source excerpt · OSVAffected packages
Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.
| Affected range | Recorded fix |
|---|---|
| Earlier releases before 8.6.0Ecosystem versions | 8.6.0 |
Version evidence: OSV · GHSA-mr8g-2mj4-pcq2
View original version evidence (276 explicit versions)
Original source description
Impact
POST /two-factor had no rate limiting, lockout, or attempt counter. An attacker with valid credentials can submit unlimited TOTP guesses. The TOTP implementation accepts the current code plus one step on either side (config/google2fa.php window=1), so at any instant 3 of 1,000,000 codes are accepted.
After a correct guess the attacker holds a fully authenticated session. If the instance is configured with 2FA in optional mode (two_factor_enabled='1'), the attacker can additionally disable 2FA via POST /account/profile with two_factor_optin=0. No OTP re-verification is required. The account is then accessible with the password alone on future logins. If 2FA is in required-for-all mode (='2'), the per-user opt-out path is closed and the impact stops at session-level account takeover. For an admin target, POST /api/v1/users/two_factor_reset additionally clears another user's 2FA secret.
Patches
Patched in v8.6.0