CVE-2026-63199

Perses is an open-source dashboard and visualization project for observability data. From 0.43.0 until 0.54.0-rc.0, the datasource creation and unsaved datasource proxy paths authorize the caller on a Datasource or GlobalDatasource scope but do not require read permission for the separately grantable associated project or global Secret before resolving it. A low-privilege user with GlobalDatasource:create or corresponding project datasource creation rights can attach a project or global Secret that the user cannot otherwise read, point the datasource at a service controlled by the user, and cause Perses to send the decrypted secret in plaintext, bypassing project and global scope separation. This issue is fixed in version 0.54.0-rc.0.

Perses is an open-source dashboard and visualization project for observability data. From 0.43.0 until 0.54.0-rc.0, the datasource creation and unsaved datasource proxy paths authorize the caller on a Datasource or GlobalDatasource scope but do not require read permission for the separately grantable associated project or global Secret before resolving it. A low-privilege user with GlobalDatasource:create or corresponding project datasource creation rights can attach a project or global Secret that the user cannot otherwise read, point the datasource at a service controlled by the user, and cause Perses to send the decrypted secret in plaintext, bypassing project and global scope separation. This issue is fixed in version 0.54.0-rc.0.

Impact

The datasource proxy authorizes the caller on the Datasource scope, then resolves and decrypts any Secret named in the request body with no Secret-scope check.

Datasource and Secret are distinct, independently grantable role scopes, so an operator can grant datasource access without secret access. The proxy and the service to create a datasource does not verify that the operator has the correct right.

A user holding only GlobalDatasource:create can create a GlobalDatasource and attached to it a GlobalSecret without having the right to get access to. The user can also do the same by using the unSaved datasource feature proposed by the proxy used to verify the connectivity to the datasource before creating the resource.

As soon as you can attach a secret that you don't have right to see, you can then create a Datasource that you control and then read anything send by Perses. Which include the secret in plain text. You can then have access to the secret without being granted to.

The project-scoped variant does the same within a project.

Patches

The proxy and the service to create the datasource is verifying if you have the right to read a secret if a secret is attached to the datasource. This is patch in v0.54.0-rc.0

Workarounds

This issue can be avoided by using the provisioning to create the datasource and by removing the right to create datasource.

Perses is an open-source dashboard and visualization project for observability data. From 0.43.0 until 0.54.0-rc.0, the datasource creation and unsaved datasource proxy paths authorize the caller on a Datasource or GlobalDatasource scope but do not require read permission for the separately grantable associated project or global Secret before resolving it. A low-privilege user with GlobalDatasource:create or corresponding project datasource creation rights can attach a project or global Secret that the user cannot otherwise read, point the datasource at a service controlled by the user, and cause Perses to send the decrypted secret in plaintext, bypassing project and global scope separation. This issue is fixed in version 0.54.0-rc.0.

Perses is an open-source dashboard and visualization project for observability data. From 0.43.0 until 0.54.0-rc.0, the datasource creation and unsaved datasource proxy paths authorize the caller on a Datasource or GlobalDatasource scope but do not require read permission for the separately grantable associated project or global Secret before resolving it. A low-privilege user with GlobalDatasource:create or corresponding project datasource creation rights can attach a project or global Secret that the user cannot otherwise read, point the datasource at a service controlled by the user, and cause Perses to send the decrypted secret in plaintext, bypassing project and global scope separation. This issue is fixed in version 0.54.0-rc.0.

Impact

The datasource proxy authorizes the caller on the Datasource scope, then resolves and decrypts any Secret named in the request body with no Secret-scope check.

Datasource and Secret are distinct, independently grantable role scopes, so an operator can grant datasource access without secret access. The proxy and the service to create a datasource does not verify that the operator has the correct right.

A user holding only GlobalDatasource:create can create a GlobalDatasource and attached to it a GlobalSecret without having the right to get access to. The user can also do the same by using the unSaved datasource feature proposed by the proxy used to verify the connectivity to the datasource before creating the resource.

As soon as you can attach a secret that you don't have right to see, you can then create a Datasource that you control and then read anything send by Perses. Which include the secret in plain text. You can then have access to the secret without being granted to.

The project-scoped variant does the same within a project.

Patches

The proxy and the service to create the datasource is verifying if you have the right to read a secret if a secret is attached to the datasource. This is patch in v0.54.0-rc.0

Workarounds

This issue can be avoided by using the provisioning to create the datasource and by removing the right to create datasource.

Perses's missing authorization in datasource proxy allows cross-scope secret disclosure in github.com/perses/perses

These are all security issues fixed in the perses-cli-0.54.0-1.1 package on the GA media of openSUSE Tumbleweed.