Kestra-io Kestra OSS authentication bypass enables unauthenticated remote code execution

Kestra is an open-source, event-driven orchestration platform. Prior to 1.0.45 and 1.3.21, AuthenticationFilter in Kestra OSS 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. Because Kestra ships with script execution plugins (plugin-script-shell, plugin-script-python, etc.) enabled by default, this directly results in unauthenticated Remote Code Execution as root inside the Kestra worker container. This vulnerability is fixed in 1.0.45 and 1.3.21.

• Kestra OSS versions before 1.0.45 are identified as affected.
• Kestra OSS versions from 1.1.0 through before 1.3.21 are identified as affected.
• The vendor advisory identifies 1.0.45 as the fix for the 1.0 branch and 1.3.21 as the fix for the 1.3 branch.
• Do not infer safety for branches or releases that are not listed in the structured facts and advisory.

The flaw is in Kestra OSS AuthenticationFilter. The filter intended to exempt only public configuration endpoints from authentication, but it uses request.getPath().endsWith("/configs") instead of an exact path comparison. As a result, any API path whose final segment is configs can bypass Basic Auth, including routes for creating or overwriting flows, triggering executions, writing KV data, deleting flows, deleting dashboards, and deleting audit logs. The attacker controls resource identifiers in these paths and can therefore create a flow named configs and execute it without credentials. Script execution plugins such as plugin-script-shell and plugin-script-python are installed by default, so this chain can result in arbitrary command execution with UID 0 inside the Kestra worker container. The advisory also describes SSRF through Pebble's http() function when combined with the authentication bypass. Direct escape from the container to the Docker host was not confirmed; the advisory states that the worker container lacks CAP_SYS_ADMIN and does not mount /var/run/docker.sock.

The vulnerability is remotely reachable over the network through the Kestra HTTP service when the instance runs an affected version and the attacker can connect to the service. Authentication and user interaction are not required; the record also identifies low attack complexity. The record marks the issue as known exploited and having a public exploit, and the vendor advisory provides a PoC for the authentication bypass, flow creation, and flow execution chain. The bypass is limited to paths whose final segment is literally configs, but that limitation does not prevent exploitation because an attacker can create a flow with that name. The supplied evidence does not identify a specific campaign, victim, or breach.

The flaw removes the intended Basic Auth protection from routes whose final path segment is configs. The direct result can be unauthorized creation, modification, execution, or deletion of resources, and workflows containing script tasks may execute commands as root inside the worker container. Pebble's http() function may also be used to send requests to internal services or cloud metadata endpoints, creating a risk of data or credential exposure that depends on network access and deployment permissions. Consequences include loss of confidentiality, loss of integrity, workload disruption, and reduced auditability. The confirmed scope is the worker container; the evidence does not confirm direct host escape or complete server control.

• Workload control: An attacker can create or execute unauthorized workflows, altering orchestration activity and consuming worker resources.
• Data exposure: Script execution can access data available to the worker container. SSRF may also reach internal services or cloud metadata endpoints; cloud credential exposure depends on the deployment environment and credential permissions.
• Data and configuration integrity: Flows, KV entries, dashboards, and other resources whose final path segment is configs may be created, changed, or deleted through affected routes.
• Availability and investigation: Malicious workflows can consume worker capacity, while log deletion can reduce the ability to investigate the incident.
• Scope limit: The advisory confirms root-level execution inside the worker container but does not confirm direct escape to the Docker host.

1. Upgrade by release branch: For the 1.0 branch, upgrade to 1.0.45. For the 1.3 branch, upgrade to 1.3.21. A fix in one branch does not establish that every other branch is fixed.
2. Reduce exposure while patching: Restrict network access to Kestra service ports, including the 8080 and 32776 ports identified by the advisory, to trusted administrative or workload sources. This is containment, not a confirmed fix.
3. Investigate before restoration: Review flows, executions, KV data, dashboards, and logs for unauthorized activity through paths ending in configs. If script execution or SSRF activity is found, consider isolating and rebuilding worker containers from trusted images.
4. Handle potentially exposed credentials: If the worker could reach secrets, internal services, or cloud metadata and evidence indicates access, rotate the related credentials after containment.
5. Validate after the change: Recheck inventory, access control, and logs to confirm that each instance is running the correct fixed release for its branch.

1. Inventory Kestra OSS instances and determine the version for each release branch. Prioritize instances before 1.0.45 or in the range >= 1.1.0, < 1.3.21.
2. Review HTTP access logs for unauthenticated requests to paths ending in /configs, especially PUT, POST, or DELETE requests involving flows, executions, KV data, dashboards, and logs. These are suspicious indicators, not conclusive proof of exploitation.
3. Inspect flow and execution records for a flow named configs, script tasks such as io.kestra.plugin.scripts.shell.Commands or io.kestra.plugin.scripts.python.Script, and executions that do not match authorized administrative activity.
4. Review unexpected changes to KV entries, dashboards, templates, and audit logs, particularly resources whose identifier ends in configs.
5. Review worker and container telemetry for unexpected containers, commands, or outbound connections, including connections to internal services or cloud metadata endpoints. The available evidence does not establish a specific IOC, and the absence of matching logs does not prove that an instance is safe.