Kestra: Unauthenticated Remote Code Execution via Authentication Bypass in `AuthenticationFilter`
Only Kestra OSS instances with Basic Auth enabled are exposed, and Kestra ships script execution plugins installed by default. The vendor gives no separate rating. Fixed in 1.0.45 and 1.3.21.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Actively exploited
- Fix
- Fixed in 1.0.45, 1.3.21
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Kestra, an open-source workflow orchestration platform, is affected, and an unauthenticated attacker could abuse a flaw in its authentication filter to run arbitrary commands as root on the worker container. This could let them create and execute workflows without credentials, potentially giving them full control over the affected system.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Timeline
- CVE published
- Added to CISA KEV
CISA has evidence of exploitation in the wild
- Record last updated
- CISA remediation deadline
Due date for US federal agencies to patch
Affected versions
- kestra-io kestra
fixed in 1.0.45; From 1.1.0 · fixed in 1.3.21
References 1
GitHub · kestra-io/kestra
Questions about CVE-2026-49869
What does this mean?
The authentication filter fails to block unauthenticated requests, so an outside user can run code as root inside the Kestra worker Docker container. From there, the attacker can read and change flows, KV entries and logs, and reach internal services through SSRF.Source: github.com
Am I affected, and how do I check?
Kestra OSS instances with Basic Auth enabled are affected in versions before 1.0.45, and in versions from 1.1.0 up to but not including 1.3.21. To check, run the version command or look at the version in your deployment, and check whether Basic Auth is enabled in the server configuration.Source: github.com
What should I do about it?
Upgrade to 1.0.45 if you run the 1.0.x line, or to 1.3.21 if you run 1.1.0 or later. No workaround is listed in the facts.Source: github.com
Is it being exploited?
Yes. CISA added it to its Known Exploited Vulnerabilities catalog on 2026-09-02, which means it has evidence of attacks. No public exploit code is tracked.Source: cisa.gov, cve.now feed data