Snipe-IT's TOTP is Brute-Forceable Due to Missing Rate Limiting on `POST /two-factor`
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
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
snipe/snipe-itPackagist | < 8.6.0 | 8.6.0 |
Affected products
1Patches
Vulnerability mechanics
Root cause
"Missing rate limiting, lockout, or attempt counter on POST /two-factor allows unlimited TOTP brute-force guesses."
Attack vector
An attacker with valid credentials submits unlimited TOTP guesses to `POST /two-factor` [ref_id=1]. The 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 [ref_id=1]. After a correct guess, the attacker holds a fully authenticated session. If 2FA is in optional mode (`two_factor_enabled='1'`), the attacker can then disable 2FA via `POST /account/profile` with `two_factor_optin=0` without OTP re-verification, making the account accessible with the password alone on future logins [ref_id=1]. For admin targets, `POST /api/v1/users/two_factor_reset` additionally clears another user's 2FA secret [ref_id=1].
Affected code
The `POST /two-factor` endpoint lacks any rate limiting, lockout, or attempt counter, allowing unlimited TOTP guesses. Additionally, `POST /account/profile` with `two_factor_optin=0` disables 2FA without requiring OTP re-verification when 2FA is in optional mode (`two_factor_enabled='1'`). For admin targets, `POST /api/v1/users/two_factor_reset` can clear another user's 2FA secret.
What the fix does
The patch (v8.6.0) introduces rate limiting, lockout, or an attempt counter on the `POST /two-factor` endpoint to prevent brute-force TOTP guessing [ref_id=1]. The advisory does not detail the exact mechanism, but the fix closes the unlimited-guess window that made the 3-in-1,000,000 acceptance rate exploitable. No additional details about the patch diff are available in the bundle.
Preconditions
- authAttacker must have valid credentials (username and password) for the target account
- configTarget instance must have 2FA enabled (either optional or required mode)
- networkAttacker must be able to reach the POST /two-factor endpoint over the network
Generated on Jun 24, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.