CVE-2026-53577

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 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.