CVE-2026-88915 in MISP
Summary
by MITRE • 09/10/2026
Affected versions of MISP do not consistently enforce the acting user's authorization when instantiating event templates.
For templates using distribution = 4, the template can specify a sharing_group_id. The instantiation path passed that value into event creation without verifying that the user instantiating the template was actually permitted to use the selected sharing group. The commit notes that Event::_add() only performed its own sharing-group authorization in another code path, leaving template instantiation able to write the identifier directly.
The same instantiation path also attached template-specified tags without checking the user's normal tagging permissions. In addition, it hardcoded local => 0, meaning tags marked local_only could be attached globally and consequently propagate through synchronization or export, contrary to their intended restriction.
The fix adds explicit SharingGroup::canUse() authorization for the acting user, applies the same tag-modification checks used by normal event tagging, and ensures local_only tags are attached locally.
Version affected: ≤2.5.45
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/10/2026
A critical access control vulnerability exists in versions of MISP up to 2.5.45 regarding the instantiation of event templates. The flaw stems from an inconsistency in how authorization is enforced when a user creates an event based on a template, specifically bypassing standard checks for sharing groups and tag permissions. This issue allows authenticated users to potentially escalate their privileges or violate data handling policies by leveraging pre-configured settings within a template that they would not normally be authorized to apply directly through the standard interface. The vulnerability highlights a failure in implementing proper object-level access controls during specific code paths, leading to unauthorized state changes and potential information disclosure depending on the sensitivity of the sharing groups involved.
The technical root cause lies in the event instantiation logic where templates with distribution set to four are processed. In this scenario, the template specifies a sharing_group_id which is passed directly into the event creation process without verifying that the acting user has permission to use that specific sharing group. While other code paths within Event::_add perform rigorous sharing-group authorization checks, the template instantiation path bypassed these safeguards by writing the identifier directly. This discrepancy means that if an attacker or a compromised account possesses access to a template configured with a high-restriction sharing group they are not part of, they can instantiate events under those restrictive groups effectively impersonating higher-privileged users or violating data sovereignty rules defined by those groups.
Furthermore, the vulnerability extends beyond sharing groups to include tag management and local scope enforcement. The same instantiation path attaches tags specified in the template without applying the standard checks that govern normal event tagging permissions. This allows a user to apply tags they are not authorized to use directly. Additionally, the code hardcoded the local flag to zero during this process. Consequently, tags marked as local_only within the template were attached globally rather than locally. Since local-only tags are intended for internal use and should never propagate through synchronization or export mechanisms, their global attachment violates data handling policies and can lead to unintended information leakage when events are shared with external partners or synchronized across instances.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management as it involves bypassing authorization checks for specific resources. It also relates to CWE-862 Missing Authorization where the system fails to verify user permissions before allowing actions on protected objects like sharing groups and tags. In terms of attack vectors, this falls under ATT&CK T1078 Valid Accounts if exploited by a legitimate but unauthorized user, or potentially T1548 Abuse Elevation Control Mechanism if used to bypass access controls for higher-level data handling privileges. The lack of consistent enforcement across different code paths represents a significant architectural flaw in the application's security model.
The operational impact of this vulnerability is severe depending on the environment configuration and the sensitivity of the sharing groups involved. Unauthorized users could create events that appear to belong to restricted sharing groups, potentially misleading other analysts about the provenance or classification level of the threat intelligence data. The propagation of local-only tags globally can result in sensitive metadata being shared with external entities who are not authorized to see it, violating compliance requirements and trust agreements between MISP instances. This undermines the integrity of the distributed threat intelligence network by allowing unauthorized modifications to event attributes that should be strictly controlled.
To mitigate this risk, organizations running affected versions must upgrade immediately to version 2.5.46 or later where explicit SharingGroup::canUse authorization checks have been implemented for template instantiation. The fix ensures that users are verified against the selected sharing group before an event is created using a template. Additionally, the patch applies standard tag-modification checks and correctly handles local_only flags by ensuring they remain local during creation. Until upgrading is possible, administrators should audit templates to ensure none contain references to high-restriction sharing groups or sensitive tags that could be exploited via this vector. Regular reviews of user permissions against template configurations can also help identify potential abuse scenarios where a user has access to a dangerous template but lacks the underlying privileges for its components.