GHSA-4227-9989-JRHX
Vulnerability from github – Published: 2026-09-18 17:39 – Updated: 2026-09-18 17:39Impact
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/perses/perses"
},
"ranges": [
{
"events": [
{
"introduced": "0.43.0"
},
{
"fixed": "0.54.0-rc.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-63199"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-18T17:39:48Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nThe 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.\n\nDatasource 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.\n\nA 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.\n\nAs soon as you can attach a secret that you don\u0027t 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.\n\nThe project-scoped variant does the same within a project.\n\n### Patches\nThe 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.\nThis is patch in v0.54.0-rc.0\n\n### Workarounds\nThis issue can be avoided by using the provisioning to create the datasource and by removing the right to create datasource.",
"id": "GHSA-4227-9989-jrhx",
"modified": "2026-09-18T17:39:48Z",
"published": "2026-09-18T17:39:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/perses/perses/security/advisories/GHSA-4227-9989-jrhx"
},
{
"type": "WEB",
"url": "https://github.com/perses/perses/commit/2368c9ef4eb0a70fbca5df69aa20e595821ab625"
},
{
"type": "PACKAGE",
"url": "https://github.com/perses/perses"
},
{
"type": "WEB",
"url": "https://github.com/perses/perses/releases/tag/v0.54.0-rc.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Perses\u0027s missing authorization in datasource proxy allows cross-scope secret disclosure"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.