CVE-2026-63458: Perses Authentication Bypass Vulnerability

CVE-2026-63458 Overview

CVE-2026-63458 is a broken access control vulnerability [CWE-639] in Perses, an open-source dashboard and visualization project for observability data. Authenticated users with viewer access to one project can read dashboards, datasources, and variables belonging to other projects. The flaw resides in project-scoped list endpoints such as /api/v1/projects/{project}/dashboards and /api/v1/datasources, where a project query parameter overrides the authorization context. Perses versions prior to 0.54.0-beta.3 are affected, and the maintainers fixed the issue in 0.54.0-beta.3.

Critical Impact

Any authenticated viewer can enumerate and exfiltrate complete resource specifications from other tenants, breaking project-level isolation.

Affected Products

• Perses versions prior to 0.54.0-beta.3
• Perses project-scoped list endpoints for dashboards, datasources, and variables
• Multi-tenant Perses deployments relying on project-based isolation

Discovery Timeline

• 2026-09-18 - CVE-2026-63458 published to NVD
• 2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-63458

Vulnerability Analysis

Perses exposes project-scoped list endpoints that return dashboards, datasources, and variables. The service layer accepts a project value derived from either the URL path or a project query parameter. When both are supplied, the query parameter takes precedence in the underlying query construction but is not re-validated against the caller's authorization for that project.

An authenticated viewer of project-A can send a list request while supplying project=project-B in the query string. The backend selects resources for project-B and returns them, including full specification objects. This exposes dashboard definitions, datasource connection metadata, and variable configurations across tenants.

The upstream fix removes the caller-controlled query manipulation from the service layer. The List, RawList, and MetadataList methods in internal/api/impl/v1/dashboard/service.go no longer call a manageQuery helper that folded request parameters into the query. A new GetProjectQueryParam / SetProjectQueryParam contract on the parameters interface centralizes project scoping so authorization can be enforced consistently.

Root Cause

The root cause is authorization based on request-controlled input [CWE-639]. The service assumed the project value derived from query parameters had already been authorized, but no check enforced that the authenticated caller could access the resolved project. This breaks tenant isolation whenever a viewer role exists on any project.

Attack Vector

Exploitation requires only low-privileged authenticated access. The attacker sends an HTTP request to a project-scoped list endpoint and supplies the target project name through the project query parameter. No user interaction, elevated privileges, or additional conditions are required. The response contains the full resource specifications for the targeted project.

// Patch excerpt: internal/api/impl/v1/dashboard/service.go
// The vulnerable variants accepted apiInterface.Parameters and
// merged caller-controlled query values without re-authorizing.

-func (s *service) List(q *dashboard.Query, params apiInterface.Parameters) ([]*v1.Dashboard, error) {
-	query, err := manageQuery(q, params)
-	if err != nil {
-		return nil, err
-	}
-	return s.dao.List(query)
+func (s *service) List(q *dashboard.Query) ([]*v1.Dashboard, error) {
+	return s.dao.List(q)
 }

-func (s *service) RawList(q *dashboard.Query, params apiInterface.Parameters) ([]json.RawMessage, error) {
-	query, err := manageQuery(q, params)
-	if err != nil {
-		return nil, err
-	}
-	return s.dao.RawList(query)
+func (s *service) RawList(q *dashboard.Query) ([]json.RawMessage, error) {
+	return s.dao.RawList(q)
 }

Source: GitHub Commit 8015fb3

Detection Methods for CVE-2026-63458

Indicators of Compromise

• HTTP requests to /api/v1/projects/{project}/dashboards or /api/v1/datasources where the project query parameter value differs from the {project} path segment.
• Authenticated sessions issuing list requests for projects the associated user is not a member of.
• Sudden growth in list-endpoint response sizes for accounts that historically accessed only a single project.

Detection Strategies

• Review Perses access logs for requests containing a project query parameter and correlate against each user's project membership.
• Deploy Web Application Firewall (WAF) rules that flag requests where the path project and query-parameter project disagree.
• Baseline per-user API access patterns and alert on enumeration behavior across multiple project names.

Monitoring Recommendations

• Forward Perses API and authentication logs to a centralized logging platform for cross-tenant correlation.
• Alert when the same session queries datasource or dashboard list endpoints for more than one distinct project within a short window.
• Monitor the deployed Perses version and generate an alert if any instance runs a release earlier than 0.54.0-beta.3.

How to Mitigate CVE-2026-63458

Immediate Actions Required

• Upgrade all Perses instances to version 0.54.0-beta.3 or later without delay.
• Audit recent access logs for requests where the project query parameter references projects outside the caller's authorization.
• Rotate credentials, tokens, and datasource secrets that may have been exposed through cross-project reads.

Patch Information

The fix is delivered in Perses v0.54.0-beta.3. It removes caller-controlled project overrides from list service methods and introduces explicit GetProjectQueryParam / SetProjectQueryParam accessors so authorization is enforced against the resolved project. Refer to the GitHub Security Advisory GHSA-cjgj-2fwf-4c2w and the upstream commit 8015fb3 for full technical details.

Workarounds

• If patching is not immediately possible, restrict Perses to trusted single-tenant use until the upgrade is applied.
• Place a reverse proxy in front of Perses that strips or rejects the project query parameter on project-scoped list endpoints.
• Temporarily revoke viewer-only accounts on shared multi-tenant deployments where cross-project exposure is unacceptable.

# Example NGINX rule: reject list requests where a project query parameter is supplied
location ~ ^/api/v1/(projects/[^/]+/(dashboards|datasources|variables)|datasources)$ {
    if ($arg_project) {
        return 400;
    }
    proxy_pass http://perses_backend;
}