CVE-2026-85533: MISP Sharing Group Authorization Bypass via Omitted Distribution Parameter
An authorization flaw in MISP allowed an authenticated user to submit a sharinggroupid without verifying that the user was authorized to use the referenced Sharing Group.
In several attribute and Galaxy Cluster creation and editing workflows, validation of the submitted Sharing Group was performed only when the request explicitly set the distribution field to 4 ("Sharing Group"). An attacker could therefore craft a request containing a sharinggroupid while omitting the distribution parameter, or otherwise avoiding the distribution == 4 condition, causing the Sharing Group authorization check to be skipped.
This could allow a user with permission to create or modify the affected MISP objects to associate data with a Sharing Group that they are not authorized to use. Depending on the affected object's existing distribution settings and subsequent processing, this could bypass intended information-sharing boundaries and result in unauthorized placement or distribution of data to members of another Sharing Group.
The issue affected attribute attachment and editing operations as well as Galaxy Cluster creation and editing. The fix ensures that authorization is performed whenever a non-empty sharinggroupid is submitted, independently of the distribution parameter. It also centralizes the authorization decision in SharingGroup::canUse() and explicitly rejects empty Sharing Group identifiers rather than allowing them to be interpreted as an unrestricted query.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update MISP so that Sharing Group authorization is enforced in attribute attachment/editing and Galaxy Cluster creation/editing whenever a non-empty sharing_group_id is provided, regardless of whether the request includes distribution=4; do not allow empty sharing_group_id to bypass checks.
MISP SharingGroup authorization logic (SharingGroup::canUse) = Authorization check whenever a non-empty sharing_group_id is submitted; explicitly reject empty sharing_group_id instead of treating it as unrestricted
Event History
Frequently Asked Questions
Who could exploit this issue?
An authenticated MISP user who has permission to create or modify the affected objects could exploit it. The affected workflows include attribute attachment and editing, plus Galaxy Cluster creation and editing.
What request conditions were needed to bypass the authorization check?
The attacker needed to submit a sharing_group_id while omitting the distribution parameter or otherwise avoiding a distribution value of 4. Authorization was only checked when distribution was explicitly set to 4, which represents Sharing Group distribution.
What is the potential impact of a successful exploit?
A user could associate data with a Sharing Group they were not authorized to use. Depending on the object's existing distribution settings and subsequent processing, this could place or distribute data to members of another Sharing Group, bypassing intended sharing boundaries.
How can administrators identify potentially affected activity?
Review attribute attachment and editing requests and Galaxy Cluster creation or editing requests for submitted sharing_group_id values where distribution was absent or was not set to 4. Such requests are the condition under which the Sharing Group authorization check could have been skipped.