CVE-2026-92002: MISP Authentication Bypass Vulnerability

CVE-2026-92002 Overview

CVE-2026-92002 affects Malware Information Sharing Platform (MISP) versions ≤2.5.45. The vulnerability resides in the authentication-failure logging mechanism, which relies on Redis to throttle duplicate log entries. When Redis is unreachable, the _shouldLog() function returns false instead of falling back to unconditional logging. This suppresses all authentication-failure records for the duration of a Redis outage. The flaw maps to [CWE-778] Insufficient Logging and allows failed authentication activity to go unrecorded, degrading the platform's audit trail and incident detection posture.

Critical Impact

Authentication failures against MISP go completely unlogged whenever Redis is unavailable, creating a blind spot that attackers can exploit to conduct credential attacks without leaving audit records.

Affected Products

• MISP (Malware Information Sharing Platform) versions ≤2.5.45
• MISP deployments configured to use Redis for authentication-failure log throttling
• Any MISP instance where Redis connectivity may be intermittent or unavailable

Discovery Timeline

• 2026-09-15 - CVE-2026-92002 published to the National Vulnerability Database
• 2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92002

Vulnerability Analysis

MISP uses Redis to deduplicate authentication-failure log entries, preventing log flooding when the same credential fails repeatedly. The throttling logic in AppController.php calls User->setupRedis() to obtain a Redis connection, then checks for the presence of a throttle key such as misp:auth_fail_throttling:<key>. The _shouldLog() function only returns true when a Redis instance exists and no throttle key is set for the current failure.

When Redis is unreachable, setupRedis() returns false. The conditional in _shouldLog() therefore evaluates to false, and the log write is skipped entirely. This inverts the intended behavior: instead of throttling duplicates, the function silences every authentication-failure event during a Redis outage. Attackers observing or causing Redis instability can conduct brute-force or credential-stuffing attacks against the MISP API and web UI without producing forensic records.

Root Cause

The root cause is a fail-closed logging design where the absence of the throttle backend disables the logging action itself. Correct behavior requires that logging always proceed when the throttle store is unavailable, with throttling treated as a best-effort optimization rather than a precondition for writing the log.

Attack Vector

Exploitation requires network access to the MISP authentication endpoints and a coincident condition where Redis is unreachable from the MISP application. An attacker who can trigger, predict, or exploit a Redis outage can then execute password guessing, API key probing, or credential-stuffing attempts that leave no entry in the authentication-failure log.

                 'sql_time' => $sql_time
             ]);
 
-            //if ($redis && !$redis->exists('misp:auth_fail_throttling:' . $key)) {
-                //$redis->setex('misp:auth_fail_throttling:' . $key, 3600, 1);
-                //return true;
-            //}
-
         }
         if ($this->isApiAuthed && $this->_isRest() && !Configure::read('Security.authkey_keep_session')) {
             $this->Session->destroy();

Source: MISP commit a39b25d2f — the patch removes the Redis-gated conditional so that authentication-failure logging proceeds regardless of Redis reachability.

Detection Methods for CVE-2026-92002

Indicators of Compromise

• Gaps or absences in MISP authentication-failure logs that correlate with Redis service downtime or connectivity errors.
• Successful logins from accounts or IP addresses that show no preceding failed-attempt entries during periods of Redis unavailability.
• Redis error entries in MISP application logs (setupRedis() failures, connection refused, timeout) without corresponding auth-failure records.

Detection Strategies

• Correlate Redis availability metrics with MISP authentication-failure log volume to identify logging gaps.
• Enable web server access logging on MISP endpoints such as /users/login and API authentication routes as an independent audit source.
• Deploy reverse-proxy or WAF logging in front of MISP to capture authentication attempts outside the application logging path.

Monitoring Recommendations

• Alert on any prolonged Redis outage affecting the MISP instance and treat the outage window as reduced-visibility time.
• Track HTTP 401/403 response rates at the reverse proxy and alert on volumetric anomalies that lack matching application-layer records.
• Monitor for User->setupRedis() failure messages in MISP application logs.

How to Mitigate CVE-2026-92002

Immediate Actions Required

• Upgrade MISP to a version above 2.5.45 that includes commit a39b25d2f.
• Ensure Redis is deployed in a highly available configuration to minimize outages that would previously have suppressed logging.
• Enable independent authentication logging at the web server or reverse proxy layer as defense in depth.
• Review historical authentication logs alongside Redis uptime data to identify past periods of silent authentication activity.

Patch Information

The upstream fix is available in the MISP repository at MISP commit a39b25d2f. The patch removes the Redis-conditional block in app/Controller/AppController.php so that authentication-failure log writes execute even when setupRedis() returns false. Administrators should apply the patched release rather than backporting manually.

Workarounds

• Front MISP with a reverse proxy such as nginx or HAProxy and enable verbose access logging for authentication endpoints.
• Configure Redis with persistent connectivity, replication, or Sentinel to reduce the probability of an outage window.
• Forward web server logs to a centralized log platform so authentication activity remains visible independent of MISP application logging.

# nginx snippet: log all POST attempts to MISP authentication endpoints
location ~ ^/(users/login|users/login/.*|api/.*)$ {
    access_log /var/log/nginx/misp_auth.log combined;
    proxy_pass http://misp_backend;
}