MISP CVE-2026-103237

Requires an authenticated MISP account holding basic write permission (perm_add) on the target instance; the attacker then embeds a nested record under the model-alias key (e.g. 'Attribute', 'Object', 'EventReport', 'ShadowAttribute') inside a submission to any affected endpoint (attribute add/edit, event edit, free-text import, sighting capture, shadow-attribute proposal, event-report creation, object-reference add, or user admin edit). Exploitation is limited to instances running MISP <2.5.48 and to attackers who already possess a write-capable account - a meaningful constraint on public/community instances but weak protection where many semi-trusted members share one server. No special non-default configuration or user interaction is needed beyond having the perm_add privilege.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N, base 8.3) is credible and internally consistent: exploitation is fully remote, low-complexity, needs only a low-privilege authenticated account (PR:L, the perm_add write role), no user interaction, and the impact is purely integrity - both to the vulnerable system (VI:H) and, notably, to other tenants/orgs (SI:H) with no confidentiality or availability effect. This is a genuine authorization-bypass (IDOR, CWE-639) rather than a raw memory/RCE class bug, so the danger is silent cross-tenant data tampering, not takeover. No EPSS score, no CISA KEV entry, and no public POC are provided, so this is 'no public exploit identified at time of analysis' - the score is driven by impact and ease, not by observed exploitation. The one caveat: PR:L means the attacker must already hold a valid write-capable account on the MISP instance, which for a threat-intelligence sharing platform often means a semi-trusted member of a sharing community rather than an anonymous internet attacker; that materially lowers real-world exposure versus an unauthenticated flaw. A vendor patch (MISP commit 9485ae40d, fixed in 2.5.48) is confirmed and the root cause is clearly documented in the diff, so this is a real, patch-now integrity issue for multi-tenant/community MISP deployments, but not an unauthenticated-RCE-grade emergency.

A low-privilege user holding perm_add on a shared MISP instance submits an attribute-add (or event-edit, sighting, shadow-attribute, object-reference, etc.) request in which they embed a nested block keyed by the model alias (e.g. 'Attribute') carrying an attacker-chosen id and event_id. MISP sanitizes the flat outer record (stripping id, pinning event_id) but the CakePHP ORM's set() binds to the inner nested record instead, so the write lands on a row belonging to another organization or event the attacker cannot read - letting them overwrite, re-parent, or soft-delete it. No public POC is identified, but the mechanism is fully described in the patch commit.