CVE-2026-54396: MISP Information Disclosure Vulnerability

CVE-2026-54396 Overview

CVE-2026-54396 is an information disclosure vulnerability in the Malware Information Sharing Platform (MISP) AuthKey edit functionality. When a validation error occurs during an AuthKey edit request, the user dropdown is populated using the attacker-controlled AuthKey.user_id value taken directly from submitted request data. An authenticated user with permission to edit an AuthKey can submit arbitrary user IDs and observe the returned dropdown, enabling enumeration of user email addresses. The flaw is tracked under [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor].

Critical Impact
Authenticated MISP users with AuthKey edit permissions can enumerate email addresses of arbitrary platform users by manipulating the user_id field in failed-validation edit requests.

Affected Products

MISP (Malware Information Sharing Platform) instances containing the vulnerable AuthKeysController.php logic
MISP deployments prior to commit 42737f4e88df801486334690913dd344e447fac3
Any MISP environment exposing AuthKey edit functionality to authenticated users

Discovery Timeline

2026-06-12 - CVE-2026-54396 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-54396

Vulnerability Analysis

The vulnerability resides in the MISP AuthKeysController edit action, implemented in app/Controller/AuthKeysController.php. When a user submits an AuthKey edit request that fails server-side validation, the controller re-renders the edit form. To repopulate the user dropdown, the controller queries the User model using the AuthKey.user_id field taken from $this->request->data.

Because this value is fully attacker-controlled, an authenticated user can substitute any numeric user ID. The resulting dropdown reveals the username (typically an email address) associated with that ID. Repeated requests iterating through ID values allow systematic enumeration of MISP user accounts.

Root Cause

The root cause is improper trust in client-supplied input when rebuilding view state after a validation failure. The controller relies on $this->request->data['AuthKey']['user_id'] rather than the persisted AuthKey record. The authorization check canEditAuthKey() validates access to the AuthKey itself, but does not constrain which user IDs may be referenced when reconstructing the dropdown.

Attack Vector

An authenticated attacker with AuthKey edit privileges sends a crafted POST request to the AuthKey edit endpoint. The request includes an invalid field combination that triggers a validation error, alongside an AuthKey.user_id value pointing to any target user. The response contains the dropdown data exposing the target user's email. Iterating the user_id parameter enumerates the entire user base.

php

         if ($this->IndexFilter->isRest()) {
             return $this->restResponsePayload;
         }
+        // Build the user dropdown from the authkey's actual owner, not from request->data:
+        // on a failed validation POST the latter reflects attacker-supplied input, which would
+        // let a user enumerate arbitrary user emails. Access to this owner is already authorised
+        // by the canEditAuthKey() check at the top of this action.
+        $ownerUserId = $this->AuthKey->find('column', [
+            'fields' => ['AuthKey.user_id'],
+            'conditions' => ['AuthKey.id' => $id],
+        ]);
+        $ownerUserId = $ownerUserId[0] ?? null;
         $this->set('dropdownData', [
             'user' => $this->User->find('list', [
                 'sort' => ['username' => 'asc'],
-                'conditions' => ['id' => $this->request->data['AuthKey']['user_id']],
+                'conditions' => ['id' => $ownerUserId],
             ])
         ]);
         $this->set('menuData', [

Source: MISP security commit 42737f4e. The patch replaces the request-supplied user_id with the persisted AuthKey owner queried directly from the database.

Detection Methods for CVE-2026-54396

Indicators of Compromise

Repeated POST requests to MISP AuthKey edit endpoints from the same authenticated session within a short interval
Edit requests containing varying AuthKey[user_id] parameter values that do not match the requester's own user ID
High volumes of validation-failure responses from the AuthKey edit action
AuthKey edit requests from accounts that rarely or never modify their own keys

Detection Strategies

Parse MISP application and web server logs for sequential or incrementing user_id values submitted to the AuthKey edit endpoint
Alert when a single authenticated user triggers multiple failed AuthKey validations across distinct user_id values
Correlate AuthKey edit activity with downstream phishing or credential-stuffing attempts against enumerated email addresses

Monitoring Recommendations

Enable verbose audit logging for the AuthKeysController actions and retain logs for forensic review
Forward MISP application logs to a centralized SIEM or data lake for correlation across user sessions
Baseline normal AuthKey edit volume per user and alert on statistical deviations

How to Mitigate CVE-2026-54396

Immediate Actions Required

Apply the upstream MISP patch from commit 42737f4e88df801486334690913dd344e447fac3 to all production instances
Audit which roles currently hold AuthKey edit permissions and remove unnecessary grants
Review recent web server and application logs for evidence of user_id enumeration against the AuthKey edit endpoint
Rotate any user email addresses or accounts suspected of exposure if abuse is confirmed

Patch Information

The maintainers fixed the issue by deriving the dropdown user from the persisted AuthKey owner via a direct database lookup, rather than from the request body. The change is published in MISP commit 42737f4e88df801486334690913dd344e447fac3. Operators should pull the corresponding MISP release containing this commit and redeploy.

Workarounds

Restrict AuthKey edit permissions to a minimal set of trusted administrators until the patch is deployed
Place the MISP web interface behind an authenticated reverse proxy that rate-limits POST requests to AuthKey endpoints
Apply a temporary web application firewall rule to block requests where AuthKey[user_id] does not match the session user's ID

bash

# Apply the upstream fix to an existing MISP deployment
cd /var/www/MISP
sudo -u www-data git fetch origin
sudo -u www-data git cherry-pick 42737f4e88df801486334690913dd344e447fac3
sudo systemctl reload apache2