CVE-2026-86417 in MISP
Summary
by MITRE • 09/07/2026
Affected versions of MISP inconsistently enforced email-address visibility in DashboardsController::listTemplates().
The query always fetched User.email, while redaction happened only inside the non-REST rendering branch. As a result, the same authenticated user who saw redacted data in the normal HTML interface could request the REST/JSON representation and receive template owners’ email addresses without the intended privilege check.
The fix moves the decision to a centralized User::canSeeEmails() authorization helper. Email addresses are now fetched only when the requester is a site administrator or the instance explicitly enables Security.disclose_user_emails. The same helper is also reused by other dashboard widgets to keep email-disclosure policy consistent.
Version affected: ≤2.5.45
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability in MISP versions up to 2.5.45 represents a classic authorization bypass rooted in inconsistent enforcement of access control policies within the application's presentation layer. Specifically, the flaw resides in the DashboardsController::listTemplates() method, which is responsible for retrieving template information for display on user dashboards. The core technical issue stems from an architectural inconsistency where data retrieval and data redaction were decoupled improperly. While the database query was configured to always fetch the User.email field associated with template owners, the logic intended to mask or redact this sensitive personally identifiable information was only implemented within the non-REST rendering branch of the codebase. This separation created a critical security gap where the application's internal data model exposed more information than its public-facing interfaces were designed to reveal.
From an operational perspective, this inconsistency allowed authenticated users who were restricted from viewing email addresses in the standard HTML interface to bypass these restrictions by interacting with the REST API. When such a user requested the JSON representation of template lists via the API endpoint, they received unredacted email addresses of other users because the redaction logic was absent in that specific code path. This constitutes an Insecure Direct Object Reference combined with Broken Access Control, as the application failed to enforce uniform privacy policies across different communication channels and data formats. The vulnerability effectively undermined the principle of least privilege by allowing lower-privileged users to access sensitive user attributes that were explicitly withheld from them in other contexts, thereby violating the intended security posture regarding user privacy and data minimization.
The remediation strategy employed addresses this flaw by centralizing the authorization logic rather than scattering it across multiple rendering branches. The fix introduces a dedicated User::canSeeEmails() helper function to serve as the single source of truth for determining email visibility permissions. This centralized approach ensures that all components, including dashboard widgets and API endpoints, adhere to the same security policy defined by site administrator privileges or the Security.disclose_user_emails configuration setting. By fetching the email address only when this check passes positively, the application eliminates the possibility of accidental data leakage through alternative interfaces. Furthermore, reusing this helper across other dashboard widgets ensures consistency in how sensitive user attributes are handled throughout the entire platform, reducing the attack surface for similar logic errors in future development cycles.
In terms of industry standards and threat modeling, this vulnerability aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials if one considers the static nature of the initial query's data fetching strategy as a failure to apply dynamic security policies. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, where an attacker leverages valid credentials but exploits misconfigured permissions to access unauthorized resources. The incident highlights the importance of implementing defense-in-depth strategies where authorization checks are performed at multiple layers, particularly ensuring that API responses undergo the same rigorous validation as web interface outputs. Security practitioners should review their own implementations for similar patterns where data retrieval is not strictly coupled with real-time permission verification across all output formats to prevent inadvertent information disclosure through less scrutinized channels like JSON APIs or XML feeds.