MISP EUVD-2026-84499

Requires the target MISP account to be in a specific combined state: disabled AND TOTP (two-factor) enrolled. The attacker must reach the UsersController login() endpoint (network-accessible, no authentication needed) and must be able to distinguish a TOTP-verification prompt from an immediate login rejection. What strictly limits impact: the downstream identify() call re-validates and rejects the disabled account, so no authenticated access is ever granted; the only leak is the difference in login response for the narrow disabled-plus-TOTP-enrolled population. There is no confidentiality of stored data, no integrity, and no availability impact.

This is a high-CVSS-but-negligible-real-risk finding. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L, base 6.9 Medium) reflects only a low-confidentiality impact reachable remotely without auth, and even that overstates reality. The vulnerability class is CWE-285 improper authorization, but the commit diff and the description confirm no actual authorization decision is bypassed: the omitted User.disabled column makes the disabled-user guard in the TOTP branch a no-op, yet the subsequent identify() call re-validates and still rejects the disabled account. The commit message itself labels this 'harmless in practice.' No EPSS score, no CISA KEV listing, and no public exploit code are present in the input - consistent with a low-value bug. The only observable effect is a login-response distinguisher (a TOTP prompt is shown to a disabled TOTP-enrolled user instead of immediate rejection) plus a PHP 'Undefined array key' warning in logs. Note the tension: the CVSS base score of 6.9 and the 'Authentication Bypass' tag both imply a meaningful auth flaw, but the source-of-truth commit demonstrates authentication is NOT bypassed - treat the score/tag as inflated relative to the vendor's own analysis.

An unauthenticated attacker who knows or guesses that a specific MISP account has been disabled but still has TOTP enrolled submits that username to the login endpoint and observes whether a TOTP prompt is returned versus an immediate rejection, inferring the account's disabled/TOTP-enrolled state. No credential compromise or session results, since identify() still refuses to authenticate the disabled account. No public exploit code is identified at time of analysis.