CVE-2026-95805: MISP ACLComponent: Typo in previewEventAttributes ACL key bypasses intended access restriction
A typo in the MISP ACLComponent access control configuration caused the ACL rule for the previewEventAttributes action to reference the permission string 'themingenabled' (with a trailing asterisk) instead of the correct 'themingenabled'. In the MISP ACL system, the array values define which role or permission grants access to a given controller action. The adjacent entry previewEventObjects correctly uses ['themingenabled'], confirming the intended restriction. The malformed key 'themingenabled' does not match any valid permission identifier, causing the access control check for previewEventAttributes to malfunction. Depending on the ACL evaluation logic, this could result in either unauthorized users gaining access to the previewEventAttributes endpoint (authorization bypass) or legitimate users being denied access (availability impact).
The previewEventAttributes endpoint exposes event attribute data within MISP so an authorization bypass could expose sensitive indicator and attribute data to users who should not have access.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Change the ACL rule for the previewEventAttributes action from the malformed permission string 'theming_enabled*' to 'theming_enabled', so only users with the theming_enabled permission can invoke the endpoint.
MISP ACLComponent previewEventAttributes ACL permission key = theming_enabled
Event History
Frequently Asked Questions
What endpoint and data may be exposed if the ACL check fails open?
The affected action is previewEventAttributes. If the malformed ACL permission is evaluated as an authorization bypass, users who should not have access could view MISP event attribute data, including potentially sensitive indicators and attributes.
Is exploitation dependent on a particular permission being assigned to the attacker?
The intended access requirement is the theming_enabled permission, but the affected rule instead uses theming_enabled* with a trailing asterisk. The data does not establish the exact ACL outcome, so the issue may either permit unauthorized access or deny legitimate access depending on ACL evaluation logic.
How can administrators identify the affected configuration?
Inspect the ACLComponent rule for previewEventAttributes. It is affected if that action references theming_enabled* rather than theming_enabled; the adjacent previewEventObjects rule is described as using the correct theming_enabled value.