
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: >= 0.43.0, < 0.54.0-rc.0
Patched in 0.54.0-rc.0
Details
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.
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
This issue can be avoided by using the provisioning to create the datasource and by removing the right to create datasource.
EPSS, exploit probability
Low0.27%
estimated chance of real-world exploitation in the next 30 days, higher than 18.9% of every CVE FIRST.org scores
Refreshed 11/2/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.