CVE-2026-63199 in Perses
Summary
by MITRE • 09/18/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified within the Perses open-source observability dashboard and visualization platform represents a critical authorization flaw rooted in improper access control mechanisms during datasource configuration. Specifically, this security defect affects versions ranging from 0.43.0 through 0.54.0-rc.0. The core issue lies in the authentication logic governing the creation of datasources and the handling of unsaved datasource proxy paths. While these operations correctly verify that a caller possesses GlobalDatasource:create permissions or equivalent project-level datasource creation rights, they fail to enforce mandatory read access checks for associated secrets stored at either the global or project scope before resolving them. This architectural oversight creates a significant gap in the principle of least privilege and proper separation of duties within the application's security model.
From a technical perspective, an attacker with low-privilege credentials can exploit this flaw by creating a new datasource configuration that references a secret object they do not have explicit read permissions to access. By pointing this configured datasource toward a malicious service controlled by the attacker, such as a custom HTTP endpoint or proxy server, the Perses application is compelled to process the request using the referenced secret's credentials. Because the system resolves and utilizes these secrets without validating whether the initiating user has permission to view them, it effectively transmits the decrypted secret values in plaintext to the external service controlled by the attacker. This mechanism allows for the exfiltration of sensitive authentication material that should remain isolated within its designated scope boundaries.
The operational impact of this vulnerability is severe, as it enables unauthorized data access and potential compromise of downstream systems relying on these secrets. An adversary can harvest API keys, database passwords, or other critical credentials stored in global or project-scoped secret stores. This breach undermines the integrity of the observability infrastructure by allowing a low-privilege user to escalate their effective privileges indirectly through credential theft rather than direct system modification. Furthermore, it violates the expected isolation between different organizational units or projects within multi-tenant deployments, as secrets intended for specific contexts can be leaked across scope boundaries due to this logic error in datasource resolution.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically regarding the failure to enforce proper access control checks before performing sensitive operations involving protected resources. It also correlates with ATT&CK technique T1530, Data from Information Repositories, as it facilitates the exfiltration of data stored in external repositories or secret management systems through legitimate application functionality abused for malicious purposes. The flaw highlights a common pitfall where authorization is checked at one stage but not consistently applied during subsequent resource resolution steps involving sensitive payloads like cryptographic keys and passwords.
To mitigate this risk, organizations running affected versions must upgrade to Perses version 0.54.0-rc.0 or later, which includes the necessary patches to enforce read permission checks on associated secrets before they are resolved and utilized by datasources. In environments where immediate upgrading is not feasible, administrators should implement strict network segmentation to limit outbound connections from the Perses application server, ensuring that it cannot communicate with unauthorized external endpoints. Additionally, rotating any credentials stored in global or project-scoped secret stores that may have been exposed during this window of vulnerability is essential to maintain security posture. Regular audits of datasource configurations and user permissions can also help identify potential misconfigurations that might exacerbate similar issues in the future.