Critical Kestra flaws (CVE-2026-53576/49869): unauthenticated root RCE

Critical vulnerabilities have been disclosed in Kestra, the fast-growing "control tower" software for running many tasks automatically, that let anyone seize admin-level control and take over the entire server without logging in (CVE-2026-53576 and CVE-2026-49869). The CVSS severity for both is a perfect 10.0 (Critical). A third flaw involving weak admin-password storage (CVE-2026-55069, 8.7) was disclosed at the same time. Fixes ship in 1.3.24 (and 1.0.45 on the older line).

Kestra is a platform that bundles the orchestration of "running many tasks automatically in a set order and under set conditions." It is said to be used by more than 30,000 organizations — including Bloomberg, Toyota, JPMorgan, and Apple — and its GitHub stars, a measure of attention, exceed 26,000. These flaws are extremely dangerous because they let an attacker take over that control tower simply because it is exposed to the internet or an internal network, with no authentication. This article walks through what happens, who is at risk, and what to do now.

Overview of the three flaws

Here are the essentials at a glance. The two most severe ones require no login at all and can be exploited straight over the network. There is not even a "small user action" as a trigger — they succeed just by sending a crafted request to an exposed Kestra.

The scores reach a perfect 10.0 because the attack succeeds with no authentication, remotely, and with no user interaction, and because the damage reaches beyond Kestra's container to the server itself. The two severe flaws were published as security advisories (GHSA) on the project's GitHub, reported by security researcher @Vasco0x4 and by Jan Kahlen of the security firm turingpoint, respectively. Fixed versions are available for all three.

Who targets this, and why

What makes these two stand out is that the attack doesn't even require tricking a legitimate user. The target doesn't have to open or click anything; the only condition for success is "traffic can reach that Kestra." The people who go after this are attackers who mechanically scan the internet for exposed admin consoles, ransomware crews who encrypt servers for ransom, and initial-access brokers who sell the foothold they gained to other criminals. To them, an automation platform is a "hub of connection details" for the many internal systems, databases, and clouds it touches — a perfect target that spreads damage fast once seized.

The method goes like this. The attacker sends a URL with only its suffix doctored to slip past the authentication gate, creates and runs an automated job carrying shell commands, and gains admin (root) privileges on the server. From there it cascades. If Kestra's container is connected to the underlying server, the host OS is taken over too. By another path, the internal network or cloud configuration (where credential keys sit) can be read out, handing over the master keys to production.

The damage falls on the IT and data-platform teams that operate Kestra, and on the business. Once the control tower is seized, it's a straight line to the leak of all the data it handles, halted operations, intrusion into production, and spillover to partners. The third flaw, on top of this, lets anyone who can read the database crack the admin password offline, enabling privilege escalation from the inside. The shortest way to cut off the entry point is to narrow exposure and update to the latest version.

What Kestra is

Kestra is a French-born open-source "workflow orchestration platform." The term is unfamiliar, but in short it is a control tower that manages the steps for running many processes automatically in a set order, under set conditions, at set times. For example, "every night, collect data, transform it, aggregate it, and deliver a report," or "receive code, test it, and publish it if it passes" — it runs such chains without manual effort.

Well-known software in the same role includes the long-standing Prefect and Apache Airflow. Where those largely assume programming (Python) knowledge, Kestra spread rapidly thanks to the convenience of defining the flow in an easy-to-read format called YAML. It announced a $25M Series A in March 2026, and the workflows executed in 2025 alone are said to number 2 billion.

By nature, such a platform holds connection details to many internal systems, databases, and clouds. That is exactly why being guarded by authentication is the fundamental premise; when that gate is breached, damage concentrates at one point and grows large. These two flaws are, precisely, a hole in that gate itself.

Looking at the three flaws individually

CVE-2026-53576 / CVE-2026-49869: doctor a URL suffix and walk past the gate (CVSS 10.0)

