CVE-2026-92002 in MISP
Summary
by MITRE • 09/15/2026
Affected versions of MISP use Redis to throttle repeated authentication-failure log entries. The intent is to avoid excessive duplicate logs while still recording failed authentication activity.
However, User->setupRedis() returns false when Redis cannot be reached. The vulnerable _shouldLog() logic only returned true when a Redis instance existed and no throttle key was present. Therefore, when Redis was unavailable, the function did not allow the log write at all, effectively silencing authentication-failure logging for the duration of the outage.
Version affected: ≤2.5.45
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability in versions of MISP up to 2.5.45 stems from an improper handling of service availability during security-critical operations, specifically regarding the throttling mechanism for authentication failure logs. The application utilizes Redis as a backend store to manage rate limiting and prevent log flooding when multiple failed login attempts occur within a short timeframe. This design choice is intended to balance operational visibility with system performance by ensuring that repeated failures from brute-force attacks are recorded without overwhelming the logging infrastructure or disk I/O subsystems. However, the implementation fails to account for scenarios where the Redis service becomes unreachable due to network issues, configuration errors, or service crashes.
The technical flaw resides in the User->setupRedis() method and its interaction with the _shouldLog() logic. When MISP attempts to initialize the connection to the Redis instance, it expects a successful handshake. If the connection fails for any reason, setupRedis returns false. The subsequent validation within _shouldLog checks whether a valid Redis instance exists before proceeding with log entry creation. Because this check relies strictly on the presence of an active Redis connection rather than implementing a fallback mechanism or defaulting to local logging when remote storage is unavailable, the function evaluates to false in outage scenarios. Consequently, the application suppresses all authentication failure logs for the duration that Redis remains inaccessible.
This behavior results in a significant security impact characterized by information suppression and reduced auditability. Security operations teams rely on accurate and complete log data to detect unauthorized access attempts, credential stuffing attacks, and brute-force patterns. By silencing these entries during periods of infrastructure instability, MISP creates blind spots in the organization's monitoring capabilities. Attackers who can induce or exploit a Redis outage could potentially conduct repeated authentication failures without triggering alerts or leaving traces in the application logs, thereby evading detection by standard security information and event management systems that depend on this data source.
From a classification perspective, this issue aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions, as the software fails to handle an unexpected condition (Redis unavailability) gracefully. It also relates to CWE-778: Insufficient Logging, since critical security events are not recorded under specific operational states. In terms of adversary tactics, this vulnerability supports ATT&CK technique T1078: Valid Accounts or T1110: Brute Force by allowing attackers to operate with reduced risk of detection during infrastructure disruptions.
To mitigate this vulnerability, organizations running affected versions should upgrade MISP to version 2.5.46 or later where the logic has been corrected to ensure logging continuity regardless of Redis availability. In environments where immediate patching is not feasible, administrators can implement a workaround by ensuring high availability for the Redis instance through clustering or redundant configurations to minimize downtime windows. Additionally, deploying an external log aggregation agent that captures application-level errors and warnings directly from system logs rather than relying solely on MISP's internal logging mechanism can provide partial visibility into authentication events even when the primary logging pipeline is compromised. Regular monitoring of infrastructure health metrics for Redis connectivity should also be established to detect such outages promptly and restore full audit coverage.