Kestra's local internal-storage backend improperly limits pathnames to a restricted directory due to validating user input for '..' traversal sequences before converting backslashes to forward slashes. This allows an attacker to use Windows-style backslashes (e.g., ..\..\..\) to bypass the traversal check. Consequently, any authenticated user with permission to view executions can call the GET /api/v1/{tenant}/executions/{executionId}/file?path= endpoint to read arbitrary files on the server filesystem accessible by the Kestra process. This includes sensitive files such as the embedded H2 database containing all flows, stored secrets, internal storage of other tenants/namespaces, mounted secret files, and the process environment file with configured credentials. This vulnerability compromises storage isolation and multi-tenancy security. The vulnerability is resolved in Kestra versions 1.0.45 and 1.3.23.

An attacker with authenticated access and minimal privileges can read any file on the Kestra server filesystem that the Kestra process can access, bypassing storage sandboxing and tenant isolation. This includes exposure of all stored flows, user secrets, other tenants' data, mounted secret files, and sensitive environment variables containing credentials. This results in a complete breach of confidentiality and multi-tenancy boundaries within Kestra.

This vulnerability is fixed in Kestra versions 1.0.45 and 1.3.23. Users should upgrade to at least these versions to remediate the issue. No other mitigation or temporary workaround is indicated in the available data.