VYPR
← All advisories
Medium severityNVD Advisory· Published Jun 12, 2026

CVE-2026-54396

CVE-2026-54396

Description

MISP AuthKey edit uses attacker-controlled user_id on validation failure, letting authenticated users enumerate email addresses via the returned dropdown.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

MISP AuthKey edit uses attacker-controlled user_id on validation failure, letting authenticated users enumerate email addresses via the returned dropdown.

Vulnerability

An information disclosure vulnerability (CVE-2026-54396) exists in the MISP AuthKey edit action. When a validation error occurs during an AuthKey edit request, the user_id value used to populate the user dropdown is derived from the request body ($this->request->data['AuthKey']['user_id']) rather than the persisted AuthKey owner. This affects versions prior to the commit 42737f4e88. An authenticated user with permission to edit an AuthKey can submit an arbitrary user_id in the POST data and observe the returned user email in the dropdown, enabling enumeration of user email addresses.

Exploitation

An attacker must be an authenticated MISP user who holds the permission to edit an AuthKey. The attacker submits an edit request with a crafted user_id value for an AuthKey that they are authorised to edit. The request attempts a validation (e.g., invalid data format) so the server does not save the changes but still rebuilds the user dropdown using the attacker-supplied user_id. The response includes a list of users filtered by that user_id, revealing the email address of the targeted user.

Impact

Successful exploitation results in the disclosure of user email addresses for any user ID the attacker chooses to probe. This is a confidentiality compromise of user PII and could be used to map usernames to emails or to profile the user base. The attacker does not gain write access or elevated privileges within MISP.

Mitigation

The fix is contained in commit 42737f4e88 ([1]), which changed the dropdown query to derive the user_id from the actual AuthKey owner (AuthKey.user_id) stored in the database, rather than from the request data. The fix was introduced on an undisclosed date. Users should update to a version that includes this commit or apply the patch manually. No workaround is documented. The vulnerability is not listed on CISA KEV as of the publication date.

References
  1. fix: [security] Authkey edit allows enumerating user emails · MISP/MISP@42737f4

AI Insight generated on Jun 12, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Misp/Mispreferences2 versions
    (expand)+ 1 more
    • (no CPE)
    • (no CPE)

Patches

1
42737f4e88df

fix: [security] Authkey edit allows enumerating user emails

https://github.com/MISP/MISPiglocskaJun 11, 2026via nvd-ref
commit
1 file changed · +10 −1
  • app/Controller/AuthKeysController.php+10 −1 modified
    @@ -95,10 +95,19 @@ public function edit($id)
         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', [

Vulnerability mechanics

Root cause

"The user dropdown in the AuthKey edit action was populated using attacker-controlled request data instead of the persisted AuthKey owner."

Attack vector

An authenticated attacker with permission to edit an AuthKey can send a crafted POST request containing an arbitrary `AuthKey.user_id` value in the request body. When the edit request fails validation, the controller populates the user dropdown using this attacker-supplied ID instead of the persisted owner. The attacker can then observe the returned dropdown data, which includes email addresses of the targeted user, enabling user enumeration. [CWE-200]

Affected code

The vulnerability resides in `app/Controller/AuthKeysController.php` within the `edit` action. Prior to the patch, the user dropdown data was built using `$this->request->data['AuthKey']['user_id']`, which is attacker-controlled input. The patch corrects this by querying the actual `AuthKey.user_id` from the database for the given `$id`.

What the fix does

The patch replaces the attacker-controlled `$this->request->data['AuthKey']['user_id']` with `$ownerUserId`, which is fetched from the database using the authenticated key's ID via `AuthKey.find('column', ...)`. This ensures the dropdown always shows the actual owner of the AuthKey rather than reflecting submitted input. The commit comment notes that access to this owner is already authorized by the `canEditAuthKey()` check at the top of the action.

Preconditions

  • authThe attacker must have an authenticated session with permission to edit an AuthKey.
  • inputThe attacker must submit a POST request to the edit endpoint with a crafted `AuthKey.user_id` value in the request body.

Generated on Jun 12, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

1

News mentions

0

No linked articles in our index yet.