One endsWith Call Away From Root: The Kestra Auth Bypass Attackers Are Already Using

Here's the entire diff between "critical, CVSS 10.0, actively exploited by cryptomining crews" and "this endpoint is fine": one word. endsWith became equals. That's the whole fix for CVE-2026-49869, an authentication bypass in Kestra OSS that CISA added to its Known Exploited Vulnerabilities catalog on September 2, 2026, with a federal remediation deadline of September 5 — three days, because attackers were already inside.

I've configured enough reverse proxies and auth filters over the years to know exactly how this class of bug gets written. Someone needed one endpoint — a health check, a public config page, something genuinely meant to be reachable without a password — to skip the auth layer. They reached for a string comparison, picked the wrong one, and shipped it. It happens constantly. What makes this one worth a full write-up isn't the bug itself, which is almost boring in its simplicity. It's what sat behind that one endpoint: an orchestration engine that runs arbitrary shell and Python scripts by default, as root, inside its own worker containers.

What Actually Happened

Kestra is an open-source, event-driven workflow orchestration platform — the kind of tool a data team spins up to schedule pipelines, trigger ETL jobs, and glue together whatever mix of Python scripts, shell commands, and API calls keeps a company's data flowing. It sits in the same category as Airflow or Prefect: popular with data engineers, usually deployed with minimal ceremony, and rarely on the security team's radar because nobody outside the data org asked for it.

Kestra's AuthenticationFilter class needed to let unauthenticated requests reach the public /configs endpoint — a page that exposes non-sensitive runtime configuration, the kind of thing a frontend might poll before a user even logs in. The check deciding whether a request could skip Basic Auth looked like this:

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

Read that literally: it doesn't check whether the path is /configs. It checks whether the path ends with /configs. Those are very different questions to a routing layer, and the difference is the entire vulnerability. /api/v1/executions/configs ends with /configs. So does /anything-you-want/configs, and so does any crafted path an attacker appends configs onto. Every one of those sails past the auth filter, because the filter was never asking "is this the safe endpoint" — it was asking "does this string end in the right six letters."

Kestra fixed it in versions 1.0.45 and 1.3.21 by swapping endsWith() for equals(). That's the entire patch. GitHub tracks it as GHSA-5vc5-wxxq-3fjx.

Why a Config Leak Became Root RCE

A suffix-match bug on one endpoint would normally be a configuration-disclosure issue — annoying, not catastrophic. What turns this into a CVSS 10.0 is that the bypass isn't scoped to /configs at all. Because the filter sits in front of the whole API and the check is so loose, an unauthenticated attacker can reach far more than the configuration page — including the endpoints that create and execute workflows.

And Kestra, like most orchestration platforms, ships with script-execution plugins enabled out of the box: plugin-script-shell, plugin-script-python, and siblings. Running a shell command inside a workflow isn't abuse of the product — it's the product's entire job. So the moment an attacker can create a workflow without logging in, they can create one that runs id, or a reverse shell, or a Monero miner, and Kestra will happily execute it as root inside the worker container, because that's exactly what it's designed to do for legitimate workflows too.

That's the pattern worth remembering: the auth bypass was necessary, but the default-enabled script plugins are what made it catastrophic instead of merely embarrassing.

The Kill Chain: What Attackers Actually Did

This one didn't stay theoretical. According to Microsoft, a threat actor was very likely exploiting CVE-2026-49869 as far back as late June 2026 — over two months before CISA's KEV listing caught up with it. The observed campaign is opportunistic and financially motivated, not the work of a sophisticated APT, which is exactly what makes it a good case study: this is the kind of automated, commodity attack that finds every exposed instance of a vulnerable product within days of a scanner picking it up.

Recon and bypass. The attacker sends a single crafted HTTP request to a Kestra API path ending in /configs, skipping Basic Auth entirely. No credentials, no exploit chain, no user interaction required.
Workflow creation. Using the now-unauthenticated API access, the attacker defines a new workflow that uses Kestra's Process runner to execute an arbitrary shell command.
Shell access. The workflow executes, and the attacker effectively has a shell — as root, inside the worker container, with no logged-in session anywhere in sight.
Docker socket enumeration. Where the worker container has the Docker socket mounted (a common pattern for orchestration workers that need to spin up containerized tasks), the attacker enumerates it to pull environment variables from sibling containers — cloud credentials, database passwords, API tokens.
Cryptominer deployment. The attacker retrieves XMRig from a public source, renames the binary to evade basic detection, and starts mining Monero on the compromised host's compute.
Persistence and follow-on collection. Further curl | sh patterns pull additional scripts, and — in a detail I found genuinely clever — encoded output gets stashed inside Kestra's own key-value store, using the orchestration platform's legitimate state-storage feature as a covert exfiltration channel.

