Attackers Exploit Kestra Login Bypass That Reaches Root

Attackers are exploiting a Kestra OSS authentication bypass that lets an unauthenticated network user create a workflow and run commands as root inside a worker container. The September 2 CISA entry for CVE-2026-49869 marks the flaw as known exploited and sets a September 5 federal remediation deadline, which has now passed.

Affected systems run Kestra OSS through 1.3.20 with Basic Auth enabled and micronaut.security.enabled=false, the project’s default OSS authentication mode. Internet exposure is unnecessary: Kestra’s security advisory says any attacker who can reach the service on port 8080 or 32776 can use the path. Neither Kestra nor CISA identifies victims, attackers, attack volume, or the actions taken in observed intrusions.

One suffix skips authentication

Vasco0x4 reported the flaw in Kestra’s AuthenticationFilter. The filter was intended to leave the public configuration endpoint accessible without Basic Auth, but it tested every request path with request.getPath().endsWith("/configs"). That suffix comparison admitted far more than the intended configuration routes.

Any API route whose last segment was literally configs could enter the unauthenticated path. Kestra’s advisory lists affected operations that create or overwrite flows, start executions, write key-value secrets, delete flows and dashboards, and destroy logs. The route still has to end in configs, yet an attacker can create a flow with that name and then execute it.

The project states the result directly: “An unauthenticated remote attacker can exploit this to create and execute arbitrary workflows without credentials.” The authentication failure is the first step. Kestra’s installed workflow capabilities supply the code-execution step.

Default plugins execute as root

Kestra ships with script execution plugins enabled in a default installation. The demonstrated chain first creates a flow named configs, then starts that flow through a second unauthenticated route. The worker launches the task in a Docker container and executes the supplied commands as uid=0(root).

The advisory tested the chain against Kestra OSS 1.3.20, commit 945f162. Its captured output included the uid=0(root) result and command output returned through Kestra’s execution logs. Confirmed task types included io.kestra.plugin.scripts.shell.Commands, io.kestra.plugin.scripts.python.Script, io.kestra.plugin.scripts.node.Commands, and io.kestra.core.tasks.scripts.Bash.

The same bypass exposes a secondary server-side request-forgery path through Kestra’s template http() function. In the research environment, the worker could reach the internal service at 127.0.0.1:8080 and the cloud metadata address 169.254.169.254. That makes internal APIs and cloud credentials possible consequences where the deployment grants that reach.

The demonstrated root privilege stays inside the worker container. The tested container lacked CAP_SYS_ADMIN and did not mount /var/run/docker.sock; the researcher did not confirm a direct Docker-host escape. CISA records ransomware use as unknown.

Figure details

A request ending in the path segment configs reaches Kestra's suffix-based public-route check and skips Basic Auth. From that bypass, the evidence branches into three demonstrated capabilities: create and execute a workflow whose default script plugin runs as root inside the worker container; use the template HTTP function to reach internal services and cloud metadata; or modify and delete Kestra resources named configs, including flows, key-value entries, dashboards, and logs. The figure ends at the worker-container boundary because the researcher did not confirm a Docker-host escape.

Which Kestra systems are exposed

Start exposure scoping with deployment mode, authentication state, version, and network reachability. An instance is within the advisory’s stated scope when it runs an affected Kestra OSS version with Basic Auth enabled and accepts connections from an untrusted or potentially compromised network segment.

Public internet access raises risk, but an internal-only address does not remove the path. A compromised workstation, service account, adjacent workload, or third-party network connection can provide the service reach the exploit needs. Map access to 8080 and 32776 from user networks, workload networks, administrative segments, VPN address pools, and peered environments.

The public record supplies no request signature, source address, hostname, file hash, or CVE-specific log marker. It also provides no reliable retrospective test for earlier exploitation. Version and reachability establish exposure; they do not establish whether an attacker created a flow, ran a task, reached metadata, changed secrets, or deleted logs.

Preserve Kestra flow, execution, key-value, dashboard, and log history before upgrade work changes the system. Review the period of exposure for resources named configs, unexplained script tasks, executions without an approved operator, access to metadata or internal-only services, and gaps in logs or deleted objects. These are consequence-focused investigation questions derived from the demonstrated operations. They are not published signatures for CVE-2026-49869.

Updates fix the login bypass

Kestra lists 1.0.45 and 1.3.21 as patched releases. Operators on the 1.0 line need 1.0.45 or later; operators on the 1.3 line need 1.3.21 or later. A current supported release above the applicable floor is preferable to remaining on the first fixed build.

CISA’s entry requires covered federal organizations to apply vendor mitigation, complete the applicable BOD 26-04 forensic triage, or discontinue use if mitigation is unavailable. The September 5 deadline means any covered vulnerable deployment still serving traffic is overdue. Other organizations should use the KEV listing’s confirmation of exploitation to prioritize patching.

Network restriction can reduce immediate reach while the upgrade is staged. It does not change the vulnerable suffix comparison in an affected build. Limit the service to the smallest approved administrative and workload paths, then verify the running application version after restart.

Test the worker’s access restrictions

Collect the running Kestra version and confirm every OSS instance reports 1.0.45, 1.3.21, or a later supported release on its branch. Recheck network paths to ports 8080 and 32776, and confirm that only approved systems can reach them. Preserve and reconcile flows, executions, key-value changes, dashboards, and log retention across the exposure window.

A fixed running version confirms that the deployed service no longer has the published suffix bypass. It cannot clear earlier compromise. That second question remains open until deployment-specific history accounts for unexplained configs resources and script executions, or Kestra or CISA publishes reliable indicators that support a narrower test.

This flaw turns a permissive string comparison into authority over an orchestration worker. Recovery requires removing the vulnerable code from every reachable instance and investigating whether the workflow system performed unauthorized actions.