In the MISP UsersController login flow, the TOTP branch performed a pre‑authentication database query that omitted the User.disabled column. Because the result set lacked the disabled key, the subsequent check treated the missing value as null, effectively bypassing the disabled‑user guard. The effect is that a user whose account is disabled and who has TOTP enrollment can reach the TOTP prompt instead of being immediately denied. The only practical consequences are a minor difference in the login response and a PHP warning emitted to application logs. No remote code execution or privilege escalation is possible, and the intent of the authentication flow remains intact after the final identify() validation.

The flaw exists in the MISP platform, specifically the MISP MISP product. All released releases prior to the patched commit are affected; the vendor has provided a fix that adds the User.disabled field to the pre‑authentication query.

The CVSS score of 6.9 indicates a medium severity vulnerability. The EPSS score is not available, and the flaw is not listed in CISA KEV, suggesting that it is not known to be actively exploited in the wild. Attackers would need to supply valid credentials for a disabled account that has TOTP enabled, which is a relatively low‑probability scenario. Consequently, the overall risk is low to medium, with the primary impact being the visibility of a PHP warning and a small information disclosure in the login prompt.