MISP core contained multiple broken access-control flaws where authorization checks were...

1. Executive summary

MISP core (the open-source threat-intelligence sharing platform) contained multiple broken access-control vulnerabilities in which authorisation checks were performed against the wrong entity, or where ownership/editability checks were missing on write paths. A lower-privileged authenticated user holding the relevant feature permission could cause the application to authorise one object but mutate another, or modify objects that were merely visible rather than editable by the user's organisation. Five subsystems are affected: Event Reports tag removal, Collection Elements bulk deletion, Analyst Data capture/update, Template Elements editing, and Decaying Model editing and mappings. Successful exploitation enables cross-organisation modifications or deletions of MISP data, integrity loss, and tampering with shared intelligence. No CVSS score, severity rating, or CISA KEV exploitation status has been resolved for this advisory; severity is therefore not asserted. EMEA financial services firms operating MISP instances — particularly those using MISP for sectoral CTI sharing — should treat this as a priority patch item once a fixed version is confirmed.

2. Regulatory framing

3. Technical analysis & attack chain

The vulnerability class is broken access control / incorrect authorisation on write paths. In each affected subsystem, the application authorises against one entity (e.g., a route-supplied ID, or a view-scope check) but mutates a different entity, or relies on a view-scope check without verifying edit ownership.

Attack chain (confirmed)

1. Initial access — authentication. The attacker authenticates to MISP as a lower-privileged user holding the relevant feature permission for the targeted subsystem (event reports, collections, analyst data, templates, or decaying models). No public-internet exploit is described; the attacker must already hold valid MISP credentials.
2. Authorisation bypass. The attacker invokes a write path in one of the five affected subsystems. The application performs an authorisation check against an entity that is not the one being mutated (e.g., a collection whose ID matches the collection-element row ID rather than the element's actual parent collection), or omits the canEditAnalystData ownership check on nested updates.
3. Cross-organisation mutation. The attacker modifies or deletes data owned by another organisation within the same MISP instance, or removes tags from another organisation's event report.
4. Impact. Integrity loss on shared intelligence, unauthorised tampering with CTI records, and disruption of analyst workflows.

Affected subsystems (detail)

• Event Reports tag removal. The route-authorised report can differ from the report ID used for tag detachment, enabling cross-organisation tag removal from another event report.
• Collection Elements bulk deletion. Bulk deletion is authorised against a collection whose ID matches the collection-element row ID, rather than the element's actual parent collection, enabling deletion of elements from collections the user does not own.
• Analyst Data capture/update. Nested analyst-data updates can overwrite an existing record without applying the normal canEditAnalystData ownership check, enabling cross-organisation overwrite of analyst-data records.
• Template Elements editing. Editing is authorised against a template whose ID matches the template-element ID, rather than the element's actual parent template, enabling unauthorised edits to another organisation's template elements.
• Decaying Model editing and mappings. Write paths load models using view-scope access but do not verify edit ownership, enabling users to edit or remap visible models owned by another organisation.

Observed impact

• Integrity loss on MISP data (events, collections, analyst data, templates, decaying models).
• Tampering with shared intelligence across organisations sharing the same MISP instance.
• Disruption of analyst workflows that depend on the integrity of CTI records.

Caveats

• The source does not name a specific fixed version, patch commit, or upgrade target. Mitigation guidance is therefore framed as "patch when available" rather than naming a version.
• No CVSS score, severity rating, or CISA KEV exploitation status has been resolved for this advisory; severity is not asserted.
• No public exploit code, IOCs, or named threat-actor attribution are present in the source material. The related advisory GHSA-9cgp-f46x-4wgf (organisation-administrator-to-site-administrator escalation) is a separate, distinct vulnerability and is not part of this item.

4. Mitigation & containment

P1 — within 24 hours

• Inventory. Identify every MISP instance operated in-house or by a third-party provider handling the firm's CTI. Record version, hosting model (self-hosted, managed, SaaS), and the responsible team.
• Access restriction. Until a fix is applied, restrict write access to the five affected subsystems (event reports, collections, analyst data, templates, decaying models) to the minimum set of trusted users. Disable or revoke feature permissions for non-essential accounts.
• Segregation. Where feasible, isolate MISP from general user populations (e.g., place behind SSO with MFA, restrict by IP allowlist) to reduce the pool of potential in-house exploiters.
• Audit log capture. Preserve current MISP audit logs and database snapshots to support post-incident review if exploitation has already occurred.

P2 — within 72 hours

• Patch. Apply the upstream MISP fix once published. The source does not name a specific fixed version; consult the MISP project release notes and the GitHub Security Advisory (GHSA-r3v6-qw6x-wf6h) for the patched release. Pin the new version in deployment manifests.
• Third-party assurance. Where MISP is operated by a third-party provider, require written confirmation that the fix has been applied and request the deployment timestamp.
• Configuration review. Verify that MISP's organisation-level sharing settings, ACLs, and feature permissions are configured to least privilege; in particular, ensure that canEditAnalystData and equivalent ownership checks are not bypassed by custom roles.

P3 — within 7 days

• Detection tuning. Add monitoring for cross-organisation modifications in the five affected subsystems (see Section 6).
• Contractual review. For third-party-operated MISP, confirm contracts permit audit, notification, and exit/transition in light of this class of vulnerability (DORA Art. 30 trigger).
• Concentration review. Document whether the firm has a concentrated dependency on MISP and the mitigation in place (DORA Art. 29 trigger).

5. Indicators of compromise

No indicators of compromise are available in the source material.

6. Detection

Insufficient indicators to author detection rules.

7. Sources

• GitHub Security Advisories — GHSA-r3v6-qw6x-wf6h — MISP core contained multiple broken access-control flaws — https://github.com/advisories/GHSA-r3v6-qw6x-wf6h — 2026-06-22
• GitHub Security Advisories — GHSA-9cgp-f46x-4wgf — An incorrect authorization vulnerability in MISP (related, distinct) — https://github.com/advisories/GHSA-9cgp-f46x-4wgf
• BSI Germany — WID-SEC-2026-1907 — MISP: Mehrere Schwachstellen — https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-1907

8. Adverse Trace position

Severity is not asserted in this advisory because no CVSS score, severity rating, or CISA KEV exploitation status has been resolved for this item. The vulnerability class — broken access control on write paths in a CTI-sharing platform — is, however, high-impact by design: any authenticated user with the relevant feature permission can tamper with intelligence shared across organisations, undermining the integrity guarantees that MISP is meant to provide. EMEA financial services firms operating or consuming MISP should treat this as a priority patch item, restrict write access to the five affected subsystems until a fix is applied, and engage their third-party providers for written confirmation of remediation. Adverse Trace will monitor upstream MISP release notes for the patched version and update this advisory accordingly; clients should report any suspected exploitation through the standard incident channel so that DORA / NIS2 reporting obligations can be assessed.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.