The short answer
CVE-2026-49869 is a CVSS 10.0 authentication bypass in Kestra OSS that hands an unauthenticated attacker remote code execution as root. A whitelisting check for the public config endpoint uses a suffix match — endsWith("/configs") — so any request path ending in configs skips Basic Auth. From there an attacker can create and run a workflow with shell or Python tasks inside the worker container. CISA added it to the Known Exploited Vulnerabilities catalog on 2 September 2026.
If Kestra sits anywhere in your data pipeline, the fix is to upgrade to 1.3.21 or 1.0.45 now and get any exposed instance off the public internet. Orchestration hosts are high-value targets precisely because they hold the keys to everything they automate, so this belongs in the same tier of urgency as your cloud and DevOps incident response.
What the flaw actually is
Kestra is an open-source, event-driven orchestrator used to build and schedule data pipelines and automation workflows — the kind of tool that sits quietly in the middle of a data platform and runs everything else. Like many such tools it ships with Basic Auth enabled by default and a single public endpoint, the instance configuration, that is meant to be reachable without a login. The bug is in how that exception is enforced.
The AuthenticationFilter decides whether to demand credentials by calling request.getPath().endsWith("/configs"). That is a suffix match, not an exact-path match, so it does not just exempt the intended /configs endpoint — it exempts any API path whose final segment is configs. An attacker only has to append that segment to a protected route to walk straight past authentication. Once inside, they can create a Kestra flow containing script tasks — shell, Python, Node, Bash — and execute it, and those tasks run as root inside the platform's Linux worker container. That is unauthenticated remote code execution on the orchestration host, with no credentials and no user interaction.
The advisory also documents a secondary server-side request forgery: the Pebble template engine's http() function performs no URI filtering, so a crafted template can call internal services or a cloud provider's metadata endpoint. On a cloud-hosted instance that is a direct path to instance credentials and lateral movement. The primary auth bypass is the CVSS 10.0 headline, but the SSRF is what turns a single-host compromise into an environment-wide one.
Why orchestration platforms keep getting hit
This is not an isolated Kestra problem; it is the latest in a run of critical flaws in workflow and automation platforms. n8n, Langflow, MLflow and similar tools have all shipped unauthenticated or auth-bypass RCE bugs in the past year. The pattern is structural. Orchestration platforms exist to run arbitrary code and to reach everything they automate, so they accumulate database credentials, cloud keys, API tokens and internal network access as a matter of design. A single authentication gap on that kind of host is not one server compromised — it is a foothold into the pipelines, warehouses and cloud accounts behind it.
They are also easy to leave exposed. These tools start as an internal convenience, get a public URL for a quick demo or a remote teammate, and quietly stay reachable. Combine "runs code by design," "holds every secret," and "sometimes on the open internet," and you have exactly the profile attackers scan for. Anyone running a data platform — especially teams standing up data and ML pipelines quickly — should treat every orchestrator and automation server as tier-one infrastructure, not a background utility, because that is how attackers treat it.
What it means for US & EU software teams
The immediate implication is operational: a KEV listing with a public proof-of-concept means exploitation is not hypothetical, and internet-reachable, unpatched instances should be assumed compromised. The CISA deadline binds US federal agencies, but the signal — "this is being used in attacks now" — applies to everyone. If you cannot confirm your Kestra instance was patched before it was ever exposed, incident response, not just patching, is the right posture: rotate secrets and check logs, do not simply upgrade and move on.
There is a compliance dimension for regulated teams too. Under frameworks such as SOC 2, and under EU regimes like NIS2 and DORA, a known-exploited vulnerability on a system that touches production data is exactly the kind of finding auditors and regulators expect you to detect and remediate on a defined timeline. A worker that runs as root and can reach cloud metadata is not a low-severity footnote. The organisations that come out of this cleanly are the ones that can show an inventory, a patch record and a credential-rotation log — not the ones that discover weeks later that the tool was even in the estate.
The broader lesson is about supply-chain surface. Most teams did not write Kestra, but they own the risk of running it. Self-hosted open-source infrastructure trades vendor lock-in for the duty to track advisories and patch fast. That is a real cost, and it should be budgeted as one: someone needs to own the inventory of what you self-host, subscribe to its security advisories, and have a path to patch within hours when a CVSS 10.0 lands on the KEV list.
What to do right now
If Kestra is anywhere in your stack, the sequence matters more than the individual steps.
- Confirm whether you run Kestra, and which version. Check container images, Helm charts and self-hosted deployments; affected releases run up to and including 1.3.20.
- Upgrade immediately. Move to 1.3.21, 1.0.45 or any 1.4.0+ release. There is no durable workaround that leaves an affected version exposed.
- Get it off the public internet. Put any exposed instance behind a VPN or private network; an orchestrator should almost never face the open web.
- Rotate every reachable secret. Assume database credentials, cloud keys and API tokens the instance could touch are exposed, and rotate them — the SSRF path makes this non-optional on cloud hosts.
- Hunt for abuse. Review logs for unexpected flow creation or execution, and for outbound requests to metadata endpoints, around and before the patch date.
- Add it to your advisory watch. Make sure this and your other self-hosted platforms are on a monitored feed so the next KEV entry does not surprise you.
None of this is legal advice, and the specifics of your exposure depend on how Kestra is deployed. But the direction is unambiguous: a CVSS 10.0 auth bypass on a code-executing, secret-holding host, now on the KEV list, is a patch-today event — and the teams that already know what they self-host will close it in hours rather than weeks.
Frequently asked questions
What is CVE-2026-49869 in Kestra?
A CVSS 10.0 authentication bypass in Kestra OSS. The AuthenticationFilter whitelists the public config endpoint with a suffix check, request.getPath().endsWith("/configs"), instead of an exact match. Any API path whose last segment is configs bypasses Basic Auth, letting an unauthenticated attacker reach protected endpoints, create a workflow with script tasks and run it as root in the worker container.
Which Kestra versions are affected and what are the fixes?
It affects Kestra OSS releases up to and including 1.3.20 running with Basic Auth enabled, which is the default. It is fixed in 1.0.45, 1.3.21 and all 1.4.0+ releases. Upgrading is the primary remediation; there is no safe workaround that leaves an affected version exposed.
Is CVE-2026-49869 being exploited?
CISA added it to the Known Exploited Vulnerabilities catalog on 2 September 2026, its signal that reliable evidence of active exploitation exists, with a 5 September remediation deadline for US federal civilian agencies. A public proof-of-concept and scanner exist, so any internet-reachable, unpatched instance should be treated as compromised until proven otherwise.
What can an attacker do after exploiting this flaw?
Create and run Kestra workflows with shell, Python, Node or Bash tasks, which execute as root in the worker container — full remote code execution on the orchestration host. A secondary SSRF via the Pebble http() function, which lacks URI filtering, can be pointed at cloud metadata or internal services to steal credentials and move laterally.
What should teams running Kestra do right now?
Upgrade to 1.3.21, 1.0.45 or 1.4.0+ immediately. Take any internet-exposed instance off the public internet and behind a VPN. Rotate credentials, cloud keys and secrets the instance could reach. Then review logs for unexpected workflow creation or execution around and before the patch date.
Sources
Kestra — Official security advisory GHSA-5vc5-wxxq-3fjx, CVE-2026-49869 (primary source)
CISA — Known Exploited Vulnerabilities Catalog (primary source)
LinuxSecurity — Kestra critical Linux container RCE flaw exploited, CISA warns