CVE-2026-91846 in MISP
Summary
by MITRE • 09/15/2026
Affected versions of MISP allow a collection element to be created from a bare UUID without consistently checking whether the acting user is allowed to access the referenced object.
The commit explains that collection elements themselves only store UUIDs, while the collection view later resolves those UUIDs into their underlying objects. Before this fix, the generic add() path could therefore persist a UUID for an Event or Galaxy Cluster that the caller could not normally read. The patch explicitly notes that this made collections a way to reference another organisation’s private data and had caused disclosure of organisation-only events in the beta collection view.
The fix centralizes authorization in __assertCanUseElements(). Event UUIDs are validated through Event::fetchSimpleEvent() under the current user’s ACL, while Galaxy Cluster UUIDs are checked through GalaxyCluster::fetchGalaxyClusters(). The check is applied both to the CRUD add() path and to addElementToCollection().
Version affected: ≤2.5.45
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in versions of MISP up to 2.5.45 represents a critical authorization bypass within the collection management subsystem, specifically affecting how users can associate elements with collections via universally unique identifiers. In this architecture, collection elements function as pointers that store only UUIDs rather than full object data, deferring the resolution of these references into actual objects until the collection is viewed or processed by an administrator or user interface component. This design choice creates a temporal gap between the act of adding an element and the verification of access rights to the underlying resource. Prior to the remediation patch, the generic add path for collections failed to perform consistent authorization checks against the current user's Access Control List when persisting these UUIDs. Consequently, any authenticated user could submit a request containing the UUID of an Event or Galaxy Cluster that was restricted by organization-level permissions, effectively bypassing the intended isolation mechanisms designed to prevent cross-organization data leakage.
The operational impact of this flaw is severe, as it allows attackers with valid credentials in one organization to reference and potentially expose private events belonging to other organizations within MISP instances where multiple tenants are hosted. Although the collection element itself only stores a UUID, the subsequent resolution phase in the beta collection view exposes the underlying object details if the viewing user has permissions for the collection but not necessarily for the referenced event. This discrepancy creates an information disclosure vector where sensitive threat intelligence data, which should remain confined to specific organizations due to strict ACL rules, becomes accessible through indirect references managed by collections. The vulnerability essentially transforms a feature intended for organizing and sharing internal indicators into a mechanism for unauthorized cross-tenant data exfiltration, undermining the fundamental multi-tenancy security model of the platform.
From a technical perspective, this issue is classified under CWE-269, which denotes Improper Privilege Control, as it involves an actor obtaining privileges or accessing resources they are not authorized to reach through normal channels. Furthermore, the exploitation technique aligns with ATT&CK T1530, Data from Information Repositories, where adversaries access data stored in distributed repositories like MISP collections without direct permission to those specific items. The root cause lies in the decentralized nature of authorization checks during the creation phase; while read operations were properly secured, write operations allowing the association of external UUIDs lacked equivalent validation logic. This inconsistency allowed malicious actors to exploit the trust placed in the collection management API endpoints by submitting crafted requests that included restricted identifiers, thereby creating a persistent link to sensitive data without immediate detection at the point of entry.
The remediation strategy implemented in version 2.5.46 and later addresses this flaw by centralizing authorization logic within the __assertCanUseElements method. This function now enforces strict validation before any element is added to a collection, ensuring that the acting user possesses explicit read access to both Event UUIDs via Event::fetchSimpleEvent() and Galaxy Cluster UUIDs via GalaxyCluster::fetchGalaxyClusters(). By applying these checks uniformly across all code paths involved in adding elements, including the standard CRUD add operation and the specific addElementToCollection function, the system ensures that no unauthorized references can be persisted. This approach eliminates the possibility of creating indirect access channels to restricted data through collection associations. Administrators operating affected versions must upgrade immediately to mitigate the risk of internal data leakage and ensure compliance with security best practices for multi-tenant threat intelligence sharing platforms.