Kestra, the open-source event-driven orchestration platform used for data pipelines, ETL, and CI/CD scheduling, has a second critical vulnerability disclosed this year — and this one requires no credentials at all. CVE-2026-49869, carrying the maximum CVSS score of 10.0, is an authentication-bypass flaw that gives remote, unauthenticated attackers a direct path to root-level remote code execution. CISA added it to the Known Exploited Vulnerabilities catalog on September 2, with a federal remediation deadline of September 5 — today.

This is a distinct bug from CVE-2026-34612, the SQL-injection-to-host-RCE chain disclosed against Kestra in April. That one needed an authenticated session and a Docker Compose PostgreSQL backend. This one needs neither.

What Happened

The flaw lives in Kestra’s AuthenticationFilter, the component responsible for enforcing Basic Auth across the API. To let the public configuration endpoint remain reachable without credentials, the filter whitelists any request whose path satisfies request.getPath().endsWith("/configs").

That’s a suffix match, not an exact-path match. Kestra addresses most of its resources — namespaces, flow IDs, execution paths — through caller-controlled path segments. Because the check only looks at the tail of the URL, an attacker can craft any API path that simply ends in /configs and have it treated as the public, unauthenticated config endpoint, regardless of what the path actually routes to. Basic Auth enforcement is skipped entirely for that request.

From there, the attacker isn’t limited to reading configuration. Kestra ships script-execution plugins — plugin-script-shell, plugin-script-python, and others — enabled by default. With authentication bypassed, an attacker can create and execute an arbitrary Kestra flow with no credentials, and that flow runs inside the Kestra worker container as root. Auth bypass becomes unauthenticated RCE in a single step, with no second vulnerability required to escalate.

Technical Details

  • CVE: CVE-2026-49869
  • CVSS: 10.0 (Critical)
  • CWE: Improper authentication / authorization bypass through path suffix matching
  • Root cause: AuthenticationFilter exempts any request path ending in /configs from Basic Auth via endsWith() rather than an exact match
  • Impact: Unauthenticated flow creation and execution → remote code execution as root in the worker container
  • Affected versions: Kestra OSS prior to 1.0.45 (LTS branch) and prior to 1.3.21
  • Fixed versions: 1.0.45 and 1.3.21
  • Attack vector: Network, no authentication, low complexity
  • Advisory: GHSA-5vc5-wxxq-3fjx

Who’s Affected

Kestra is deployed as an internal orchestration and automation backbone — data pipelines, ETL jobs, CI/CD triggers, infrastructure scheduling — often reachable from internal networks or, in some deployments, directly from the internet. Because the whole point of the product is to run arbitrary user-defined workflows, script execution plugins are enabled by default in most installs, which is exactly the primitive this bug needs.

CISA’s KEV addition confirms active exploitation is already occurring, and public proof-of-concept scanners for the bypass are circulating (a checker script referencing CVE-2026-49869 is already on GitHub), which materially lowers the bar for opportunistic scanning against exposed instances. Any organization running an internet-facing or loosely-segmented Kestra deployment should treat this as an assume-compromise scenario if patching wasn’t already complete before today’s public disclosure and KEV listing made the bug widely known.

What To Do Right Now

  • Patch immediately to Kestra 1.0.45 (LTS) or 1.3.21, whichever branch you’re tracking.
1
2

docker-compose pull
docker-compose up -d
  • Do not rely on network exposure alone as mitigation. The bypass works over the same API surface used for legitimate access; if the API is reachable by anyone who can reach the UI, it’s exploitable.
  • Audit for compromise before assuming the patch is sufficient. Review Kestra execution logs for flows you didn’t create, especially ones invoking shell or script plugins, and check worker container process history for anomalous root-level activity.
  • Restrict network access to the Kestra API to trusted management networks as defense-in-depth, even after patching.
  • Federal agencies: this is a KEV entry with a remediation deadline of September 5, 2026 — verify patch status today.

Broader Implications

This is the second critical Kestra vulnerability disclosed in five months, and both land on the same theme: orchestration platforms that execute arbitrary user-defined code are only as safe as the authentication layer standing in front of them. A single string-matching mistake — endsWith() instead of an exact comparison — collapsed the entire auth boundary for a platform whose core feature is running shell and Python scripts on demand. Any product built around this “run whatever workflow the user defines” model deserves the same scrutiny applied here: verify that path-matching logic in auth filters is exact, not prefix- or suffix-based, and that script-execution capability is never one filter bug away from being handed to an anonymous caller.

References