MISP EUVD-2026-36603

The attacker must be authenticated to the MISP instance and must possess object editing permissions - either granted directly or via a role that includes object add/edit rights. No elevated administrative privileges are required; a standard analyst-level account with editing rights is sufficient. Exploitation requires sending an HTTP request to the object add or edit endpoint with distribution set to 4 and an arbitrary sharing_group_id value. The target MISP instance must have at least one sharing group configured that the attacker cannot legitimately access; otherwise the information disclosure impact is null. Exploitation is limited to users with pre-existing authenticated sessions and editor-level permissions - unauthenticated attackers and read-only users cannot exploit this flaw. The vulnerability does not require any non-default configuration beyond the presence of sharing groups, which is a standard MISP feature in multi-organization deployments.

The CVSS 4.0 base score of 5.3 (Medium) is consistent with the limited blast radius: exploitation requires an authenticated session (PR:L) with pre-existing object editing permissions, and the confidentiality and integrity impacts are both Low (VC:L/VI:L). The attack complexity is Low and no specific attack preconditions (AT:N) are required beyond authentication. Concretely, the worst-case outcome is information disclosure of sharing group names or identifiers that should be invisible to the user, and unauthorized tagging of distribution metadata - neither of which constitutes direct data exfiltration or code execution. There is no availability impact (VA:N). No EPSS score is available in the provided data, so exploitation probability cannot be quantified numerically. The absence of a KEV listing and no known public exploit code further reduces immediate urgency. The primary real-world concern is in high-sensitivity MISP deployments where sharing groups partition intelligence visibility between trusted communities; an insider with limited editor access could map the sharing group topology, undermining the confidentiality model of the platform. This vulnerability is a genuine priority for organizations relying on MISP sharing group boundaries as a security control, but is lower priority for single-organization deployments where sharing groups are not used as access controls.

An authenticated MISP user who holds object editing permissions but lacks access to a restricted sharing group crafts an HTTP POST request to the MISP object edit endpoint, setting distribution=4 and supplying an arbitrary sharing_group_id value in the request body. Because the field merge in ObjectsController.php causes the validation check to reference a stale data key that no longer exists, the sharing group authorization check is silently skipped and the object is saved with the unauthorized sharing group assignment. The attacker can enumerate sharing group IDs by observing success or failure responses, learning the names and existence of sharing groups they should not be able to see. No public exploit code has been identified at time of analysis.