CVE-2026-92003: MISP Authentication Bypass Vulnerability

CVE-2026-92003 Overview

CVE-2026-92003 affects MISP (Malware Information Sharing Platform) versions ≤2.5.45. The vulnerability stems from inconsistent application of the existing authentication-failure logging throttle. Two API authentication failure branches write directly to the Log model without invoking _shouldLog(), allowing each request to create a durable auth_fail entry. Attackers can abuse this behavior to exhaust log storage and back-end Redis resources through repeated unauthenticated API requests. The issue maps to [CWE-400] Uncontrolled Resource Consumption.

Critical Impact
Unauthenticated attackers can generate unbounded log entries by sending API requests with no key or with a malformed key, degrading availability of the MISP instance.

Affected Products

MISP versions ≤2.5.45
MISP API authentication paths in AppController.php
Deployments relying on Redis-backed logging throttles

Discovery Timeline

2026-09-15 - CVE-2026-92003 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92003

Vulnerability Analysis

MISP implements a logging throttle via _shouldLog() to prevent authentication-failure events from flooding persistent storage. Most API authentication failure branches consult this throttle before writing to the Log model. Two specific branches bypass this control entirely.

The first branch fires when an API request presents no authentication key. The second branch fires when the supplied API key has an incorrect length. In both cases, the controller directly calls Log->createLogEntry() without checking whether the source has recently generated an equivalent entry.

Because the throttle is skipped, every unauthenticated request results in a durable auth_fail row. A remote attacker can drive log volume upward without limit, consuming disk space, database rows, and Redis capacity used by throttle bookkeeping. The impact is availability-focused rather than confidentiality- or integrity-oriented.

Root Cause

The root cause is a missing guard in app/Controller/AppController.php. The two failure branches were added or refactored without the surrounding _shouldLog() check that governs sibling branches. This is a classic case of inconsistent application of a defensive control.

Attack Vector

Exploitation requires no authentication and no user interaction. An attacker sends repeated HTTP requests to any MISP API endpoint, either omitting the Authorization header or supplying a key of invalid length. Each request commits an auth_fail log entry, amplifying storage consumption on the target.

php

                        throw new ForbiddenException('Authentication failed.');
                    }

-                    if ($loginByAuthKeyResult === null) {
+                    // Throttled like its siblings, and keyed on the source
+                    // address rather than on anything the caller supplied: this
+                    // branch is reached precisely because no key was presented,
+                    // and a key derived from attacker input would let a caller
+                    // mint an unbounded number of Redis entries.
+                    if ($loginByAuthKeyResult === null && $this->_shouldLog('noauthkey:' . $this->User->_remoteIp())) {
                        $this->loadModel('Log');
                        $this->Log->createLogEntry('SYSTEM', 'auth_fail', 'User', 0, "Failed API authentication. No authkey was provided.");
                    }

Source: GitHub MISP Commit 2bf887433. The patch keys the throttle on the remote IP rather than caller-supplied input, preventing attackers from minting unbounded Redis entries.

Detection Methods for CVE-2026-92003

Indicators of Compromise

High-frequency auth_fail entries in the MISP Log table with the message Failed API authentication. No authkey was provided.
Repeated auth_fail entries referencing malformed or incorrect-length API keys from the same source IP
Abnormal growth of the MISP database logs table or backing Redis instance

Detection Strategies

Query the MISP logs table for action = 'auth_fail' grouped by source IP over short time windows to identify volumetric abuse.
Alert on sustained rates of unauthenticated API requests reaching /users/* or other MISP API endpoints from a single origin.
Baseline typical auth_fail volume per hour and generate alerts when volume exceeds normal thresholds.

Monitoring Recommendations

Monitor disk utilization on the MISP database host and Redis memory usage for unexpected growth.
Forward MISP application logs to a centralized log platform to correlate authentication failures with upstream network sources.
Track HTTP 401/403 response rates on the MISP reverse proxy or web server to identify unauthenticated request storms.

How to Mitigate CVE-2026-92003

Immediate Actions Required

Upgrade MISP to a version above 2.5.45 that includes commit 2bf887433.
Restrict MISP API exposure to trusted networks or VPN reachable clients where feasible.
Enforce web-tier rate limiting on API endpoints to cap unauthenticated request volume.

Patch Information

The fix is committed upstream in GitHub MISP Commit 2bf887433. The patch wraps the two previously unguarded auth_fail write paths with _shouldLog() calls keyed on the remote IP address. This ensures both branches respect the same throttle semantics as sibling authentication-failure paths.

Workarounds

Place a reverse proxy such as NGINX or HAProxy in front of MISP and apply per-IP rate limits to API paths.
Configure fail2ban or an equivalent tool to block IPs generating excessive authentication failures against MISP.
Periodically prune the MISP logs table and monitor Redis key counts until the patch is applied.

bash

# Example NGINX rate limit for MISP API endpoints
http {
    limit_req_zone $binary_remote_addr zone=misp_api:10m rate=10r/s;

    server {
        location /users/ {
            limit_req zone=misp_api burst=20 nodelay;
            proxy_pass http://misp_backend;
        }
    }
}