Vulnerabilities

MISP versions 2.5.45 and earlier accept attacker-controlled email input on the unauthenticated forgot-password reset endpoint without a length bound or format validation, persisting the supplied value twice per request (once in an audit log entry and once in a queued password-reset job) with no rate limiting. An unauthenticated attacker can repeatedly submit oversized or arbitrary values to this and similar pre-auth paths (registrations, failed REST authentication attempts), driving unbounded growth of persistent storage and queued work. The result is high availability impact (CVSS 4.0 8.7, VA:High): resource exhaustion can degrade or disrupt the instance, while confidentiality and integrity are unaffected. Any MISP deployment running 2.5.45 or earlier is affected, particularly instances where the pre-auth reset flow is reachable by untrusted users. No public PoC, no CISA KEV listing, and an EPSS of about 0.3% indicate no known exploitation at this time.

Do: Upgrade MISP to a release newer than 2.5.45, which adds the 1024-byte email length cap, email-format validation before persistent work, a per-source pre-auth request budget with HTTP 429 responses, and a 15-minute cooldown for API-access request emails. Until patched, rate-limit or restrict unauthenticated access to the forgot-password and other pre-auth endpoints at a reverse proxy or WAF, and monitor audit-log and job-queue growth for signs of storage exhaustion. Also verify the API-access request endpoint is POST-only with CSRF protection in the deployed version.

MISP's custom LdapAuthenticate and LinOTPAuthenticate components, which replace CakePHP's FormAuthenticate, failed to replicate its credential validation, allowing empty or non-string values to reach the underlying authentication mechanisms. A remote attacker who knows a valid directory user's email address can submit an empty password, which is passed to ldap_bind(); if the LDAP server accepts unauthenticated binds, the bind succeeds and MISP treats the attacker as that directory user without verifying any password. The flaw also affects the LinOTP path and local fallback: with mixed authentication enabled, an empty password can be checked against a stored MISP password hash, and LDAP-provisioned accounts may have been created with an empty local password that remains usable once the account is no longer resolved through LDAP. Successful exploitation lets an unauthenticated attacker impersonate an existing MISP user — potentially an administrator — gaining access to sensitive threat-intelligence data and the ability to modify or delete it and alter configuration. Only MISP deployments with the LDAP or LinOTP authentication components enabled are affected; no public proof-of-concept or in-the-wild exploitation is known (EPSS 0.5%, not in CISA KEV).

Do: Upgrade MISP to the patched release addressing CVE-2026-85216; the fix enforces valid string credentials, rejects empty passwords where not permitted, and assigns randomly generated local passwords to LDAP-provisioned accounts. As interim mitigations, configure the LDAP directory to reject unauthenticated (empty-password) binds, disable mixed authentication with LinOTP if not needed, and reset the local passwords of LDAP-provisioned MISP accounts — especially privileged ones — in case they hold empty-password hashes. Review authentication logs for successful logins against known directory-user email addresses using empty passwords.

MISP Core contained broken access-control checks in the bulk deletion flows for Event Reports and Sharing Groups. The affected deleteSelection handlers authorized deletion using broad role-level permissions instead of validating authorization for each selected object. For Event Reports, EventReportsController::deleteSelection relied on the global perm_add capability rather than a per-report ownership/authorization check. As a result, a contributor-level user could submit report IDs or UUIDs for reports belonging to other organisations and hard-delete them instance-wide. The fix changed the callback to call EventReport::fetchIfAuthorized($user, $itemId, 'delete') for each selected report before deletion. For Sharing Groups, SharingGroupsController::deleteSelection relied on the global perm_sharing_group capability rather than verifying ownership of each selected sharing group. This allowed a sharing-group-capable user to hard-delete sharing groups owned by other organisations, bypassing the per-object ownership gate used by the single-object delete action. The fix changed the callback to call SharingGroup::checkIfOwner($user, $itemId) for each selected sharing group. An authenticated attacker with the relevant broad role permission could abuse the affected bulk deletion endpoints to delete objects outside their organisation’s authorization scope, causing loss of event-report content or sharing-group configuration across the instance.