MISP CVE-2026-103235

Two concrete preconditions must both hold: (1) the attacker is an authenticated user whose role carries the delegation permission (perm_delegate), and (2) the instance-wide MISP.delegation server setting is enabled, which is not the default. Given both, exploitation is a single crafted POST to the delegateEvent endpoint containing an extra 'id' (primary key) or 'event_id' field in the EventDelegation payload; the controller authorizes only the event named in the URL but saves the full submitted record, so the injected key retargets an existing delegation to an arbitrary event. Limiting factors: valid credentials with the delegation permission (PR:L), dependence on the non-default delegation feature being enabled, and full ownership transfer additionally requiring the target organisation to accept the delegation. No victim user interaction is needed for the read-access disclosure.

This is a genuine, high-priority authenticated authorization flaw rather than a CVSS-inflated non-issue. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L, score 8.7) is well-supported by the description and by the source-code patch: a low-privileged authenticated user reaches broad confidentiality and integrity impact with no user interaction and low attack complexity. No EPSS score, no CISA KEV listing, and no public POC are provided, so exploitation is currently theoretical (no public exploit identified at time of analysis) - the risk is driven by ease of exploitation and impact severity, not by evidence of active exploitation. The commit diff independently confirms the root cause (create()+save() with a caller-supplied primary key/event_id, fixed via an allow-list), raising confidence well above a description-only report. The two real limiters are that the attacker must already hold the perm_delegate permission and that the non-default MISP.delegation server setting must be enabled; where both hold, this is a real priority for MISP operators running multi-organisation sharing.

An authenticated user in one organisation who holds the delegation permission submits a delegation request for an event they legitimately access, but injects an 'id' (primary key) or 'event_id' field into the payload. The application authorizes only the event named in the URL, then persists the entire submitted record, retargeting an existing delegation row at any event on the instance and granting the attacker's org read access to other organisations' events. No public exploit is identified, but the mass-assignment technique is trivial to reproduce with a standard HTTP client such as PyMISP.