Microsoft summarized the blast radius as four distinct impact paths: shell execution through the workflow engine, container-environment exposure through Docker socket access, host resource hijacking through miner deployment, and follow-on collection through workflow task execution. Four separate ways to extract value from one authentication check that compared the wrong two strings.

CVE-2026-49869 at a Glance

Attribute	Detail
CVE ID	CVE-2026-49869
Component	`AuthenticationFilter`, Kestra OSS
Root cause	`request.getPath().endsWith("/configs")` suffix match instead of exact path comparison
CVSS score	10.0 (Critical)
EPSS score	0.99% (60th percentile)
Affected versions	All releases prior to 1.0.45 (1.0.x line) and 1.3.21 (1.3.x line)
Fixed versions	1.0.45 and 1.3.21
CISA KEV listing	Added September 2, 2026
Federal remediation deadline	September 5, 2026
Observed exploitation	Since at least late June 2026, per Microsoft
Payload observed	Reverse shell, Docker socket recon, XMRig cryptominer, KV-store exfiltration

My Take

I don't think the interesting story here is Kestra specifically. It's how predictable this shape of bug is, and how much damage it does specifically because of where these tools sit in a real environment.

In every infrastructure I've managed, orchestration and automation platforms accumulate access faster than anyone tracks. A workflow engine that feeds a warehouse ends up with a database credential. One that triggers deployments ends up with cloud API keys. One that talks to a dozen SaaS tools ends up with a dozen tokens sitting in its secrets store. Nobody sits down and designs that blast radius on purpose — it just grows, one integration at a time, because the whole point of the tool is to be plugged into everything. That's precisely why an auth bypass on an orchestration platform is worse than an auth bypass on, say, a marketing CMS: the CMS holds blog drafts, the orchestration engine holds the keys to everything it touches.

The second thing that stands out to me, and the nFlo write-up made a point I think is worth repeating: the same week this bug went public, a strikingly similar class of flaw — an incomplete string comparison standing in for a real authorization check — turned up in an entirely unrelated product, Visual Studio Code. I've seen this pattern often enough in infrastructure reviews to know it isn't a coincidence of timing. endsWith(), startsWith(), and contains() get reached for constantly when a developer needs "close enough" matching for something like a file extension or a URL prefix, and every one of them is a trap when it ends up gatekeeping something that actually matters. It's not a sophisticated vulnerability class. It's a code-review blind spot, and it keeps recurring because a "does this look right" review misses it just as easily as an automated scanner does — unless someone is specifically trained to ask "match against what, exactly?" every time a comparison decides who gets in.

And the part that would worry me most if I were running infrastructure today isn't the vulnerability itself — it's the discovery problem. Data platforms like Kestra get stood up by a data team on shared infrastructure, often without a ticket, definitely without a security review, because it solved a scheduling problem on a Tuesday afternoon. The nFlo piece calls this out directly, and it matches what I've seen everywhere I've worked: the riskiest system in the environment is very often the one nobody remembered to put on the asset inventory.

What You Should Do Right Now

Find out if you're running Kestra at all. Check container registries, Kubernetes namespaces, and any internal "we built this ourselves" data tooling. If your data or platform team owns a workflow scheduler you didn't provision, ask what it is.
Patch to 1.0.45 or 1.3.21 immediately if you find an instance — don't wait for a maintenance window. Exploitation takes one HTTP request; there is no meaningful mitigation short of the fix or taking the instance offline.
Pull the instance off the public internet now if patching can't happen today. Restrict API access to a VPN or internal network while you plan the update.
Audit every defined workflow for anything that wasn't created through your normal change process — no linked ticket, no known author, especially anything invoking shell or Python execution against external URLs.
Check execution history for off-schedule runs — jobs firing outside their cron windows, at odd hours, or with no traceable trigger are the signature of an attacker-created workflow.
Rotate every credential the worker container could reach — database passwords, cloud API keys, source-control tokens, anything in environment variables or a mounted secrets volume. Treat all of it as burned until you've confirmed otherwise.
Check for a mounted Docker socket on the worker containers and remove it unless a workflow genuinely needs to launch sibling containers. It's the single detail that turned this from "attacker has a shell in one box" into "attacker can see every credential on the host."
Disable script-execution plugins you don't actually use. If your Kestra deployment doesn't need plugin-script-shell or plugin-script-python, remove them. It won't stop the next auth bug, but it will stop the next auth bug from being an instant root shell.

This article was researched and drafted with AI assistance as part of an experiment in building a faster tech-writing workflow, then reviewed and edited before publishing.

Primary source: CVE-2026-49869: Authentication Bypass in Kestra OSS — One endsWith and Full RCE as Root — nFlo, September 2, 2026

Secondary sources: CISA Adds Seven Exploited Flaws as Attackers Deploy Reverse Shells and Crypto Miners — The Hacker News, September 2026; CISA Adds Seven Known Exploited Vulnerabilities to Catalog — CISA, September 2, 2026; GHSA-5vc5-wxxq-3fjx — GitHub Security Advisories