CVE-2026-91851 in MISP
Summary
by MITRE • 09/15/2026
Affected versions of MISP incorrectly filter dashboard templates that are restricted to a specific permission flag.
DashboardsController::listTemplates() allowed a template when either:
- its restrict_to_permission_flag matched one of the current user’s permission flags, or
- restrict_to_permission_flag equaled integer 0
However, restrict_to_permission_flag is a varchar. MySQL therefore performed numeric coercion when comparing the column against integer 0. Strings such as perm_site_admin convert numerically to zero, making expressions such as perm_site_admin = 0 evaluate true and causing the “unrestricted” branch to match permission-restricted templates as well.
Version affected: ≤2.5.45
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability in MISP versions up to 2.5.45 represents a critical logic flaw within the DashboardsController::listTemplates function, resulting in an authorization bypass that allows users to access dashboard templates intended for higher privilege levels. This issue stems from improper handling of permission flags during database queries, specifically involving how MySQL processes string comparisons against integer values. The core technical failure lies in the conditional logic used to determine template visibility, which incorrectly treats certain non-zero permission strings as equivalent to zero due to type juggling and numeric coercion inherent in SQL operations on varchar columns.
In a properly secured system, dashboard templates should only be visible if they are either unrestricted or explicitly match one of the current user’s assigned permission flags. The flawed implementation allowed access when either condition was met: the restrict_to_permission_flag matched a user flag, OR the restrict_to_permission_flag equaled integer 0. While this logic appears sound on its surface, it fails to account for MySQL's behavior when comparing varchar data types with integers. In MySQL, if one operand of a comparison is an integer and the other is a string, the database engine attempts to convert the string to a number before performing the comparison.
This numeric coercion leads to unexpected results because many valid permission flag strings, such as perm_site_admin or similar identifiers starting with alphabetic characters rather than digits, are converted to zero during this process. Consequently, an expression like perm_site_admin = 0 evaluates to true in MySQL's execution engine. This causes the unrestricted branch of the logic to trigger for templates that were explicitly restricted by design. As a result, any user possessing basic access rights can view dashboard configurations and data visualizations reserved for administrators or other privileged roles, effectively bypassing the intended permission boundaries.
The operational impact of this vulnerability is significant within multi-tenant environments where strict separation of duties is required. Attackers with low-level privileges could potentially extract sensitive information embedded in restricted dashboards, such as threat intelligence indicators, organizational structures, or internal network maps that are not meant for general consumption. This exposure violates the principle of least privilege and compromises the confidentiality of security operations data managed by MISP instances. It also undermines audit trails since actions performed via these improperly accessed templates may lack proper attribution to high-privilege accounts.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically involving insufficient authorization checks during resource access. The mechanism of exploiting type coercion in database queries is often associated with CWE-697 Incorrect Comparison, although the root cause here is more accurately described as CWE-862 Missing Authorization Check due to flawed logic implementation rather than a simple coding error. In terms of MITRE ATT&CK mapping, this flaw facilitates Initial Access or Discovery phases by allowing unauthorized users to enumerate and view restricted resources without authentication failures that would typically trigger alerts.
Mitigation strategies must address both the immediate code defect and broader database interaction patterns. The primary fix involves correcting the comparison logic in DashboardsController::listTemplates() to ensure strict type checking is enforced, preventing implicit numeric conversion of permission strings. Developers should explicitly cast or compare values as strings when dealing with varchar columns containing non-numeric identifiers. Additionally, implementing explicit checks for null or zero values before performing comparisons can prevent unintended matches. Upgrading to a patched version beyond 2.5.45 resolves this issue by correcting the underlying query logic.
To further harden MISP deployments against similar vulnerabilities, organizations should enforce strict input validation and avoid relying on implicit type conversions in SQL queries. Utilizing parameterized queries with explicit data types can mitigate risks associated with dynamic value comparison. Regular security audits focusing on authorization logic across all controllers are recommended to identify other potential bypasses where permission flags or role identifiers might be mishandled. Monitoring database logs for unusual query patterns involving string-to-integer comparisons may also help detect exploitation attempts in real-time before significant data exposure occurs.