Mercredi 30 septembre 2026

MISP

MISP contains a stored cross-site script (XSS) vulnerability in the event graph preview feature. The event graph preview image field was accepted and stored without server-side validation. On the client side, the stored value was rendered into an HTML img element's src attribute via string concatenation, allowing a crafted value to break out of the attribute context and inject arbitrary script. Preconditions: - An authenticated MISP user with the ability to create or modify an event graph entry. - A second user (the victim) who views the event graph and triggers the preview popover. Impact: - Execution of arbitrary JavaScript in the victim's browser within the MISP application context. - Potential theft of session tokens, cookies, or sensitive data accessible to the victim's browser. - Potential for performing actions on behalf of the victim within the MISP application. Affected: MISP versions prior to the fix (commit applied after v2.5.48).

MISP

MISP contains a privilege escalation vulnerability in the tag collection creation and editing functionality. The affected actions accepted the full HTTP request payload and passed it to a bulk-association save operation, which writes not only the intended tag collection record but also any associated model data present in the payload. A user holding the tag editor permission could craft a request that includes additional model data (such as User or Organisation records) alongside the tag collection fields. Because the save operation processed all associated models indiscriminately, the injected sibling records were written to the database, enabling the attacker to modify or create privileged accounts and escalate to site administrator. Preconditions: - An authenticated account with the tag editor permission (perm_tag_editor) - Network access to the MISP instance Impact: - Unauthorized creation or modification of User and Organisation records - Privilege escalation from tag editor to site administrator Affected versions: < 2.5.48

MISP

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

MISP

MISP contains a mass assignment vulnerability in the event delegation feature. When a user with delegation permission submits a delegation request, the application authorized the user against the event identified in the URL but then persisted the entire submitted record, including caller-supplied fields such as the primary key and event_id. An authenticated attacker could inject a primary key or event_id into the delegation payload to retarget an existing delegation record to any event on the instance. Because a delegation row grants the requesting organisation read access to the event it references, this effectively granted read access to arbitrary events belonging to other organisations. If the target organisation subsequently accepted the delegation, ownership of the event was transferred and the original record was deleted. Preconditions: - An authenticated user with the delegation permission (perm_delegate) - The MISP.delegation server setting must be enabled Impact: - Confidentiality: read access to any event on the instance - Integrity: overwriting existing delegation records and transferring event ownership Affected versions: MISP < 2.5.48