CVE-2026-63458: Broken Object Level Authorization (BOLA) and Tenant Isolation Bypass in Perses

Perses is an open-source observability dashboard and visualization platform designed for multi-tenant environments.

Multi-tenancy in Perses relies on project boundaries to isolate dashboards, datasources, folders, variables, and secrets.

Security boundaries must prevent users assigned to one project from viewing or modifying resources belonging to another project.

Prior to version 0.54.0-beta.3, Perses suffered from a significant Broken Object Level Authorization (BOLA) vulnerability.

The application evaluated permissions based on path parameters but retrieved data using client-controlled query parameters.

This inconsistency allowed authenticated users with minimum viewer access to bypass project isolation and read sensitive resource metadata from arbitrary projects.

The root cause of the vulnerability lies in the parameter precedence logic inside the Perses API service layer.

Specifically, the helper function manageQuery processed incoming query filters before interacting with the database.

When a client requested a list of resources, the API extracted the project scope from both the HTTP request path and the URL query parameters.

In the vulnerable implementation, manageQuery prioritized existing values in the query object over the validated path parameter.

If the project key was present in the query string, the helper skipped overriding it with the authorized path variable.

Consequently, the authorization middleware performed access checks against the safe path parameter, while the database query execution layer proceeded to retrieve records using the attacker-controlled query parameter.

Additionally, a secondary gap existed within the authorization middleware's path registration.

The middleware classified incoming requests as project-scoped or global by checking their paths against a static list.

Because the endpoint for Ephemeral Dashboards (PathEphemeralDashboard) was omitted from this registration array, all requests targeting ephemeral dashboards bypassed project-scoped authorization entirely.

The vulnerable code in the service layer relied on manageQuery to resolve the target project.

The function failed to enforce alignment between the authorized parameter and the query filter:

// Vulnerable implementation of manageQuery
func manageQuery(q *dashboard.Query, params apiInterface.Parameters) (*dashboard.Query, error) {
    query, err := deep.Copy(q)
    if err != nil {
        return nil, fmt.Errorf("unable to copy the query: %w", err)
    }
    // If the query parameter is already populated, this override is skipped
    if len(query.Project) == 0 {
        query.Project = params.Project
    }
    return query, nil
}

The remediation removed manageQuery entirely and established query verification in the central toolbox component.

The toolbox now enforces strict parity between the path scope and the query parameter:

// Patched logic in internal/api/toolbox/list.go
func (t *toolbox[T, K, V]) list(ctx echo.Context, parameters apiInterface.Parameters, query V) (any, error) {
    projectQueryParameter := query.GetProjectQueryParam()
    if len(projectQueryParameter) > 0 {
        // Enforce strict matching between the path-defined project and query-defined project
        if len(parameters.Project) > 0 && parameters.Project != projectQueryParameter {
            return nil, apiInterface.HandleBadRequestError(fmt.Sprintf("the project name in the path (%s) and the project name in the query parameter (%s) are different", parameters.Project, projectQueryParameter))
        }
        // Override parameter to ensure authorization is performed on the actual target
        parameters.Project = projectQueryParameter
    }

To resolve the second issue, the middleware utility array was updated to include the missing ephemeral path variable:

// Patched internal/api/utils/utils.go
var ProjectResourcePathList = []string{
    PathDashboard,
    PathEphemeralDashboard, // Added to enforce authorization checks
    PathDatasource,
    PathFolder,
    PathRole,
    PathRoleBinding,
    PathSecret,
    PathVariable,
}

To exploit this vulnerability, an attacker must first obtain valid credentials with viewer permissions for at least one project on the target Perses instance.

The attacker does not require administrative privileges.

This low prerequisite threshold increases the likelihood of internal exploitation in multi-tenant environments.

The attacker crafts a standardized HTTP GET request to a project-scoped list endpoint.

The request targets the project for which the attacker possesses authorization, but appends the target project's name as a query parameter.

The following diagram illustrates the vulnerable flow and the authorization bypass mechanism:

When the query parameter is processed, the backend queries the database for resources matching the query value instead of the path value.

The server returns the configuration objects of the unauthorized tenant, exposing credentials, data source locations, and dashboard layouts.

The impact of CVE-2026-63458 is classified as High, with a CVSS v4.0 base score of 7.1.

The attack vector is Network, requiring Low privileges and zero user interaction.

The primary impact is to Confidentiality, which is assessed as High.

An attacker can read the complete database schema, connection endpoints, credentials, and variable configurations of other projects.

For datasources, this exposure could reveal sensitive system metrics, internal infrastructure topology, or monitoring credentials.

Because the vulnerability does not allow modification of resources or interruption of service, Integrity and Availability impacts are rated as None.

While there is no current evidence of active exploitation in the wild, the vulnerability presents a significant risk to organizations utilizing Perses as a shared, multi-tenant monitoring service.

Security teams should treat this as a high-priority exposure in environments where sensitive data is separated on a project-by-project basis.

The recommended and complete remediation for CVE-2026-63458 is upgrading the Perses server installation to version 0.54.0-beta.3 or higher.

This release contains the updated verification pipeline in the toolbox module that rejects mismatched requests.

If upgrading is not immediately possible, security teams can implement temporary Web Application Firewall (WAF) or reverse proxy rules.

The rules should analyze incoming GET requests to /api/v1/projects/ paths.

If the request contains a query parameter named project that does not match the project name in the path, the request must be blocked and a 400 Bad Request returned.

Organizations should also conduct a retrospective log analysis of their web server access logs.

Search for HTTP requests that access project resources and contain the project query parameter.

Comparing the path segment against the query parameter value will help identify any past exploitation attempts.