CVE-2026-63458 in Perses
Summary
by MITRE • 09/18/2026
Perses is an open-source dashboard and visualization project for observability data. Prior to 0.54.0-beta.3, an authenticated user with viewer access to one project can supply another project through the project query parameter on project-scoped list endpoints, including /api/v1/projects/{project}/dashboards and /api/v1/datasources. The request-controlled project value is used to select dashboards, datasources, and variables without enforcing the caller's authorization for that selected project, which breaks project-level tenant isolation and exposes complete resource specifications belonging to other projects. This issue is fixed in version 0.54.0-beta.3.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in Perses prior to version 0.54.0-beta.3 represents a critical failure in access control logic, specifically categorized under CWE-284 Improper Access Control and aligned with the MITRE ATT&CK technique T1078 Valid Accounts. As an open-source dashboarding platform designed for observability data, Perses relies on strict project-level tenant isolation to ensure that users can only interact with resources belonging to their authorized scope. The flaw arises from a broken object reference mechanism where the application fails to validate whether the authenticated user possesses permissions for the specific project identified in the request parameters rather than just the context of the current session or endpoint path.
Technically, the vulnerability is exploited through HTTP query parameters on endpoints that are ostensibly scoped to a single project, such as /api/v1/projects/{project}/dashboards and /api/v1/datasources. An attacker who has obtained viewer-level access credentials for one specific project can manipulate the request by injecting a different project identifier into the relevant query parameter. The backend logic processes this supplied value directly without cross-referencing it against the user's actual permission set or role-based access control list. This lack of server-side authorization enforcement allows the application to retrieve and return data associated with the injected project ID, effectively bypassing the intended security boundaries that separate tenant environments within the multi-tenant architecture.
The operational impact of this vulnerability is severe due to the nature of observability platforms which often aggregate sensitive telemetry, logs, metrics, and potentially personally identifiable information from various infrastructure components. By exploiting this flaw, an authenticated user with minimal privileges can enumerate and view complete resource specifications belonging to other projects. This includes accessing dashboards that may reveal architectural details, viewing data sources that could expose connection strings or database schemas, and inspecting variables that might contain sensitive configuration values. The breach of tenant isolation undermines the fundamental security model of the application, potentially leading to further attacks such as privilege escalation if additional vulnerabilities exist within the exposed resources, or causing significant compliance violations depending on the sensitivity of the data accessed across tenants.
Mitigation for this issue requires immediate upgrading to Perses version 0.54.0-beta.3 or later, where the developers have implemented proper authorization checks that validate user permissions against the target project specified in the request parameters. In environments where an upgrade is not immediately feasible, administrators should implement strict input validation and access control middleware at the reverse proxy or API gateway level to ensure that any project identifier supplied via query parameters matches the authorized scope of the authenticated session. Additionally, enforcing principle of least privilege by limiting viewer accounts to only essential permissions can reduce the blast radius if such an exploitation attempt occurs in unpatched systems. Regular security audits focusing on object-level access control patterns are recommended to detect similar implementation flaws across other endpoints within the application ecosystem.