GHSA-vr5f-w35q-98jp: Path Traversal
Impact When Perses is using the file system database, on the list endpoints, the project value is bound from the request into the resource Query struct and is never validated against directory-traversal characters (validation/Flatten only runs for Create/Update bodies, not list queries).
The path is then used to retrieve files in the database directly.
Attacker can read arbitrary YAML/JSON files from the server host and can bypass the security constraints to get access to other resources contained in the file database.
For example https://localhost:8080/api/v1/dashboards?project=../projects returns the list of the project while it must not return anything.
Patches Has the problem been patched? What versions should users upgrade to?
Workarounds Avoid using the file system database in production. Use SQL database instead.
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 - Configuration
Avoid using the file system database in production; use the SQL database instead.
Perses file system database usage = disabled - Compensating control
If Perses is deployed with file system database, mitigate directory traversal exposure by not exposing list endpoints that accept the project parameter (e.g., /api/v1/dashboards?project=../projects) to untrusted clients; ensure access to these endpoints is restricted.
Event History
Frequently Asked Questions
Which deployments are exposed?
Perses deployments using the file system database are exposed through list endpoints that accept a project value. The described workaround indicates that using an SQL database instead avoids this condition.
What does an attacker need to exploit this issue?
An attacker needs to send a request to a list endpoint with a project query value containing directory-traversal characters, such as ../projects. The vulnerable query value is used directly to retrieve files without validation.
What can an attacker access?
An attacker can read arbitrary YAML or JSON files from the server host and bypass intended security constraints to access other resources stored in the file database. The example shows a dashboard list request returning resources from another project.
What can be done if patching is not immediately possible?
Avoid using the file system database in production and use an SQL database instead.