CVE-2026-95754: MISP: Disabled-user check ineffective in pre-authentication TOTP login branch
In MISP's UsersController login() method, the pre-authentication database query used for the TOTP (two-factor authentication) verification branch did not include the User.disabled column in its SELECT fields list. The query selected only User.password, User.totp, and User.hotpcounter. When the TOTP branch subsequently accessed $unauthuser['User']['disabled'], the key was absent from the result set, producing a PHP 'Undefined array key' warning and causing the expression to evaluate as null (falsy). As a result, the disabled-user guard in the TOTP branch was effectively a no-op: a disabled, TOTP-enrolled user could proceed to the TOTP verification step rather than being rejected at that point.
The commit message explicitly states this was 'harmless in practice' because the subsequent identify() call re-validates the user and would still reject a disabled account.
The practical security impact is therefore minimal, limited to a very small information-disclosure difference in the login response (a TOTP prompt is presented instead of an immediate rejection) and a PHP warning in application logs.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Add User.disabled to the fields array of the pre-authentication database query used by the TOTP verification branch so disabled users are rejected before TOTP verification.
MISP UsersController login() Pre-authentication TOTP find() query fields = User.password, User.totp, User.hotp_counter, User.disabled
Event History
Frequently Asked Questions
Can a disabled account successfully log in through the TOTP flow?
No. Although the pre-authentication TOTP branch failed to enforce the disabled-user check, the subsequent identify() call re-validates the account and rejects disabled users.
Which systems are exposed to the observable behavior?
The behavior applies to MISP instances where a disabled user is enrolled in TOTP and reaches the pre-authentication TOTP login branch. The user may receive a TOTP prompt instead of an immediate rejection, and the application may log a PHP "Undefined array key" warning.
What is the practical impact if the issue is not immediately patched?
The stated impact is minimal: a small login-response information difference and warning noise in application logs. The available information does not indicate that disabled accounts can authenticate or gain access.