CVE-2026-91846: MISP Collection Element Add Missing Authorization on Referenced Object UUID
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
Affected Software
Event History
Frequently Asked Questions
Which data types could be exposed through a collection?
Event UUIDs and Galaxy Cluster UUIDs could be added and later resolved by the collection view. The issue was specifically reported as disclosing organisation-only events from another organisation in the beta collection view.
Which MISP versions are affected?
MISP versions 2.5.45 and earlier are affected.
Do both supported collection-element addition paths receive the authorization fix?
Yes. The fix applies authorization checks to both the generic CRUD add() path and addElementToCollection(). Event access is checked under the current user's ACL, and Galaxy Cluster access is checked through the Galaxy Cluster retrieval path.