CVE-2026-49984: Kestra Path Traversal Allows Arbitrary File Read Across Tenants

Technical summary

The vulnerability is a directory traversal flaw in Kestra's local internal-storage backend affecting versions prior to 1.0.45 and 1.3.23. The root cause is a validation-order issue: the platform sanitizes paths for .. sequences before normalizing Windows backslashes to forward slashes. An attacker crafts a path using backslash notation (e.g., ..\..\..\) which passes the guard as a 'harmless string' (backslashes are not recognized as traversal syntax during validation), but is later converted to ../../../ immediately before file access. This allows reading arbitrary files accessible to the Kestra process, bypassing multi-tenancy and namespace isolation. Affected file classes include the embedded H2 database (containing all workflows, user data, and encrypted secrets), filesystem storage of other tenants, mounted secret files, and the process environment file. The vulnerability is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory), CWE-180 (Incorrect Behavior of Source-Code Preprocessor), and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).

Business impact

This vulnerability represents a critical breach of Kestra's core security model. For multi-tenant deployments, it allows complete cross-tenant data exfiltration: an attacker in one tenant can read flows, schedules, and secrets belonging to all other tenants. For single-tenant installations, all sensitive data—including plaintext or weakly encrypted credentials, API keys, and database passwords stored in the environment—becomes accessible to any user with execution-view permissions, a role typically granted to operators and developers. The compromise of database credentials and secret-backend tokens enables further lateral movement and persistence. Organizations relying on Kestra's isolation guarantees for regulatory compliance or multi-team security boundaries face immediate risk of data breaches and credential theft.

Affected systems

Kestra versions prior to 1.0.45 and 1.3.23 are affected. The vulnerability applies to deployments using the local internal-storage backend (the default for self-hosted Kestra). Impact depends on deployment architecture: multi-tenant Kestra instances suffer complete isolation failure, while single-tenant instances expose all files readable by the Kestra process user (typically a service account with broad filesystem access). Cloud-hosted or managed Kestra services should be assessed for tenant isolation by the vendor.

Exploitability

Exploitability is straightforward. The vulnerability requires only authenticated access at the lowest privilege level (execution-viewer role) and a simple HTTP GET request with a crafted path parameter. No special tooling or network position is required; the attack works over standard REST APIs. The barrier to exploitation is low because execution-viewer access is commonly granted to development and operations teams. No user interaction or race conditions are involved; the attack is deterministic and repeatable.

Remediation

Upgrade immediately to version 1.0.45 (for 1.0.x series) or 1.3.23 (for 1.3.x series) or later. These versions fix the validation-order bug by sanitizing paths after converting backslash notation to forward slashes. Vendors should consult the official Kestra release notes to verify the exact patched versions for their deployment. In the interim, apply compensating controls: restrict the local filesystem permissions of the Kestra process user to only required directories; limit execution-viewer role assignment to trusted administrators; and monitor API access logs for suspicious /api/v1/*/executions/*/file requests with path parameters containing backslashes or ../ sequences.

Patch guidance

Kestra has released fixes in 1.0.45 and 1.3.23. Organizations should upgrade to the earliest available patched version within their current release series. Verify patch application by confirming the version number in the Kestra admin interface or API response headers. Test in a non-production environment first to ensure compatibility with custom flows or integrations. If a gap exists between your current version and the patched version, prioritize this as an emergency update due to the high severity and low exploitation barrier.

Detection guidance

Monitor Kestra API logs for GET requests to /api/v1/{tenant}/executions/{executionId}/file with path parameters containing backslash characters (\) or directory traversal sequences (.. or ..). Alert on any such requests regardless of HTTP status, as successful exploitation may not always return errors. Additionally, audit access logs to identify which users accessed the file-download endpoint and from which source IPs. For runtime detection, monitor the Kestra process for unusual file-open syscalls targeting files outside the configured storage directory. Review Kestra audit logs for role assignments that grant execution-viewer permissions, and correlate unexpected role grants with recent user or API activity.

Why prioritize this

This vulnerability merits immediate patching because it enables unauthenticated access to secrets, credentials, and multi-tenant data with minimal effort and no exploitation complexity. The CVSS score of 7.7 (HIGH) reflects high confidentiality impact and cross-tenant scope, but the actual risk is arguably higher due to the trivial barrier to exploitation and the centrality of the affected file store to Kestra's security model. Any Kestra deployment should be considered compromised if exposed to untrusted users with execution-viewer access prior to patching.

Risk score, explained

The CVSS v3.1 score of 7.7 (HIGH) reflects: network accessibility (AV:N), low complexity to exploit (AC:L), requirement for authentication but at a low privilege level (PR:L), changed scope indicating cross-tenant/sandbox breakout (S:C), high confidentiality impact (C:H), no integrity or availability impact (I:N, A:N). The score accurately captures the severity of data exfiltration but does not fully account for the triviality of exploitation or the scope of sensitive data at risk in typical deployments. Organizations should treat this as functionally critical despite the 'HIGH' rating.

Frequently asked questions