https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 18:21:28 +0000 https://db.gcve.eu/vuln/cve-2026-95754 <p><strong>Affected:</strong> MISP</p> <p>In MISP&#39;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[&#39;User&#39;][&#39;disabled&#39;], the key was absent from the result set, producing a PHP &#39;Undefined array key&#39; 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.</p> <p>The commit message explicitly states this was &#39;harmless in practice&#39; because the subsequent identify() call re-validates the user and would still reject a disabled account.</p> <p>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.</p> <p><strong>Affected:</strong> MISP</p> <p>In MISP&#39;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[&#39;User&#39;][&#39;disabled&#39;], the key was absent from the result set, producing a PHP &#39;Undefined array key&#39; 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.</p> <p>The commit message explicitly states this was &#39;harmless in practice&#39; because the subsequent identify() call re-validates the user and would still reject a disabled account.</p> <p>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.</p> https://db.gcve.eu/vuln/cve-2026-95754