Vulnerabilities

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.