Kestra's internal storage backend validates paths for '..' traversal only before converting Windows‑style backslashes to forward slashes. An attacker can thus embed a traversal sequence such as '..\\..\\..', which passes the guard and is rewritten to '../../../' before the file is opened, allowing an authenticated user to read any server file accessible to the Kestra process. This violation of storage isolation lets any user with the lowest‑privilege view‑execution role download arbitrary files, including the embedded H2 database, secrets, and process environment variables.

Kestra, published by kestra-io, is vulnerable in all releases before 1.0.45 and 1.3.23. version lower than these numbers uses the built‑in local internal‑storage backend and therefore is affected regardless of tenant or namespace configuration. No operating‑system restrictions are specified, so any Kestra installation using the default backend can be impacted.

The CVSS score of 7.7 signals a high‑severity confidentiality issue, but the EPSS score is not available and the vulnerability is not listed in CISA's KEV catalog. The exploit requires only an authenticated user with the view‑execution role, a privilege level that many users possess; once exploited, attackers can read sensitive configuration, database, and secret files across all tenants, constituting a full breach of Kestra's multi‑tenant isolation.