A Perfect 10.0: MISP's LDAP-Plus-OTP Setup Let Attackers Skip the Second Factor Entirely

MISP, the open-source malware-information and threat-intelligence sharing platform that underpins a large share of the world's CSIRT and SOC tooling, has disclosed an authentication-bypass vulnerability that the National Vulnerability Database scores at a flat 10.0 — the maximum possible CVSS v3.1 base score. Tracked as CVE-2026-10611, the flaw is narrow in its preconditions but severe in its consequence: in the affected configuration, the second authentication factor that operators believed was mandatory could simply be skipped.

The bug lives at the intersection of two settings that security-conscious deployments deliberately turn on together. With LdapAuth.mixedAuth=true, MISP allows users to authenticate through an external plugin such as LDAP. With Security.require_otp=true, the platform is supposed to demand a one-time password — TOTP, HOTP, or an emailed code — on top of those primary credentials. The intent is textbook defense-in-depth: even an attacker who phishes or brute-forces a directory password should be stopped at the OTP wall. The vulnerability is that the wall was, in practice, optional.

"As a result, an attacker with valid primary authentication credentials could bypass the required OTP step by authenticating through the plugin-backed login flow and then directly accessing another application URL instead of completing the OTP verification page. This allows access to the application as the affected user without providing a valid TOTP, HOTP, or email OTP code."— NVD, source

The mechanism is a sequencing error, the kind that static analysis rarely catches because every individual line of code is correct. According to the NVD record, users authenticated through a plugin "may have their authenticated session established during the application beforeFilter phase before the normal login flow enforces the OTP challenge." In other words, by the time MISP got around to presenting the OTP form, the session cookie was already valid. An attacker who supplied a correct LDAP username and password and then, instead of typing a code, navigated to any other authenticated route, was simply let in as that user.

Why the maximum score is justified here

A 10.0 is rare, and the CVSS vector explains why this one earns it. The string is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: network-reachable, low attack complexity, no privileges required beyond the leaked primary credential, no user interaction, and — critically — a changed scope with high impact across confidentiality, integrity, and availability. The scope change reflects that compromising the authentication layer does not just expose one account; it hands an attacker the keys to whatever that account can touch inside a platform whose entire purpose is to centralize sensitive indicators of compromise, attribution data, and unpublished threat reporting.

That is the part defenders should sit with. MISP instances are, by design, repositories of an organization's most operationally sensitive security knowledge. They aggregate the IOCs a SOC is hunting on, the events it is correlating, and frequently the early, unredacted details of incidents that have not yet been disclosed. An OTP bypass that yields a logged-in session is therefore not a peripheral information leak — it is access to the crown jewels of a defender's situational awareness, potentially including the data that other sharing partners contributed under a trust agreement.

Who is actually exposed

The honest framing is that this is a configuration-dependent vulnerability, and the precondition is meaningful. The flaw only manifests where plugin-based authentication is enabled and OTP is expected to be mandatory — the very combination that careful operators adopt. An organization running MISP with local accounts and no OTP requirement is not affected by this specific path, and one running LDAP without any OTP enforcement never had the second factor to bypass. The cruel irony is that the deployments most exposed are the ones that did the extra work to bolt on multi-factor authentication on top of their directory.

There is also a credential prerequisite: an attacker needs valid primary authentication credentials to reach the plugin login flow in the first place. That tempers the "unauthenticated internet randos" reading of a 10.0. But it should not be over-weighted. Directory credentials are exactly what credential-stuffing, phishing, and prior-breach reuse produce in volume, and the entire reason an organization deploys OTP is the assumption that those primary credentials will eventually leak. This vulnerability defeats that assumption at the moment it matters most.

The fix and the remediation path

The remedy is conceptually simple and lives in the order of operations. Per the published advisory, the corrected flow "ensures that OTP requirements are checked immediately after plugin authentication and before the user session is established, redirecting users to the appropriate OTP challenge when required." Moving the gate ahead of session establishment closes the window in which a half-authenticated request could be promoted to a full session by side-stepping to another URL.

For operators, the action items are unambiguous. Update to the patched MISP release that carries the commit referenced in the NVD entry. Until that patch is applied, the only reliable interim mitigation is to remove the dangerous combination — either disable LDAP mixed authentication or, less ideally, recognize that the OTP enforcement you configured is not currently providing the guarantee you think it is. Reviewing access logs for sessions that reached authenticated routes without a corresponding OTP challenge is a sensible post-patch hygiene step, particularly on internet-exposed instances.

The broader lesson generalizes well beyond MISP. Sequencing bugs in authentication middleware — where a session is minted a beat too early relative to the policy checks that are supposed to govern it — are a recurring and under-appreciated class of failure. They tend to score brutally because they collapse a multi-factor design back down to single-factor, silently, without any error the legitimate user would ever notice. CVE-2026-10611 is a clean, maximum-severity example of exactly that pattern, and a reminder that where a check runs is as load-bearing as whether it runs.