CVE-2026-63199: Perses: Missing authorization in datasource proxy allows cross-scope secret disclosure
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.
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/perses/persesto a version that resolves this vulnerability.Fixed in 0.54.0-rc.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 0.54.0-rc.0 - Configuration
Avoid the issue by removing the `GlobalDatasource:create` (and corresponding project datasource creation rights) permission from low-privilege users, so they cannot create datasource resources to trigger the datasource proxy behavior.
Perses datasource creation permissions GlobalDatasource:create = remove/deny for low-privilege users - Compensating control
Avoid the issue by provisioning/creating the datasource via provisioning (instead of using the datasource creation proxy paths) and by removing datasource creation rights from the operators/users who could exploit the cross-scope secret disclosure.
Event History
Frequently Asked Questions
Who can exploit this issue?
A low-privilege user who has permission to create a GlobalDatasource or the corresponding project-level datasource can exploit it. The user does not need read permission for the associated project or global Secret.
What must an attacker be able to do to disclose a secret?
The attacker must be able to create a datasource or use the unsaved datasource proxy path, attach a Secret they cannot read, and configure the datasource to contact a service they control. Perses can then send the decrypted Secret to that service in plaintext.
Are both project and global Secrets affected?
Yes. The affected authorization checks can allow access to separately grantable project Secrets and global Secrets, bypassing the intended separation between project and global scopes.
What versions are affected and what version fixes the issue?
Perses versions from 0.43.0 until 0.54.0-rc.0 are affected. The issue is fixed in version 0.54.0-rc.0.