Security Digest · Jun 3, 2026 · Vulnerability · CI/CD

Kestra CVE-2026-49869: Exploited Unauthenticated RCE

A /configs suffix check lets anyone create and run Kestra OSS workflows as root. Exploited for cryptomining, in KEV. Fixed in 1.0.45 and 1.3.21.

Our verdict

Act now

If you run Kestra OSS below 1.0.45 or 1.3.21 and anyone untrusted can reach its API, assume it is compromised: upgrade, then rotate every secret the workers could see.

Who must act: Teams self-hosting Kestra OSS 1.0.x before 1.0.45 or 1.1.0 through 1.3.20, especially where the API port is reachable from the internet or shared networks or the worker has the Docker socket mounted.

Who can relax: Teams that do not run Kestra, and Kestra users already on 1.0.45, 1.3.21 or any later release who have checked for signs of earlier compromise.

Affected
Kestra OSS before 1.0.45
Kestra OSS 1.1.0 through 1.3.20
Fixed in
Kestra OSS 1.0.45
Kestra OSS 1.3.21 (and later 1.3.x and 2.0.x releases)
CVSS
10.0 (v3.1, CNA)
EPSS
2.1% (percentile 81)
CISA KEV
Yes, listed as known exploited
Exploitation
Exploited in the wild
Severity
Critical

What to do

  1. Find every Kestra instance and its image tag or version.
  2. Upgrade to 1.0.45 or 1.3.21 or later; 1.1.x and 1.2.x users must move to 1.3.21+.
  3. Take the Kestra API and UI off the internet and put them behind a VPN or authenticating proxy.
  4. Rotate secrets reachable from workers: Kestra KV entries, environment variables of containers on the same Docker host, and cloud credentials.
  5. Stop mounting /var/run/docker.sock into workers unless required, and restrict worker egress.

How to check if you are affected or compromised

  • Search proxy and access logs for PUT, POST or DELETE requests to API paths ending in /configs; only GET /api/v1/configs is legitimate.
  • In Kestra, look for flows with the id configs, unexpected namespaces, executions nobody triggered, and missing execution logs.
  • On worker hosts, look for shells spawned by the Kestra Java process, XMRig, nohup-launched binaries and immutable files in temp directories (lsattr).
  • Check egress for 172.232.38.92:32991 and auto.c3pool.org, which Microsoft tied to this campaign.

What happened#

On June 3, 2026, Kestra published GHSA-5vc5-wxxq-3fjx, later assigned CVE-2026-49869, for an authentication bypass in its open-source orchestration platform. The bug sits in AuthenticationFilter, which was meant to let unauthenticated users load only the public configuration endpoint. It checked request.getPath().endsWith("/configs") instead of matching that path exactly. As a result, every API route whose last segment is configs skips Basic Auth.

That suffix check is enough for a full takeover, because an attacker can choose a flow's name:

  • PUT /api/v1/main/flows/<namespace>/configs creates a flow called configs containing a shell or Python task.
  • POST /api/v1/main/executions/<namespace>/configs runs it.

Script plugins ship enabled by default, so the commands run as root inside the worker container. The advisory includes a working proof of concept. It also notes that the Pebble http() function has no URL filtering, which allows server-side requests to internal services and cloud metadata. GitHub, as the CNA, scores the flaw CVSS 3.1 10.0. The fix shipped in 1.3.21 on June 2 and in 1.0.45.

On August 26, Microsoft described an intrusion and assessed with high confidence that initial access came through CVE-2026-49869. The Hacker News places the activity in late June. CISA added the CVE to KEV on September 2, with a September 5 deadline.

Who is affected#

According to the CVE and NVD records, Kestra OSS before 1.0.45 is affected, as is 1.1.0 through 1.3.20. The 1.1 and 1.2 lines have no fixed release, so users on them must move to 1.3.21 or later. Current releases, 1.3.44 and 2.0.7 (October 20), postdate the fix.

The advisory says the default Basic Auth mode is vulnerable. It also stresses that the instance does not need to face the internet: network access to the API port is enough, so a flat internal network also counts as exposure.

Do you really need to act?#

Yes, if you run Kestra OSS. The exploit is two unauthenticated HTTP requests, the PoC is public, and attackers have used it. Orchestrators are high-value targets because they hold credentials for everything they automate.

The case Microsoft documented shows how far the damage can reach. After getting a reverse shell from a workflow, the attacker used the worker's mounted Docker socket to read the environment variables, including secrets, of every container on the host. They then ran an XMRig miner and stored harvested data in Kestra's own key-value store to leave fewer files behind.

A single-user instance bound to localhost on a laptop is low risk, but upgrade it anyway. If you do not run Kestra, nothing here affects you.

What to do now#

  1. Inventory instances, for example docker ps --format '{{.Names}} {{.Image}}' | grep -i kestra on each host, and note the version tags.
  2. Upgrade to 1.0.45 or 1.3.21 or later, then recreate the containers. Do not just restart them.
  3. Remove direct exposure of the API and UI. Put Kestra behind a VPN or an authenticating reverse proxy, and limit which networks can reach its port.
  4. If an instance was reachable while unpatched, rotate its KV secrets, the cloud credentials available to workers, and any secrets held in the environment variables of containers on the same host.
  5. Following Microsoft's guidance, move secrets out of environment variables into a managed store, avoid mounting /var/run/docker.sock into workers, and set deny-by-default egress.

How to tell if you were hit#

In proxy or access logs, any PUT, POST or DELETE to a path ending in /configs is suspicious. The only legitimate request is GET on the configs endpoint. Inside Kestra, look for flows named configs, unfamiliar namespaces, executions nobody launched, odd encoded KV entries and missing logs. The advisory notes that the bypass can also delete execution logs.

On worker hosts, look for shells spawned by the Kestra Java process, nohup-launched miners, a harvest.sh script, and files made immutable in temp directories (lsattr). Microsoft lists 172.232.38[.]92:32991 as the reverse-shell endpoint and auto.c3pool[.]org as the mining pool.

Timeline#

  • — Kestra commits the fix to the authentication filter.
  • — Kestra 1.3.21 is released.
  • — Kestra publishes GHSA-5vc5-wxxq-3fjx, crediting Vasco0x4.
  • — The CVE-2026-49869 record is published.
  • — Microsoft publishes its analysis of an intrusion that likely began with this flaw.
  • — CISA adds the CVE to KEV, with a September 5 deadline.

Vulnerability records

  • CVE-2026-49869 · KEV 2026-09-02 · Kestra is an open-source, event-driven orchestration platform.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

  1. Kestra / GitHub — GHSA-5vc5-wxxq-3fjx: Unauthenticated RCE via authentication bypass in AuthenticationFilter github.com
  2. Kestra / GitHub — Release v1.3.21 github.com
  3. CVE record — CVE-2026-49869 cve.org
  4. NVD — CVE-2026-49869 nvd.nist.gov
  5. CISA — Known Exploited Vulnerabilities: CVE-2026-49869 cisa.gov
  6. Microsoft Security — When AI infrastructure becomes the target: Securing gateways and control points microsoft.com

Coverage and analysis

  1. The Hacker News — CISA adds seven exploited flaws as attackers deploy reverse shells and crypto miners thehackernews.com