CVE-2026-86452 in MISP
Summary
by MITRE • 09/07/2026
Affected versions of MISP permit unauthenticated or weakly constrained request paths to perform persistent work without adequate input bounds or rate limiting.
The users/forgot password-reset endpoint accepted an attacker-controlled email value without first imposing a reasonable length bound or validating its format. That value was then used to create an audit log entry and queue a password-reset job, causing the supplied value to be persisted more than once per request. The commit explicitly states that an unbounded unauthenticated request field was stored twice per call with no throttle.
The fix adds:
* a maximum email input length of 1024 bytes;
* email-format validation before persistent work;
* a per-source pre-authentication request budget;
* HTTP 429 responses when that budget is exceeded;
* a 15-minute cooldown for API-access request emails;
* POST-only handling and CSRF protection for the API-access request endpoint.
The new flood filter is specifically intended to limit persistent storage costs from anonymous requests such as password resets, registrations, and failed REST authentication attempts.
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/07/2026
Versions of MISP up to 2.5.45 contain a critical vulnerability that allows unauthenticated or weakly constrained actors to perform persistent operations without adequate input validation or rate limiting controls. This flaw primarily affects the users/forgot password-reset endpoint, which accepts an attacker-controlled email address value without first imposing reasonable length bounds or validating its format against standard patterns. The absence of these safeguards enables malicious entities to exploit the system by submitting excessively long or malformed inputs that trigger resource-intensive backend processes. Specifically, the application uses this unvalidated input to create audit log entries and queue password-reset jobs, resulting in the supplied value being persisted more than once per request. This behavior leads to unnecessary database writes and increased storage consumption, which can be leveraged for denial-of-service attacks or data integrity issues through excessive logging and queuing operations.
The technical root cause of this vulnerability lies in the lack of pre-processing validation on unauthenticated endpoints that trigger persistent state changes. By allowing arbitrary-length strings to enter the system without size constraints, attackers can craft requests designed to maximize database transaction costs. The commit history explicitly notes that an unbounded unauthenticated request field was stored twice per call with no throttle mechanism in place. This design oversight means that each malicious request consumes disproportionate computational resources and storage space relative to legitimate traffic. Such behavior aligns with CWE-787, which addresses out-of-bounds write vulnerabilities, although here the impact is more closely related to resource exhaustion due to unbounded input sizes leading to excessive persistence operations. Furthermore, the lack of rate limiting on these endpoints facilitates automated abuse at scale, allowing attackers to overwhelm system resources through high-volume requests that trigger expensive backend workflows like email queuing and audit logging.
The operational impact of this vulnerability extends beyond simple performance degradation. Attackers can exploit this flaw to cause denial-of-service conditions by flooding the application with password reset requests containing large payloads or numerous distinct entries. This not only consumes server CPU and memory but also fills up database tables with redundant or malicious data, potentially obscuring legitimate audit trails and increasing backup sizes. In environments where MISP is deployed as a critical threat intelligence sharing platform, such disruptions can hinder incident response capabilities and compromise the availability of shared indicators. Additionally, if the system relies on these logs for forensic analysis, the injection of excessive fake entries could dilute the signal-to-noise ratio, making it harder to detect actual malicious activity or track user actions accurately over time.
To mitigate this vulnerability, a comprehensive set of defensive measures has been implemented in subsequent versions. The fix introduces a strict maximum email input length limit of 1024 bytes, ensuring that no single request can carry an excessively large payload that would strain database operations. Email format validation is now enforced before any persistent work begins, preventing malformed or non-email strings from triggering backend processes. A per-source pre-authentication request budget has been established to track and limit the number of requests allowed from a specific source IP address within a given timeframe. When this budget is exceeded, the system responds with HTTP 429 Too Many Requests status codes, effectively throttling abusive clients. Additionally, a fifteen-minute cooldown period for API-access request emails prevents rapid-fire attempts against the same target email address, further reducing the risk of automated abuse.
These mitigations also include enforcing POST-only handling and implementing CSRF protection for the API-access request endpoint to prevent cross-site request forgery attacks that might otherwise bypass client-side restrictions. The new flood filter is specifically designed to limit persistent storage costs from anonymous requests such as password resets, registrations, and failed REST authentication attempts. This approach aligns with ATT&CK technique T1498, Network Denial of Service, by addressing the vector through which resource exhaustion occurs. By combining input validation, rate limiting, and protocol enforcement, the updated version significantly raises the barrier for attackers attempting to exploit this weakness. Organizations running affected versions should upgrade immediately to ensure that their instances are protected against these unauthenticated persistence-based attacks and maintain both availability and data integrity standards required in secure threat intelligence environments.