CVE-2026-95754 in MISP
Summary
by MITRE • 09/22/2026
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.hotp_counter. When the TOTP branch subsequently accessed $unauth_user['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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
In MISP's UsersController login method, a pre-authentication database query used for two-factor authentication verification failed to include the User.disabled column in its SELECT fields list. The query selected only User.password, User.totp, and User.hotp_counter. When the TOTP branch subsequently accessed $unauth_user['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 or falsy. As a result, the disabled-user guard in the TOTP branch became effectively inactive, allowing a disabled but TOTP-enrolled user to proceed to the TOTP verification step rather than being rejected immediately 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 where a TOTP prompt is presented instead of an immediate rejection, along with a PHP warning appearing in application logs. This behavior aligns loosely with CWE-209 as it generates unnecessary error messages that could potentially aid attackers in enumerating valid accounts or understanding internal logic flow during authentication attempts.
From an ATT&CK perspective, this vulnerability relates to TA0001 Initial Access and T1078 Valid Accounts since it involves the handling of disabled credentials during login processes. Although the flaw does not directly allow unauthorized access due to subsequent validation checks, it represents a minor deviation from expected security controls by allowing slightly more interaction with disabled accounts than intended. The absence of proper input sanitization or complete data retrieval for critical authentication fields can lead to unexpected application behavior that might be exploited in conjunction with other vulnerabilities.
Mitigation strategies should focus on ensuring all necessary user attributes are retrieved during pre-authentication checks, particularly those related to account status and security settings like disabled flags. Developers must verify that database queries used for authentication decisions include all required columns to prevent undefined key errors and ensure consistent evaluation of access control conditions. Additionally, implementing robust error handling mechanisms can suppress or properly log such warnings without exposing internal details to end users while maintaining accurate audit trails for security monitoring purposes.