A CVSS 10 flaw turns Kestra into an unauthenticated root shell
On September 2, 2026, CISA added CVE-2026-49869 to its KEV catalog: a CVSS 10 command injection in the open-source orchestrator Kestra, caused by a path comparison that lets any endpoint ending in ’configs’ through. Move to 1.0.45 or 1.3.21 before the September 5 federal deadline, then check whether the instance was already used as an entry point.
September 2, 2026. CISA adds seven vulnerabilities to the KEV catalog, including CVE-2026-49869, a CVSS 10.0 command injection in Kestra. September 5, 2026. The federal deadline set by BOD 26-04 — three days to patch. June 26, 2026. The flaw had already been documented in a GitHub security advisory — it took two months to reach the agencies’ radar. Why it matters: a single suffix comparison lets any path ending in “configs” through, and Kestra ships shell and Python execution plugins enabled by default. The result is a root shell inside the worker container, no credentials required.
A suffix comparison that opens the whole API
The root cause fits on one line. In Kestra OSS, the AuthenticationFilter class whitelists the public configuration endpoint by testing request.getPath().endsWith("/configs"). The check is not an exact path match but a suffix match: any API path whose last segment is “configs” bypasses Basic Auth, no matter what precedes it.
The consequence is immediate. An unauthenticated attacker can create and then run arbitrary workflows with no credentials at all. The GitHub advisory is blunt: the flaw “directly results in unauthenticated Remote Code Execution as root inside the Kestra worker container.” The associated CWEs confirm the nature of the defect — CWE-287 (improper authentication), CWE-78 (OS command injection), plus CWE-184 and CWE-918. The CVSS 3.1 score is at the ceiling, 10.0, with a vector that leaves no room for debate: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Network, low complexity, no privileges, no interaction, changed scope, full impact on confidentiality, integrity and availability.
The fix is already published, in Kestra 1.0.45 and 1.3.21. Every earlier version on either branch is affected.
An orchestrator, so code execution by default
What turns an authentication error into root RCE is the nature of the tool itself. Kestra is an event-driven orchestration platform: its entire job is to trigger tasks, including script execution. And it ships the plugin-script-shell and plugin-script-python execution plugins enabled by default, alongside Docker and Kubernetes runners.
In other words, there is no second vulnerability needed to turn access into code execution. Bypassing authentication is enough: the attacker submits a workflow that invokes the shell plugin, and the code runs with the worker process’s privileges — root in a typical containerized deployment. That is exactly what CISA summarizes in the KEV entry: “an unauthenticated remote attacker can create and execute arbitrary workflows without credentials.”
The lesson goes beyond Kestra. Any self-hosted orchestrator — Airflow, Prefect, Temporal, n8n — concentrates a distinct attack surface: once the API is breached, code execution is part of the product contract. An authentication flaw there always costs more than it would elsewhere.
A late KEV entry, in the middle of a batch of seven
CVE-2026-49869 did not enter the KEV catalog alone. On September 2, 2026, CISA added seven vulnerabilities, all on evidence of active exploitation. Three of them had already been covered by ETTAYEB: CVE-2026-82329 in JFrog Artifactory, and the two SonicWall SMA1000 flaws CVE-2026-83548 and CVE-2026-83549 (SSRF and OS command injection). Three others are new to the catalog: CVE-2026-9586 (SQL injection in Sangoma Switchvox), CVE-2026-48710 (HTTP request smuggling in Starlette) and CVE-2026-59822 (improper authentication in BerriAI LiteLLM).
The batch says two things. First, the pace is accelerating: CISA is now bundling exploited vulnerabilities that hit infrastructure products, web frameworks and AI building blocks like LiteLLM at the same time. Second, the gap between technical disclosure and KEV listing remains a real problem: Kestra had shipped its fix in late June, and the federal deadline only landed in early September. For two months, exposed instances remained patchable but unflagged as priorities.
Patch in three days, then investigate
The September 5, 2026 deadline leaves little margin, and BOD 26-04 does not stop at patching. It also requires checking whether the asset was compromised before the fix was applied. For an exposed Kestra instance, that means hunting for unknown workflows, anomalous executions in the history and outbound connections from the worker to external addresses.
# Patch a containerized instance: pin a fixed version
docker pull kestra/kestra:1.0.45 # 1.0 branch
docker pull kestra/kestra:1.3.21 # 1.3 branchThe first action is still the simplest: identify the running version, then bring it up to 1.0.45 or 1.3.21. For a non-containerized deployment, update the JVM artifact and restart the workers. In parallel, review the workflows and stored secrets — an attacker who already ran code inside the worker may have read the credentials injected into tasks.
Beyond the fix, the deeper question is exposure. An orchestrator has no business being reachable from the internet. Putting it behind a VPN or an internal mesh, and disabling the script execution plugins where they are not used, shrinks the value of the next authentication flaw.
A rising class of targets
The Kestra case is not isolated. In August, Langflow — another self-hosted orchestration platform, this one oriented toward AI flows — was hit by CVE-2026-0768, an RCE that let attackers steal API keys; we covered it at the time. The pattern repeats: these tools install in a few commands, expose a port, and concentrate infrastructure secrets. Their value to an attacker is double — an initial foothold, and credentials to pivot into the rest of the network.
The consequence for teams is structural. An orchestrator is not hardened once and for all: it is watched continuously. Inventory the deployed instances, minimize exposure, rotate secrets, and update within hours of a vendor advisory. In this case the fix had been available since late June — what was missing for two months was visibility, not technique.
The bypass, step by step
To size up the flaw, just walk the scenario. The attacker targets an exposed Kestra instance, then calls an API path ending in “configs” — say a workflow-management route whose last segment has been forged to match the suffix. The authentication filter, which only compares the tail of the path, lets it through with no credentials. Once inside, the attacker submits a workflow that invokes the shell plugin, and the worker process runs the command as root.
The takeaway for a defender is not the payload detail but the design lesson: a suffix whitelist is not a whitelist. Any path comparison built on endsWith or startsWith without normalizing the full path is a bypass waiting to happen. It is exactly the kind of defect that code reviews and API scanners should hunt first.
Verdict
If you run Kestra, patch to 1.0.45 or 1.3.21 right now: the federal deadline of September 5, 2026 is a day away, and an exposed instance is a free root shell. Apply the forensic side of BOD 26-04 too — check the workflow history before you call the incident closed.
If you host another orchestrator, treat this as a reminder: the authentication flaw costs more here, because code execution is part of the product. Cut network exposure and audit which execution plugins are enabled.
In every case, do not measure your exposure against the KEV catalog alone: Kestra published its fix in late June, and CISA only listed it two months later. Watching vendor advisories still beats the agencies’ calendar.