CVE-2026-103237 in MISP
Summary
by MITRE • 09/30/2026
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
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified in the MISP platform represents a critical failure in input validation and object-relational mapping logic within its data persistence layer. This flaw, classified under CWE-913 for improper control of dynamically determined model identifiers, allows an authenticated user with basic write permissions to manipulate database records outside their authorized scope. The core issue stems from how the application handles incoming JSON payloads through various endpoints such as attribute management, event editing, and sighting capture. While the application attempts to sanitize input by stripping primary keys and enforcing context-specific foreign keys like event_id or object_id on the outer record level, it fails to account for nested structures within that payload. Specifically, when a request contains a nested block keyed with the model alias, the underlying ORM's set method prioritizes this inner structure over the sanitized outer fields. This architectural oversight creates a bypass mechanism where the security controls applied to the top-level data are effectively ignored because the database operations target the unsanitized nested object instead.
From an operational perspective, this vulnerability enables significant cross-tenant data integrity compromises. An attacker can exploit this logic error to overwrite attribute values, re-parent objects to events they do not own, or soft-delete rows belonging to other organizations within the same MISP instance. The impact is severe because it affects multiple entity types including Attributes, Objects, EventReports, Sightings, AttributeTags, and ShadowAttributes. This means that an attacker with only low-privilege access can degrade the quality of threat intelligence shared across the platform or destroy critical data associated with other users' investigations. Such actions undermine the trust model inherent in multi-tenant environments where isolation between organizations is paramount for security and compliance purposes. The ability to soft-delete records also poses a risk of denial of service against specific datasets without leaving obvious traces, complicating forensic analysis and recovery efforts.
The technical execution relies on the disparity between application-level sanitization and ORM behavior. When data enters through endpoints like free-text import or shadow attribute proposal, the server-side logic removes explicit identifiers from the main payload to prevent direct ID manipulation. However, by embedding a nested dictionary under the model alias key, the attacker provides an alternative source of truth for the ORM. Since the ORM binds to this inner record which was not subjected to the same sanitization routines as the outer wrapper, it accepts maliciously crafted IDs and foreign keys. This effectively neutralizes the intended security controls that rely on context pinning. The vulnerability is present in versions prior to 2.5.48, indicating a long-standing issue in how complex nested payloads are processed during object creation or update operations.
Mitigation strategies must focus on strengthening input validation at both the application and ORM layers. Developers should ensure that all nested structures within incoming requests undergo the same rigorous sanitization processes as top-level fields. This includes validating and stripping any identifiers present in nested objects before they reach the persistence layer. Additionally, implementing strict schema validation using tools like JSON Schema can help reject payloads containing unexpected or unauthorized nested keys. Enforcing least-privilege principles at the database level through row-level security policies could also limit the damage if such an exploit occurs by restricting which rows a user can modify based on their organization ID regardless of what is submitted in the request body. Upgrading to version 2.5.48 or later resolves this issue as it addresses these validation gaps. Security teams should audit existing configurations for similar patterns in other parts of the application and consider implementing comprehensive logging to detect anomalous write operations that might indicate exploitation attempts aligned with ATT&CK techniques related to data manipulation and lateral movement within threat intelligence platforms.