CVE-2026-45807: Kestra Path Traversal Vulnerability (v1.0.43, v1.3.19 Patch)

Technical summary

The vulnerability stems from a validation bypass in Kestra's URI path handling. API endpoints accept kestra:// URIs and pass them through StorageInterface.parentTraversalGuard, which validates only the literal URI.toString() representation. URL-encoded traversal sequences (%2E%2E for ..) are not detected at this guard stage. Downstream code calls URI.getPath(), which automatically URL-decodes the string, converting %2E%2E to ... The decoded path is then passed to Paths.get() without normalization, allowing the OS kernel to resolve .. segments during file open operations. This results in arbitrary file read access within the Kestra process's privilege boundary. The root cause is the semantic gap between the guard's string-level inspection and the URI decoder's automatic decoding, combined with the absence of path canonicalization before filesystem operations.

Business impact

For organizations running Kestra in production, this vulnerability exposes a critical data-leakage channel. Any authenticated user—including low-privilege automation accounts or compromised credentials—can extract sensitive information: configuration files, database credentials, API keys stored in execution environments, and outputs from other tenant workflows if multi-tenancy is enabled. In compliance-heavy industries (finance, healthcare, PII processing), unauthorized data access triggers breach notification obligations and regulatory penalties. The impact is heightened in containerized or cloud deployments where Kestra may have access to mounted secrets or Kubernetes service account tokens. Remediation delay increases risk of insider threats and lateral movement via stolen credentials.

Affected systems

Kestra versions prior to 1.0.43 (stable series) and prior to 1.3.19 (latest series) are affected. The vulnerability applies to any Kestra deployment where users have API access—whether self-hosted, containerized, or managed. Air-gapped environments are not exempt; internal threat actors or compromised service accounts remain viable attack vectors. Multi-tenant deployments face cross-tenant data leakage risk.

Exploitability

Exploitation is straightforward once an attacker has valid credentials. No special tools or network positioning are required; a simple HTTP request with a URL-encoded path traversal sequence in the URI parameter is sufficient. The attack is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog as of the advisory date, but the simplicity of the technique and public disclosure mean weaponization is probable if exploitation is not already occurring. The requirement for authentication raises the bar slightly—insiders, compromised service accounts, or users granted unintended Kestra access become the primary threat actors. Automated scanners can detect vulnerable versions, making discovery of exposed instances trivial.

Remediation

Upgrade Kestra to version 1.0.43 or later for the stable 1.0.x branch, or to version 1.3.19 or later for the 1.3.x branch. Verify the patched version is deployed and restarted. As an interim control, restrict API access via network policies or reverse-proxy authentication to trusted sources only, and audit execution logs for suspicious API calls containing encoded path sequences (look for %2E%2E or similar encodings in kestra:// URIs). Review file system permissions to minimize the data accessible to the Kestra process user.

Patch guidance

Consult the official Kestra release notes for versions 1.0.43 and 1.3.19 to confirm fix inclusion and any breaking changes. Test the patch in a non-production environment first, particularly if you are running custom extensions or relying on specific API behavior. Rolling updates with no downtime are typically supported; monitor service health after deployment. If you are on a version older than 1.0.43 or 1.3.19, do not skip intermediate versions without reviewing changelogs for deprecations or migrations.

Detection guidance

Monitor API logs for requests to file-reading endpoints (/api/v1/files, /api/v1/executions/{id}/files, or similar) containing URI parameters with %2E%2E, %2e%2e, or double-encoded variants. Flag requests accessing paths outside expected workflow directories, particularly those containing ../ in the decoded path. Network-based detection should look for suspicious kestra:// URIs in API payloads. Endpoint detection and response (EDR) tools can monitor file open operations initiated by the Kestra process targeting unexpected paths like /etc or credential storage locations. Baseline normal file access patterns to detect anomalies.

Why prioritize this

This vulnerability merits immediate patching due to its HIGH CVSS score (7.7), ease of exploitation, and direct impact on data confidentiality. Although authentication is required, the low technical complexity and the likelihood that legitimate users have API access make this a credible insider threat. The absence from the KEV catalog does not indicate low risk; it reflects recent disclosure. In multi-tenant or sensitive-data environments, prioritize patching within days, not weeks.

Risk score, explained

The CVSS 3.1 score of 7.7 (HIGH) reflects a network-accessible API (AV:N) with low attack complexity (AC:L), requiring low privilege (PR:L, authenticated user), and no user interaction (UI:N). The scope is changed (S:C), meaning the impact affects resources beyond the vulnerable component. Confidentiality is high (C:H) because arbitrary files accessible to the process can be read; integrity and availability are not impacted (I:N/A:N). The score appropriately captures the risk of authenticated data exfiltration but does not account for exploit maturity, deployment context, or business sensitivity—factors that may elevate risk for your organization.

Frequently asked questions