· via dev.to (home feed)
Critical Kestra OSS auth bypass CVE-2026-49869 enables unauthenticated RCE and is actively exploited
Attackers are exploiting CVE-2026-49869, a CVSS 10.0 authentication bypass in Kestra OSS that escalates to unauthenticated remote code execution. Fixed releases are 1.0.45 and 1.3.21.

Authentication bypass in Kestra OSS is being exploited in the wild
A vulnerability tracked as CVE-2026-49869 lets an unauthenticated attacker bypass authentication in the open-source workflow orchestrator Kestra OSS and achieve remote code execution. According to a dev.to analysis of the flaw, it carries the maximum CVSS 3.1 score of 10.0, and CISA added it to its Known Exploited Vulnerabilities catalog on 2026-09-02 — a signal that attacks are already happening.
How the bypass works
The root cause is a suffix check in Kestra's AuthenticationFilter. Requests whose path ended in /configs were exempted from Basic Authentication, an allowance intended for a public configuration endpoint. The problem, as dev.to explains, is that "configs" can also appear as a caller-controlled resource identifier in other API routes, which meant protected endpoints could be reached without any credentials.
Turning the bypass into code execution requires no second bug. Kestra ships script-execution plugins by default, so an anonymous caller who can create a workflow and trigger it gets the platform to run commands inside the worker. The platform's own execution feature becomes the attacker's tool.
Patched versions
Per the CVE data cited by dev.to, affected releases are Kestra OSS below 1.0.45 and versions from 1.1.0 up to but not including 1.3.21 — in other words, everything up to and including 1.3.20. Fixed releases are 1.0.45 and 1.3.21. The vendor's fix normalizes the request path and matches the public configuration endpoint exactly as /api/v1/configs, and adds regression tests verifying that other paths ending in /configs now return 401 Unauthorized. The GitHub security advisory is GHSA-5vc5-wxxq-3fjx.
Internet exposure, measured with caveats
To gauge how many orchestrators are reachable, the dev.to author ran ZoomEye queries on 2026-09-16:
- app="Kestra" matched 119 assets
- title="Kestra" matched 231 assets
- app="Kestra OSS" matched 0, indicating an invalid product fingerprint in the index rather than an absence of deployments
- vul.cve="CVE-2026-49869" matched 0, reflecting CVE indexing lag rather than evidence of patching
The two positive queries overlap and should not be summed, and neither count reveals which version an instance runs, whether it is reachable beyond the scanned port, whether an upstream authentication layer would stop the bypass, or whether it has already been accessed. A public fingerprint proves the product is present; only the owner can confirm the version and configuration.
Recommended operator steps
The analysis lays out a response sequence:
- Cross-check public fingerprints against your own inventory — orchestrators are often deployed by platform or data teams and may be missing from the central asset register.
- Identify instances reachable from untrusted networks, including internal ones, since an attacker already inside an office, development, or cluster network can reach deployments that are not internet-facing.
- Upgrade to 1.0.45, 1.3.21, or a later supported release.
- Until the upgrade lands, restrict the Kestra API at the network layer to trusted administrative entry points and enforce authentication at an upstream proxy instead of relying on the application filter.
- Investigate rather than only scan: look for unexpected flows, unfamiliar executions, key-value changes, deleted logs, and script tasks from unknown sources. If the worker could reach cloud metadata endpoints, database credentials, or internal APIs, include credential rotation in the response.
The analysis also cautions against overstating blast radius: root inside the worker container is not automatically root on the host, since container escape depends on mounts, capabilities, exposed sockets, service accounts, and runtime configuration. CISA's confirmation of exploitation does not mean every internet-facing instance was compromised.
Why it matters
A workflow orchestrator is not a passive web application. Kestra's documented role includes defining and scheduling workflows, running shell, Python, and Node.js tasks, connecting to databases, cloud services, message systems, and internal APIs, and storing flow configuration, variables, and run logs. An authentication bypass in such a system yields code execution plus access to the surrounding infrastructure, not mere information disclosure. The exposed population is small — roughly one to two hundred fingerprinted instances — which suggests Kestra typically sits on internal networks behind access controls, where it belongs. With active exploitation confirmed and the flaw in the KEV catalog, patching is time-sensitive, and the exposure count is a prompt to verify your own configuration, not a substitute for it.
- #kestra
- #security
- #cve
- #workflow-orchestration
- #cisa