Kestra's Login Bypass Was One Line of Code. Attackers Mined Crypto With It for Two Months Before CISA Noticed.
CVE-2026-49869 exists because a Java filter checks whether a path ends in "/configs" instead of matching it exactly. Microsoft traced a threat actor exploiting it since late June — root shell execution, Docker socket enumeration, an XMRig miner, and exfiltration hidden inside Kestra's own key-value store.
A single misplaced string check in Kestra's login filter let anyone on the network create and run arbitrary workflows without a password. Microsoft's threat-intel team says someone found it in late June 2026 — and used it to mine Monero and rifle through other containers' secrets for roughly two months before CISA added the bug to its Known Exploited Vulnerabilities catalog on September 2.
Scores as of 2026-09-10live record →
One endsWith() call
Kestra is an open-source, event-driven workflow orchestrator — the kind of tool that sits in front of data and AI pipelines, wiring together scripts, triggers, and scheduled jobs. Its AuthenticationFilter is supposed to let one endpoint, the public config page, skip login. According to Kestra's own GitHub Security Advisory (GHSA-5vc5-wxxq-3fjx), the whitelist check in AuthenticationFilter.java looks like this:
// AuthenticationFilter.java, webserver module, line 49
boolean isConfigEndpoint = request.getPath().endsWith("/configs");From bypass to root shell
Per the advisory, an attacker can PUT a malicious flow to a path like /flows/{namespace}/configs, then POST to /executions/{namespace}/configs to run it — no credentials required. Kestra ships script-execution plugins (shell, Python, Node) enabled by default, so that execution runs as root inside the worker container.
CVE-2026-49869: from an unauthenticated PUT to a cryptominer
- Unauthenticated PUT to /flows/{ns}/configs
- Unauthenticated POST to /executions/{ns}/configs
- Shell/Python plugin runs as root
- Worker's Docker socket queried for container Env arrays
- Secrets harvested from other running containers
- XMRig miner + curl-pipe-shell output stored via Kestra's own KV API
What Microsoft watched happen since June
Microsoft published a forensic writeup on August 26, 2026, assessing with high confidence that a threat actor's initial access ran through this exact bug starting in late June — months before CISA's KEV listing. The telemetry shows a four-stage compromise.
The Kestra compromise, per Microsoft's telemetry
- Two closely timed shell sessions from the workflow engineThe first produced shell initialization activity; the second performed the main follow-on actions.
- Docker socket queried, container secrets exposedThe attacker inspected Config.Env arrays across all running containers, collecting embedded cloud, database, and API credentials from other workloads on the host.
- XMRig v6.26.0 deployed with RandomX MSR tuningMiner binary retrieved from a public release source, renamed, and run in the background with CPU-tuning behavior toward a Monero mining pool; restrictive permissions and immutable-file attributes were set on temp paths for defense evasion.
- curl-pipe-shell data harvestingA script (referenced as harvest.sh in Microsoft's detection table) collected host data; output was encoded and stored through Kestra's own key-value interface instead of written to disk.
- Microsoft publishes the forensic writeup"When AI infrastructure becomes the target: Securing gateways and control points."
- CISA adds CVE-2026-49869 to KEVOne of seven vulnerabilities added that day; federal agencies given a 3-day remediation window under BOD 26-04, due September 5.
The Kestra compromise exposed four 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.
| Indicator | Type | Role |
|---|---|---|
| 172.232.38.92:32991 | IP:port (Linode VPS) | Reverse-shell C2 |
| auto.c3pool.org:443 | Domain | XMRig Monero mining pool |
| 2001:41d0:701:1100::adfd | IPv6 address | c3pool mining endpoint |
| 47.86.197.116 | IPv4 address | c3pool mining endpoint |
Three of the seven target AI infrastructure
CVE-2026-49869 didn't ship alone. It was one of seven vulnerabilities CISA added to KEV on September 2, and three of the seven sit in AI/ML-adjacent infrastructure — Kestra (data/AI pipeline orchestration), LiteLLM (an AI gateway), and Starlette (the ASGI framework underlying vLLM, LiteLLM, and MCP servers). Reporting on the batch called it the first KEV wave where AI components made up nearly half the additions.
| CVE | Vendor / product | CVSS | Our priority |
|---|---|---|---|
| CVE-2026-49869 | Kestra OSS | 10.0 | critical |
| CVE-2026-9586 | Sangoma Switchvox | 9.8 | critical |
| CVE-2026-82329 | JFrog Artifactory | 9.8 | critical |
| CVE-2026-83548 | SonicWall SMA1000 (SSRF) | 10.0 | critical |
| CVE-2026-83549 | SonicWall SMA1000 (OS command injection) | 7.8 | high |
| CVE-2026-59822 | BerriAI LiteLLM | 8.2 | high |
| CVE-2026-48710 | Kludex Starlette | 6.5 | medium |
Our own signals still lag the reality
What to do
- Upgrade to Kestra 1.0.45 or 1.3.21 — there is no configuration-level workaround for this bug.
- Audit worker containers for flows or executions you don't recognize, particularly any created via routes ending in
/configs. - Check whether your Kestra worker has the Docker socket mounted; if it does, assume any secret in another container's environment on that host may have been read.
- Rotate credentials that were reachable from the worker container's environment during the exposure window.
- Inspect your Kestra key-value store for unexpected entries — this actor used it as an exfiltration channel, not just workflow state.
- Hunt for the IOCs above (the C2 IP and c3pool mining infrastructure) in outbound connection logs.
CVE and KEV data as of 2026-09-10live record →