Kestra's fourth flaw has no fix in any stable release

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.

The fourth flaw: SSRF through the template engine's http() (no CVE yet, CVSS 8.6)

On 23 July 2026 a new security advisory (GHSA-r56g-q4p6-m3p6) appeared on the project's GitHub. The target is http(), a function offered by Pebble, the template engine available inside Kestra's job definitions (Flow YAML). Whatever URL is written there was handed straight to URI.create() with no validation — no restriction on the destination address, none on the protocol scheme. Severity is CVSS 3.1 8.6 (High), class SSRF (CWE-918). The CVE number was still unassigned when the advisory went out.

No authentication is required. An attacker only has to import a crafted job definition and have it run, and the Kestra server makes the request on the attacker's behalf. The reachable destinations include private internal IP addresses, Kestra itself (localhost), schemes such as file:// and gopher://, and cloud metadata endpoints (169.254.169.254). 169.254.169.254 is a special address that a server running in the cloud uses to fetch the credentials assigned to it, so reaching it means the cloud master keys held by that server can be read straight out.

"Patched in 2.0.0" points at a version that does not exist

The weightiest fact here concerns the fix. The advisory lists the affected range as "everything before 2.0.0" and the patched version as "2.0.0." That 2.0.0 is not being shipped. Checking the public sources one by one on 29 July 2026 gives the following.

The conclusion is single-sentence: as of 29 July 2026, no stable release closes this SSRF. The newest v1.3.30 (28 July 2026), v1.0.53 on the LTS 1.0 line (same day), v1.2.24 (7 July 2026) and v0.22.46 (15 July 2026) are all unpatched. The usual routine — "the advisory names a fixed version, so update and you're done" — does not apply here.

[Re-checked 5 August 2026] The conclusion has not changed. v1.3.31 and v1.0.54 shipped on 4 August, but neither release note mentions a security fix and the advisory's patched-version field still reads 2.0.0. Two stable releases in a week, and this one hole is still sitting there.

Keep the difference from the earlier disclosures clear. CVE-2026-53576 and CVE-2026-49869 are fixed in 1.3.21 (1.0.45 on the older line), and the guidance in the rest of this article still holds; the password-storage flaw CVE-2026-55069 is closed in 1.3.24. The only hole left open is this SSRF. In practice that means two moves at once: updating to 1.3.24 or later remains mandatory, and network-side controls have to be layered on top for the SSRF.

What to do while there is no fix

The vendor's own security hardening guide already assumes exactly this class of attack. Five measures do the real work.

As for exploitation, nothing has been reported at the time of writing, and the flaw is not in CISA's KEV catalog (re-verified on 5 August 2026 against all 1,660 entries in the 4 August catalogue — no Kestra entry appears). A tool that probes for this SSRF alongside the earlier auth bypass has been published on GitHub, but it is a diagnostic, not a weaponised exploit — it states plainly that it is for "authorized defensive testing only." It is usable for checking whether your own environment is affected; we are not linking it here, since doing so would mostly help untargeted scanning.

Overview of the three earlier 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 earlier 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.

This table covers the three flaws above. The fourth one, the SSRF with no CVE assigned, affects every stable release including the latest v1.3.30. Moving to 1.3.24 or later does not close it, so handle that one with the network-side mitigations.

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. On top of that, because updating alone will not close the fourth flaw, block traffic to 169.254.169.254/32 with a network ACL and cut down the set of users who can import and run Flow YAML.

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.

Then, on 23 July 2026, a fourth flaw arrived: an SSRF through the template engine's http() function (GHSA-r56g-q4p6-m3p6, CVSS 8.6, no CVE assigned yet). The advisory names 2.0.0 as the fix, but 2.0.0 was never formally released — GitHub holds only release candidates. Every stable build is unpatched, the newest v1.3.30 included, which makes this one unsolvable by updating. Keep the two cases apart: the first three close when you upgrade, the fourth does not. For the fourth, put the block on 169.254.169.254/32 and the limits on Flow YAML imports in place first.

References

• ▸NVD - CVE-2026-53576
• ▸NVD - CVE-2026-49869
• ▸NVD - CVE-2026-55069
• ▸kestra-io/kestra - Security Advisories (GHSA list)
• ▸GHSA-r56g-q4p6-m3p6 - SSRF via the Pebble http() function (CVSS 8.6, no CVE yet)
• ▸kestra-io/kestra - Releases (fixes 1.3.21 / 1.3.24 / 1.0.45; latest v1.3.30)
• ▸Kestra Docs - Releases (newest line is LTS 1.3; no 2.0 listed)
• ▸Kestra Docs - Security Hardening (blocking 169.254.169.254/32 and more)
• ▸Kestra official site
• ▸PR Newswire - Kestra raises $25M Series A (scale and adopters)