MISP CVE-2026-95671

Exploitation requires an authenticated MISP session (PR:L) plus knowledge of a valid identifier for a sharing group the attacker is NOT authorized to use. The attacker must send a PUT request to the collections/add endpoint rather than the expected POST, and must set distribution=4 (share with a specific sharing group). What LIMITS exploitation: a valid low-privileged account is mandatory (no unauthenticated path), the attacker must know or guess a target sharing-group ID, and impact is confined to improperly associating collection data with that group - no data read, code execution, or service disruption. No user interaction and no special tooling are needed. The condition is inherent to the affected MISP versions with no non-default feature toggle required.

This is a genuine but low-severity authorization flaw, not a high-CVSS scare. All signals agree on modest real-world risk. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N, base 5.3) correctly reflects an authenticated (PR:L), network-reachable, low-complexity bug with integrity-only impact and no confidentiality or availability loss - consistent with the CWE-862 missing-authorization classification and the source-code diff. There is no EPSS score, no CISA KEV listing, and no public exploit code, so exploitation status is 'no public exploit identified at time of analysis.' The one amplifying signal is that a vendor patch (MISP commit c20f5a836) already exists and the root cause is trivially understandable from the one-line diff, which lowers the barrier to weaponization - but the impact ceiling is bounded: an attacker can only mis-file collection data into a sharing group they lack rights to, not read others' data or execute code. Net: a real, patch-worthy access-control bug for MISP operators, but a routine-priority fix rather than an emergency. No signals conflict; the chief limitation is that all data derives from a single vendor/CIRCL source with no independent corroboration of impact.

An authenticated MISP user who knows the ID of a sharing group they are not authorized to use sends a PUT request (instead of the expected POST) to the collections/add endpoint, creating a collection with distribution=4 bound to that restricted sharing group. Because CRUDComponent::add() persists on both POST and PUT but the sharing-group usability check only ran on POST, the guard is skipped and the collection is exposed to all members of the unauthorized sharing group. No public exploit code exists, but the technique requires only a changed HTTP verb and no special tooling.