CVE-2026-49870 in Snipe-IT
Summary
by MITRE • 08/19/2026
Snipe-IT is an IT asset/license management system. Prior to 8.6.1, POST /two-factor has no rate limiting, lockout, or attempt counter, allowing an attacker with valid credentials to submit unlimited TOTP guesses against the three accepted codes created by config/google2fa.php window=1. A successful guess creates a fully authenticated session. When two_factor_enabled is 1, POST /account/profile with two_factor_optin=0 can disable two-factor authentication without OTP reverification, while required mode 2 prevents that opt-out. An administrator can also use POST /api/v1/users/two_factor_reset to clear another user's secret. This issue is fixed in version 8.6.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
Snipe-IT serves as a comprehensive IT asset and license management platform, relying heavily on secure authentication mechanisms to protect sensitive organizational data. A critical security deficiency was identified in versions prior to 8.6.1 regarding the implementation of Two-Factor Authentication (2FA). Specifically, the endpoint POST /two-factor lacked essential brute-force protection measures such as rate limiting, account lockout policies, or attempt counters. This architectural flaw allowed an attacker possessing valid user credentials to submit unlimited Time-based One-Time Password (TOTP) guesses against the three accepted codes generated by the google2fa configuration window. Since TOTP codes are typically six digits long and the system accepts a small window of valid codes due to potential time synchronization drift, the effective search space for brute-forcing is significantly reduced compared to standard cryptographic hashes. The absence of any throttling mechanism means that an attacker can automate this process rapidly, increasing the probability of guessing a valid code within a short timeframe.
The operational impact of this vulnerability is severe, as successfully guessing one of the accepted TOTP codes results in the creation of a fully authenticated session for the targeted user account. This effectively bypasses the second layer of authentication intended to secure access to the application. The risk is exacerbated by additional flaws related to the management and disabling of 2FA settings. When the two_factor_enabled configuration flag is set to one, an attacker who has gained initial access or compromised credentials can exploit the POST /account/profile endpoint with the parameter two_factor_optin set to zero. This action disables two-factor authentication for that user without requiring re-verification via OTP, thereby stripping away future security protections permanently until manually restored by an administrator.
Furthermore, administrative privileges introduce additional vectors for abuse regarding 2FA management. An authenticated administrator can utilize the POST /api/v1/users/two_factor_reset endpoint to clear another user's secret key. While this feature is intended for legitimate account recovery or troubleshooting, its existence combined with insufficient access controls could allow a malicious insider or an attacker who has compromised administrative credentials to disable 2FA for other users without their knowledge. It is important to note that the vulnerability regarding disabling 2FA via profile updates is mitigated when the system is configured in required mode two, which prevents users from opting out of mandatory authentication protocols. However, the brute-force weakness on the verification endpoint remains a critical flaw regardless of these administrative controls.
This vulnerability aligns with CWE-307, Improper Restriction of Excessive Authentication Attempts, as it fails to limit the number of failed login attempts, facilitating offline or online brute-force attacks. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1110.001, Brute Force: Password Guessing, where an adversary uses automated tools to guess credentials due to a lack of detection and prevention mechanisms. The ability to disable 2FA without re-verification also touches upon CWE-693, Protection Mechanism Failure, specifically in the context of authentication state management. To mitigate these risks, organizations must upgrade Snipe-IT to version 8.6.1 or later, which addresses the lack of rate limiting on the two-factor verification endpoint. Additionally, administrators should ensure that required mode two is enabled for all users where feasible to prevent unauthorized disabling of multi-factor authentication through profile modifications. Regular auditing of user security settings and monitoring for unusual login patterns can further enhance defense-in-depth strategies against such authentication bypass attempts.