CVE-2026-107180 in MISP
Summary
by MITRE • 10/07/2026
On MISP instances configured to require TOTP enrolment (Security.otp_required), the enforcement of the mandatory two-factor authentication setup applied only to standard browser requests. An authenticated user who had not yet enrolled in TOTP could bypass the forced setup by issuing any non-browser request type, including AJAX/XHR calls, REST API requests, .json format URLs, restSearch queries, or automation actions. Because these machine-readable request shapes cannot follow the redirect that the browser path uses to send the user to the TOTP enrolment page, the guard simply skipped the check and the user retained full access to the instance without completing the required second-factor setup.
The initial fix (commit 8deb0619e) added a guard specifically for AJAX requests. A follow-up fix (commit 6b527ba6e) broadened the guard to cover every non-browser request shape, while preserving the exemption for identities authenticated via API key (logged_by_authkey flag).
Impact: an authenticated user on an otp_required instance can operate with full access indefinitely without enrolling in TOTP, nullifying the instance-level two-factor authentication policy.
Affected version: <2.5.48
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability described represents a critical bypass of mandatory multi-factor authentication controls within MISP instances configured to enforce Time-based One-Time Password enrollment through the Security.otp_required setting. This flaw stems from an incomplete implementation of security guards designed to intercept and redirect users who have not yet completed the TOTP setup process. The original logic relied on detecting standard browser requests, typically identified by specific HTTP headers or user-agent strings that indicate a human-operated web browser is making the request. When such a request was detected from an unenrolled authenticated user, the system would issue an HTTP redirect to force the user onto the TOTP enrollment page before granting access to protected resources. However, this logic failed to account for machine-readable or programmatic requests that do not follow standard browser navigation patterns.
The technical flaw lies in the inability of non-browser request types to handle HTTP redirects as browsers do. When a server returns a redirect status code (such as 302 Found) to an AJAX/XHR call, REST API client, or automated script requesting data in JSON format, these clients typically do not automatically follow the Location header to navigate to a new page. Instead, they often return the raw response with the redirect status and headers to the calling application logic. In this specific implementation, the security guard interpreted this lack of navigation as an indication that the request was non-browser-based and therefore exempt from the TOTP enforcement check. Consequently, any authenticated user could bypass the mandatory two-factor authentication requirement simply by issuing requests via these alternative channels, retaining full access to the instance without ever completing the required second-factor setup.
This vulnerability effectively nullifies the organization's multi-factor authentication policy for a significant subset of potential attack vectors. While an attacker might not be able to use standard web browsers to bypass the check, they can easily exploit REST API endpoints or automated scripts that interact with MISP programmatically. This allows an authenticated user who has compromised credentials but lacks physical access to their TOTP device to maintain persistent and full administrative or operational control over the instance. The impact is severe because it undermines a core security control intended to protect against credential theft, allowing unauthorized actors to exfiltrate sensitive threat intelligence data or manipulate sharing rules without triggering additional authentication challenges.
The remediation strategy involved updating the application logic to explicitly handle non-browser request types rather than relying on implicit assumptions about client behavior. The initial fix targeted AJAX requests specifically, recognizing that these were a common vector for bypassing browser-centric checks. A subsequent patch broadened this scope to cover all non-browser request shapes, including REST API calls and JSON format URLs. Crucially, the updated logic preserves exemptions for identities authenticated via API keys, indicated by the logged_by_authkey flag. This distinction is vital because API key authentication often implies a service-to-service interaction where TOTP enrollment may not be applicable or required in the same manner as user-based browser sessions. By explicitly checking request types and handling redirects appropriately for machine clients, the system ensures that all interactive human users are forced to complete TOTP setup regardless of how they initiate their session.
From an industry standards perspective, this vulnerability aligns with CWE-287: Improper Authentication, specifically relating to the failure to enforce multi-factor authentication consistently across all access methods. It also reflects weaknesses in input validation and request handling that allow attackers to bypass security controls by exploiting differences in client behavior, a pattern often associated with logic flaws rather than simple injection attacks. In terms of MITRE ATT&CK, this vulnerability facilitates Initial Access and Persistence tactics where an attacker leverages valid credentials but circumvents additional authentication layers to maintain undetected access. Organizations running MISP versions prior to 2.5.48 must upgrade immediately to ensure that the mandatory TOTP enforcement applies uniformly across all interaction methods, thereby closing the gap between browser-based security policies and programmatic API usage.