CVE-2026-92003 in MISP
Summary
by MITRE • 09/15/2026
Affected versions of MISP do not consistently apply the existing authentication-failure logging throttle.
Two API authentication failure branches wrote directly to the Log model:
- API requests with no authentication key; - requests supplying an API key with an incorrect length
Unlike other authentication failures, these paths bypassed _shouldLog(), so every request could create another durable auth_fail entry.
Version affected: ≤2.5.45
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability in versions of MISP up to and including 2.5.45 represents a significant flaw in the application's authentication failure handling mechanism, specifically concerning API endpoint security controls. The core issue lies in the inconsistent implementation of rate limiting for failed login attempts. While standard authentication failures are subject to throttling mechanisms designed to mitigate brute-force attacks, specific code paths related to malformed or missing API credentials bypass these protective measures entirely. This architectural oversight allows an attacker to generate a high volume of unthrottled requests without triggering the expected defensive responses, thereby undermining the integrity of the account lockout and rate-limiting policies intended to protect user accounts from automated credential stuffing attacks.
Technically, the flaw manifests in two distinct API authentication failure branches that write directly to the Log model without passing through the _shouldLog() validation function. The first branch is triggered when an API request is made with no authentication key provided at all. The second branch activates when a request includes an API key but supplies one with an incorrect length, indicating malformed input rather than just invalid credentials. By bypassing the _shouldLog() check, these specific error conditions do not increment the counter used for throttling logic nor are they subject to the same frequency restrictions applied to standard password-based authentication failures. This means that every single request falling into either of these categories results in a new durable entry being written to the database logs, regardless of how rapidly those requests arrive from a single source or across multiple sources targeting specific accounts.
The operational impact of this vulnerability is multifaceted and severe. From an availability perspective, the ability to generate unlimited log entries can lead to rapid disk space exhaustion on the server hosting MISP, potentially causing service degradation or complete denial of service for legitimate users if storage quotas are reached. This constitutes a resource exhaustion vector that attackers can exploit with minimal effort by simply sending requests lacking proper API keys or using incorrectly sized keys. Furthermore, from an integrity and monitoring standpoint, this behavior creates significant noise in the security logs. The influx of unthrottled authentication failure entries can obscure genuine attack patterns, making it difficult for security operations centers to detect actual brute-force attempts against valid accounts. This log flooding effectively masks malicious activity behind a curtain of benign-looking but voluminous error messages, reducing the efficacy of intrusion detection systems that rely on clear signal-to-noise ratios in logging data.
From a classification standpoint, this vulnerability aligns with CWE-780: Use of RSA Algorithm for Key Wrapping if considered under broader cryptographic misuse contexts, but more accurately maps to CWE-352: Cross-Site Request Forgery (CSRF) is not applicable here; instead it falls squarely under CWE-196: Unsuccessful Downcast or Type Conversion leading to unexpected behavior and CWE-770: Allocation of Resources Without Limits or Throttling. In the context of the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with T1110: Brute Force, specifically by allowing attackers to bypass rate-limiting controls that are part of standard brute-force mitigation strategies. It also relates to T1562: Impair Defenses, as the log flooding impairs the ability of defenders to monitor and respond to actual threats effectively. The lack of proper input validation for API key length further touches upon CWE-20: Improper Input Validation, although the primary security impact stems from the failure to enforce resource limits during authentication processing.
Mitigation strategies must address both the immediate code flaw and broader architectural resilience. For organizations running affected versions, upgrading to a version of MISP greater than 2.5.45 is the primary remediation step, as this issue has been resolved in subsequent releases where the logging logic was corrected to respect throttling rules for all authentication failure types. In environments where immediate patching is not feasible due to operational constraints, temporary mitigations should focus on implementing network-level rate limiting using firewalls or reverse proxies such as Nginx or Apache. These external controls can restrict the number of requests allowed from a single IP address within a given time window, effectively neutralizing the ability to flood logs regardless of whether the application layer enforces its own throttling correctly. Additionally, administrators should configure log rotation policies with strict size limits and automated archival to prevent disk space exhaustion resulting from excessive logging activity. Monitoring solutions should be tuned to alert on spikes in authentication failure events specifically for API endpoints, allowing for rapid detection and blocking of sources attempting to exploit this resource exhaustion vector before it impacts system stability or obscures other malicious activities.