MISP: Nested Model Alias Key Bypasses Sanitization to Modify Cross-Tenant Rows

Summary

MISP contains an improper input validation vulnerability in its ORM save path. When a user submits data through various endpoints (attribute add/edit, event edit, free-text import, sighting capture, shadow attribute proposal, event report creation, object reference add, user admin edit), the application sanitizes the flat record by stripping the primary key and pinning the event_id or object_id to the caller's context. However, the underlying ORM's set() method gives priority to a nested key whose name matches the model alias and discards the outer scalar fields. An authenticated user with basic write permissions can exploit this by embedding a nested block under the model alias key inside their request. The sanitization logic (id removal, event_id pinning) is applied to the outer record, but the ORM binds to the inner record instead, which carries an attacker-chosen id and event_id. This allows the attacker to overwrite, re-parent, or soft-delete rows belonging to other organizations or events they have no read access to. Impact: • Cross-tenant data integrity compromise (attribute values rewritten, objects re-parented to attacker events, rows soft-deleted) • Affects multiple entity types: Attribute, Object, EventReport, Sighting, AttributeTag, ShadowAttribute • Requires only a low-privilege authenticated account with perm_add Affected versions: <2.5.48

Timeline

1. Sep 30, 2026, 9:56 AM UTCCVE published
2. Sep 30, 2026, 5:08 PM UTCCISA SSVC assessment

   Exploitation: none · Automatable: no · Technical impact: partial

3. Sep 30, 2026, 5:08 PM UTCRecord last updated

Affected versions

• MISP MISP

  fixed in 2.5.48

References 1