CVE-2026-63199: Perses Information Disclosure Vulnerability

CVE-2026-63199 Overview

CVE-2026-63199 is a missing authorization vulnerability [CWE-862] in Perses, an open-source dashboard and visualization project for observability data. Affected versions from 0.43.0 through 0.53.x authorize callers on the Datasource or GlobalDatasource scope during datasource creation and unsaved datasource proxy paths. The code does not verify read permission on the associated project or global Secret before resolving it. A low-privilege user with GlobalDatasource:create or equivalent project datasource creation rights can attach an unreadable secret, redirect the datasource to an attacker-controlled service, and receive the decrypted secret in plaintext. The issue is fixed in version 0.54.0-rc.0.

Critical Impact
Authenticated low-privilege users can exfiltrate arbitrary project or global secrets in plaintext, bypassing Perses scope separation.

Affected Products

Perses >= 0.43.0
Perses < 0.54.0-rc.0
Perses observability dashboard deployments using project or global Secrets

Discovery Timeline

2026-09-18 - CVE-2026-63199 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-63199

Vulnerability Analysis

Perses supports Datasources and GlobalDatasources that can reference Secrets holding authentication material such as bearer tokens or client credentials. When a user creates a datasource or invokes the unsaved datasource proxy endpoint, Perses evaluates only whether the caller has permission on the datasource scope. The server then resolves and decrypts the referenced Secret server-side without checking whether the caller has read permission on that Secret's project or global scope.

Because the datasource specification includes a proxy URL controlled by the user, the caller can point the datasource at an HTTP endpoint they own. Perses attaches the decrypted secret to outbound proxy requests, transmitting it in plaintext to the attacker's listener. The result is a cross-scope disclosure that defeats the separation between the Datasource and Secret RBAC objects.

Root Cause

The root cause is missing authorization enforcement in the datasource service and global datasource proxy handler. Prior to the fix, datasourceImpl.NewService and globalDatasourceImpl.NewService were instantiated without an authzService reference, leaving no mechanism to check Secret read permissions before dereferencing. The proxy handler resolved secrets through a closure that ignored the caller's authorization context.

Attack Vector

Exploitation requires network access to the Perses API and a low-privilege authenticated account that holds GlobalDatasource:create or equivalent project-level datasource creation rights. No user interaction is required. The attacker crafts a datasource specification that references a target Secret they cannot read, sets the proxy URL to an attacker-controlled host, and triggers the proxy or creation flow. Perses decrypts the Secret and forwards it as plaintext to the attacker endpoint.

// Patch: pass authzService into datasource services so Secret reads are authorized
schemaService := pluginService.Schema()
migrateService := pluginService.Migration()
dashboardService := dashboardImpl.NewService(conf, dao.GetDashboard(), dao.GetGlobalVariable(), dao.GetVariable(), schemaService)
-datasourceService := datasourceImpl.NewService(dao.GetDatasource(), schemaService)
+datasourceService := datasourceImpl.NewService(dao.GetDatasource(), schemaService, authzService)
ephemeralDashboardService := ephemeralDashboardImpl.NewService(dao.GetEphemeralDashboard(), dao.GetGlobalVariable(), dao.GetVariable(), schemaService)
folderService := folderImpl.NewService(dao.GetFolder())
variableService := variableImpl.NewService(dao.GetVariable(), schemaService)
-globalDatasourceService := globalDatasourceImpl.NewService(dao.GetGlobalDatasource(), schemaService)
+globalDatasourceService := globalDatasourceImpl.NewService(dao.GetGlobalDatasource(), schemaService, authzService)

Source: GitHub Commit 2368c9ef

A second hunk in internal/api/impl/proxy/globaldatasource.go refactors proxyGlobalDatasource to accept a caller-scoped retrieveSecret function instead of an unconditional global secret lookup, forcing authorization checks at the call site.

Detection Methods for CVE-2026-63199

Indicators of Compromise

Datasource or GlobalDatasource creation events by low-privilege accounts that reference Secrets outside their normal project scope.
Outbound HTTP or HTTPS requests from Perses to unfamiliar external hosts carrying Authorization, X-Api-Key, or similar header values.
Unsaved datasource proxy requests (/proxy/*) with proxy URLs pointing to attacker-controlled or non-corporate infrastructure.

Detection Strategies

Review Perses audit logs for Datasource and GlobalDatasource create operations that bind Secrets the caller lacks read access to.
Correlate proxy endpoint invocations with the destination URL declared in the datasource spec and flag external or newly registered domains.
Compare Perses egress traffic against an allowlist of expected observability backends such as Prometheus, Tempo, and Loki instances.

Monitoring Recommendations

Enable and centrally forward Perses API server audit logs to a SIEM for retention and correlation.
Alert on rapid creation of ephemeral datasources followed by proxy invocations from the same principal.
Monitor Secret resolution counts per user and flag statistical anomalies across project and global scopes.

How to Mitigate CVE-2026-63199

Immediate Actions Required

Upgrade Perses to version 0.54.0-rc.0 or later on all API server instances.
Rotate every project and global Secret that may have been referenced by an unauthorized datasource since deploying an affected version.
Audit RBAC bindings and revoke Datasource:create and GlobalDatasource:create permissions from accounts that do not require them.

Patch Information

The fix ships in Perses v0.54.0-rc.0. It threads authzService into both datasourceImpl.NewService and globalDatasourceImpl.NewService, and refactors the global datasource proxy to accept a caller-scoped retrieveSecret function so Secret read authorization is enforced before decryption. See the GitHub Security Advisory GHSA-4227-9989 and GitHub Release v0.54.0-rc.0.

Workarounds

Restrict datasource creation permissions to trusted administrators until the upgrade is complete.
Place Perses behind a network egress proxy that allowlists only approved observability backend destinations.
Disable the unsaved datasource proxy endpoint at the reverse proxy layer where feasible.

bash

# Verify the running Perses version and upgrade
perses --version
# Upgrade container image tag
docker pull persesdev/perses:v0.54.0-rc.0
kubectl set image deployment/perses perses=persesdev/perses:v0.54.0-rc.0