MISP CVE-2026-9136

Requires an authenticated MISP account (PR:L) with the role permission to submit ShadowAttribute proposals - typically any contributor in a sharing community, not just administrators - against MISP instance versions 2.5.0 through 2.5.37 reachable over the network on the standard web/API interface. The attacker must know or be able to enumerate a valid existing ShadowAttribute id (sequential integer primary key, often discoverable via the API or REST event exports). What limits exploitation: the bug is confined to the ShadowAttribute add workflow (other models are not implicated), no anonymous access is possible, and the attacker can only overwrite ShadowAttribute records - not core Attributes or Events directly - though impact still spans event contexts the attacker should not control.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) indicates network-reachable, low-complexity, no-user-interaction exploitation requiring only low-privileged authentication - realistic for any MISP instance with a community of contributors who can submit proposals. Impact is asymmetric: VI:H and SI:H (high integrity impact to vulnerable and subsequent systems) with no confidentiality or availability impact, matching the described outcome of unauthorized record overwrites that can propagate across federated MISP communities. There is no EPSS score, KEV listing, or public PoC available, which is consistent with an authenticated, application-specific issue in a niche product rather than a mass-exploited internet bug - but the 8.3 score and trust-model implications make this a real priority for any organization running MISP as a shared intelligence hub, since a single compromised contributor account can silently corrupt cross-event proposal data. The description's hint that data may 'move across event contexts' suggests potential confidentiality side effects not fully captured by VC:N - defenders should not over-rely on the integrity-only framing.

An authenticated MISP user with permission to submit shadow attribute proposals enumerates or guesses the integer id of an existing ShadowAttribute belonging to another event they cannot edit. They submit a normal-looking proposal-creation POST to the add endpoint for their own event but inject the target id into the ShadowAttribute payload, causing the framework to silently UPDATE the foreign record with attacker-chosen content (e.g., neutralizing a malware IOC by overwriting its value, type, or comment), thereby corrupting shared threat intelligence without triggering a creation event. No public exploit identified at time of analysis.