Kestra vulnerabilities

In Kestra before versions 1.0.45 and 1.3.21, the REST API authentication filter bypasses credential checks for requests ending in '/configs'. An unauthenticated attacker can exploit this to create flows with Shell or Process tasks that execute as root inside the container, and via the mounted /var/run/docker.sock gain access to the host Docker daemon.

In Kestra OSS prior to versions 1.0.45 and 1.3.21, the AuthenticationFilter uses request.getPath().endsWith("/configs") to whitelist the public configuration endpoint from Basic Auth. Because the check is a suffix match rather than an exact path match, any API path whose last segment is configs bypasses authentication entirely. An unauthenticated remote attacker can exploit this to create and execute arbitrary workflows without credentials.

Kestra version 1.3.3 and earlier is vulnerable to SQL injection. The vulnerability occurs because user-controlled input from a GET parameter is directly concatenated into an SQL query without proper sanitization or parameterization.

Kestra prior to version 1.3.7 contains a SQL injection vulnerability in the GET /api/v1/main/flows/search endpoint, allowing an authenticated attacker to achieve remote code execution via PostgreSQL COPY ... TO PROGRAM.

Kestra before version 1.3.24 has a stored XSS vulnerability in its custom Markdown parser. A user with permission to create or update a Flow description can inject JavaScript event-handler attributes via the [[link]] syntax, causing script execution when another user opens the description or information panel.

Kestra before version 2.0.0 passes the user-controlled http() uri argument to URI.create() and the server-side HTTP client without restricting private, loopback, or link-local destinations, allowing an unauthenticated attacker to import and execute a flow that accesses internal services or cloud metadata.

Kestra before version 2.0.0-rc6 serves GET /worker without authentication and serializes the complete live Task object, which can expose commands, environment variables, HTTP headers, connection details, plaintext credentials, and execution identifiers while the main API on port 8080 remains protected. This issue is fixed in 2.0.0-rc6.

A vulnerability in Kestra prior to 2.0.0-rc6 exposes Micronaut management endpoints on port 8081 without authentication even when Basic Auth protects /api/v1/** on port 8080, allowing unauthenticated GET /env requests to disclose resolved configuration and POST /loggers/{name} requests to change runtime log levels.

A vulnerability in the BasicAuth component of Kestra OSS before version 1.3.24 allows an attacker with read access to the PostgreSQL database to recover the administrator password offline due to SHA-512's high computation speed. In Kubernetes deployments, this enables privilege escalation to read the cluster ServiceAccount token and all K8s Secrets.

In Kestra prior to versions 1.0.45 and 1.3.21, the previewFileFromExecution endpoint (GET /api/v1/{tenant}/executions/{executionId}/file/preview) contains an access control bypass that allows any authenticated user to read output files from any other execution within the same tenant, bypassing execution-level and namespace-level isolation.

In Kestra before versions 1.0.45 and 1.3.23, the local internal-storage backend improperly validates user-supplied paths, allowing an attacker to smuggle a traversal sequence using backslashes (..\..\..\) before conversion to forward slashes. An authenticated user with the lowest privilege can read any file on the server filesystem, including the H2 database, stored secrets, and credentials.

In Kestra before versions 1.0.43 and 1.3.19, several API endpoints accept a kestra:// URI from the client and pass it through StorageInterface.parentTraversalGuard before reading the underlying file from the local storage backend. The guard only inspects the literal URI.toString(), so a URL-encoded .. written as %2E%2E slips through. The downstream code then calls URI.getPath(), which decodes %2E%2E back to .., and the resulting path is handed to Paths.get(...) without normalization. The OS resolves the .. segments at open(2) time, so an authenticated user with a single execution can read any file the Kestra process has access to on the host filesystem (/etc/passwd, mounted secrets, other tenants' execution outputs, etc.).

Kestra is an event-driven orchestration platform that, prior to versions 1.3.19, 1.2.19, 1.1.19, and 1.0.43, had an issue with the `inputFiles` task. This allowed file names to be written directly in the task working directory, potentially leading to overwriting files outside of that directory.