CVE-2026-49869: Kestra's CVSS 10.0 Auth Bypass Flaw

CVE-2026-49869 lets an unauthenticated attacker create and run arbitrary workflows on a Kestra OSS instance. No login, no API key, nothing but a URL shaped the right way. The bug lives in a single string comparison inside Kestra’s AuthenticationFilter, it’s rated CVSS 10.0 (the maximum the scale allows), and CISA added it to the Known Exploited Vulnerabilities catalog on September 2. If your Kestra deployment is on a version below 1.0.45 or 1.3.21, patch it today, not this sprint.

What CVE-2026-49869 actually is

Kestra needed one route to work without authentication: a public config endpoint that tells a fresh install where to find login settings and feature flags before a user has logged in anywhere. To let that one path through, the AuthenticationFilter checked this:

request.getPath().endsWith("/configs")

That’s a suffix check, not a path check. It answers “does this URL end in the seven characters c-o-n-f-i-g-s,” which is a different question from “is this URL actually the config endpoint.” The two questions happen to have the same answer for the one path Kestra intended to exempt. They diverge for every other path that happens to share the same ending, and Kestra’s REST API has a lot of those, because it namespaces most resources by a name the caller supplies.

Name a workflow “configs” and you get /api/v1/main/flows/tutorial/configs. That URL ends in /configs. The filter waves it through with the same logic it uses for the real config endpoint, because from a suffix check’s point of view, they’re identical. GitHub’s advisory (GHSA-5vc5-wxxq-3fjx) lays out the resulting chain plainly: a PUT to a flows path ending in /configs creates a workflow with zero credentials presented, a POST to the matching executions path runs it, and the execution logs, reachable through the same bypass, hand back whatever the workflow printed. Three requests, no session token in any of them.

Why a bypass turns into root shell access

Being able to create and run a workflow without logging in would be a serious bug on its own. What makes this one a perfect 10 rather than a bad-but-contained one is what sits behind the door once you’re through it.

Kestra ships script-execution plugins, shell, Python, Node, and a few others, enabled by default. That’s not an edge feature bolted on for power users. Running scripts is close to the point of a workflow orchestrator; Kestra exists to schedule and execute real work, and real work is frequently a script. So a workflow an attacker creates isn’t limited to moving data between two connectors. It can have exactly one step: run this shell command. And Kestra’s worker processes execute as root inside their container by default, which means the command runs as root, not as some scoped-down service account.

Put those two facts together and the authentication bug stops being an authentication bug and becomes a remote code execution bug that happens to be triggered by an authentication bug. The advisory also flags a secondary path through Kestra’s template environment that can be abused for server-side request forgery, worth checking during incident response if you suspect you were already hit, since it can reach internal services or cloud metadata endpoints that a straightforward RCE check might miss.

Who’s affected, and how to check

Every self-hosted Kestra OSS instance on a version before 1.0.45 (on the 1.0.x line) or before 1.3.21 (on the 1.3.x line) is vulnerable, and that includes every 1.1.x and 1.2.x release in between. Check your running version:

curl -s https://your-kestra-host/api/v1/configs | jq .version

That endpoint really is meant to be public, so querying it isn’t itself risky. If the number that comes back is below the patched builds, or if you can’t confirm it from a live query, check your container image tag or deployment manifest directly instead of assuming.

There isn’t a meaningful stopgap short of upgrading. A reverse proxy sitting in front of Kestra doesn’t help here, because the broken comparison runs inside Kestra’s own filter chain, after your proxy has already forwarded the request along. You could add an exact-path rule at the proxy that rejects anything but the literal /api/v1/configs, but that’s a narrow workaround you’d have to get exactly right, not a substitute for the actual fix.

Patching and what to do after

Upgrade to 1.0.45 or 1.3.21, matching whichever line you’re already on. Kestra’s fix replaces the suffix comparison with an exact match, so a flow named configs no longer rides in on the coattails of the real config endpoint.

docker pull kestra/kestra:1.3.21

Restart the worker containers specifically, not just the webserver process. The worker is where the privileged execution actually happens, and an updated image with an old worker process still running keeps serving the vulnerable code path until that process is actually replaced.

After patching, treat the exposure window as a possible incident, not a closed ticket. Rotate secrets, connected-service credentials, and cloud IAM roles anything Kestra’s workers could reach, since an unauthenticated attacker who found this before you patched could have read or used them. Check your flow and execution history for anything you don’t recognize creating or running; the advisory’s exact URL pattern (a flow or execution ID ending in configs) is a specific, searchable thing to grep your logs for.

The September 2 KEV batch

CVE-2026-49869 landed in CISA’s Known Exploited Vulnerabilities catalog on September 2, as one of seven additions in a single day, an unusually large batch. Alongside Kestra: an unauthenticated SQL injection in Sangoma Switchvox, two separate SonicWall SMA1000 bugs (one SSRF, one command injection), and three we’ve written up on their own, because each is worth understanding on its own terms: Starlette’s Host-header parsing bypass, JFrog Artifactory’s forged admin tokens, and LiteLLM’s second MCP authentication bypass this year. Reporting on the batch describes attackers already using several of these to deploy reverse shells and crypto miners against exposed instances, not just scanning for them.

A KEV listing carries two different weights depending on who’s reading it. For U.S. federal agencies, BOD 26-04 turns it into a binding deadline, September 5 for this batch, not a recommendation. For everyone else, it’s one of the more reliable public signals available that a bug is being exploited right now, since CISA doesn’t add entries to that catalog on suspicion. If you’re trying to put a number on what a batch like this actually costs a team, in patch time or in a worse scenario, we broke down the real figures separately.

Four unrelated products landing in front of CISA in the same week doesn’t mean the bugs share a cause. They don’t. But they share a profile: infrastructure that gets stood up once, works, and stops getting looked at. A workflow orchestrator, an artifact repository, an LLM gateway, a web framework three dependency layers down, none of these get the same Tuesday-patch-cycle attention as an OS or a browser, and that’s exactly why bugs like this one sit unpatched for months once a fix exists.

The takeaway

If Kestra runs anywhere in your infrastructure, check the version today. Not because “CVSS 10.0” makes for a dramatic headline (it does), but because the actual defect, a suffix check standing in for a path comparison, is the kind of one-line mistake that’s obvious once you know to look for it and invisible until someone does. It’s worth grepping your own authentication middleware for endsWith() calls on request paths while you’re at it. This isn’t the first time that exact pattern has produced a full bypass, and Kestra won’t be the last codebase where it’s found.