The two perfect-score holes share a root cause. To allow a few URLs that may be accessed without logging in (the configuration pages whose path ends in /configs), Kestra's authentication gate checked whether the URL ends in /configs. The problem is that this was a naive "suffix match" (endsWith("/configs")). According to the published advisories, an attacker who crafts a URL like /api/v1/main/flows/tutorial/configs — made to merely end in /configs — can run operations that should require authentication, unauthenticated.

Past the gate, the attacker can create and immediately run a workflow carrying shell commands, with no login. Because execution runs as root (highest privilege) inside Kestra's worker container, the damage is severe. In CVE-2026-53576, when the container can see /var/run/docker.sock (the window for operating Docker), that becomes a foothold to take over the underlying server OS. In CVE-2026-49869, the template engine's request feature lacks URL restrictions, enabling an SSRF attack that reads internal services and cloud configuration (where credential keys sit). Both affect 1.3.20 and earlier and were fixed in 1.3.21 (or 1.0.45 on the older line).

CVE-2026-55069: the admin password gets cracked offline (CVSS 8.7)

The third flaw is the weakness of how the login password is stored. In Kestra's basic auth, the admin password was stored using SHA-512, a "fast to compute" method. Password storage should deliberately use a slow method to make brute-force cracking hard. When it's fast, someone who can read the database can take the stored value and brute-force it quickly on their own machine to recover the original password.

According to the advisory, when running on Kubernetes (the system for operating containers at scale), the cracked admin privilege becomes a foothold to reach service-account tokens and all stored secrets, expanding to even greater privilege. Because exploitation requires database read access, the severity stops short of 10.0, but combined with the two flaws above the damage grows. The fix is 1.3.24; updating to 1.3.24 or later reliably closes all three at once.

Quick check: are you affected?

Your risk changes greatly depending on whether you use Kestra, where it is exposed, and which version it is. Find your situation below. Check the version in the admin console or with kestra --version.

The most dangerous case is when the Kestra admin console or API is reachable directly from the internet. As a stopgap until you can update, blocking external access (placing it behind a firewall or VPN) is strongly recommended. Configurations that pass /var/run/docker.sock into the container deserve priority review, since damage there spreads to the host.

Is it being exploited?

Let's separate what we know from what we can't confirm yet.

What operators should check now

The top priority is updating Kestra to 1.3.24 or later (or 1.0.45+ if you are on the older line). Reaching 1.3.24 closes the two perfect-score flaws and the password issue at once. If updating right away is hard, as a stopgap block external access and limit exposure to inside a trusted network. Also check whether you pass /var/run/docker.sock into the container and whether database access rights are too broad.

In environments that exposed an old version externally, check for traces of intrusion (workflows or run histories you don't recognize) and, if needed, consider rotating the connection details Kestra holds (cloud credential keys, database credentials). For other attacks aimed at automation and data platforms, the takeover flaw in Prefect is a recent reminder. You can quickly inspect the external plugins and components your platform pulls in with our free OSS vulnerability scanner. For movements on serious vulnerabilities affecting companies, see our 2026 roundup of major vulnerabilities as well.

FAQ

Summary

CVE-2026-53576 and CVE-2026-49869 in the automation control tower Kestra are worst-class flaws: because the auth gate naively checked only "does the URL end in /configs," disguising the suffix walks straight past it, lets an attacker run commands as root without logging in, and even seizes the server itself. Both score a perfect CVSS 10.0. The third, CVE-2026-55069, is that the admin password was stored in an easily crackable form. The fix is simple: update Kestra to 1.3.24 or later and narrow external access. Above all, environments exposing the admin console directly to the internet should treat this moment as dangerous and act now.

References

• ▸NVD - CVE-2026-53576
• ▸NVD - CVE-2026-49869
• ▸NVD - CVE-2026-55069
• ▸kestra-io/kestra - Security Advisories (GHSA list)
• ▸kestra-io/kestra - Releases (fixes 1.3.21 / 1.3.24 / 1.0.45)
• ▸Kestra official site
• ▸PR Newswire - Kestra raises $25M Series A (scale and adopters)