Kestra's Path Suffix Bug: When a Framework Forgets to Check the Whole Route

A patch released in June 2026 became an urgent remediation item in September. The reason is not that the fix was wrong, but that CISA added the vulnerability to its Known Exploited Vulnerabilities catalog after evidence of real attacks. The case is a useful study in the gap between a patch existing and a risk being closed.

What the vulnerability is

CVE-2026-49869 affects Kestra, an event-driven orchestration platform used for data, AI and infrastructure workflows. It is an operating system command injection reachable without authentication, rated 10.0 in the CISA KEV entry. The root cause is an authentication filter that matched request paths by suffix rather than by exact route.
The filter checked whether a path ended with /configs. A request to a path such as /api/v1/main/flows/tutorial/configs therefore passed the check. The filter did not verify that the request was actually addressed to the configuration endpoint, nor did it constrain the HTTP method. An unauthenticated caller could create a workflow and then trigger its execution.
Because Kestra workflows can run shell commands, the practical result is remote code execution with the privileges of the Kestra process.

Why a three-month-old patch became urgent

The timeline is the instructive part:

• 2 June 2026: Kestra 1.3.21 is released, with a changelog entry describing a fix for a potential authentication filter bypass.
• 3 June 2026: version 1.0.45 is tagged and advisory GHSA-5vc5-wxxq-3fjx is published, disclosing the affected range and the fixed versions.
• 26 June 2026: the CVE record enters the public data stream, making it visible to vulnerability management tooling.
• 2 September 2026: CISA adds CVE-2026-49869 to the KEV catalog, based on evidence of exploitation. The fix was available for three months before the KEV listing. The listing changed the priority, not the technical facts. That gap is where most of the risk lives.

The gap between patch availability and risk reduction

Four conditions have to be satisfied before a published patch actually removes risk from an environment:

1. The asset inventory knows Kestra is deployed.
2. Software composition analysis or image scanning can identify the version actually running, not the version someone believes is running.
3. The fixed version reaches the artifact repository and completes a production deployment.
4. After the vulnerability enters KEV, the team revisits historical exposure and the possibility of prior compromise. Each of these can fail independently. An organization can have the patch approved and still be running the vulnerable version in a container that was never rebuilt. It can have rebuilt the container and still not know the service was reachable from the internet.

Why the KEV listing matters

CISA adds a vulnerability to KEV when it has evidence of active exploitation. That is a different signal from a high CVSS score. A CVSS score describes potential severity in the abstract; a KEV listing describes observed attacker behavior against real targets.
For defenders, the KEV listing is a scheduling instruction. It says the theoretical risk has become a practical one, and the remediation window should be measured in days.

Affected versions and fixes

Kestra addressed the flaw in 1.0.45 and 1.3.21. Systems running 1.3.20 or earlier in the 1.3 line, or 1.0.44 or earlier in the 1.0 line, are affected.
Where immediate upgrade is not possible, the reported interim measure is to block, at a reverse proxy, requests that do not target /api/v1/configs but still end in /configs. Direct public access to the Kestra service port should be removed in any case. This is a compensating control, not a fix.

Verification steps

For environments that ran an affected version while reachable, the check should go beyond version confirmation:

1. Confirm the running version against the fixed versions.
2. Review workflow definitions for entries that were not created by a known operator, particularly ones with shell command tasks.
3. Search execution logs for runs that were not triggered by a scheduled or user-initiated workflow.
4. Review network logs for requests to paths ending in /configs from unfamiliar sources.
5. Rotate any credentials or secrets that were reachable from the Kestra process.

The broader pattern

CVE-2026-49869 is an authentication filter defect, which places it in a well-populated category. Filters that match on partial paths, that ignore the HTTP method, or that rely on string suffix comparisons rather than structured route matching tend to produce exactly this outcome: a route the developer did not intend to expose becomes reachable without credentials.
The defensive implication is that authentication checks should be expressed against the same route definitions the application uses to dispatch requests, not against string patterns that approximate them. When the two representations diverge, the gap is where bypasses live.

Limits of the current picture

The public record establishes the flaw, the fixed versions and the KEV listing. It does not establish how many instances were attacked, what the attackers did after gaining execution, or whether the observed exploitation was targeted or opportunistic. Those questions remain open.

References

• GitHub Security Advisory GHSA-5vc5-wxxq-3fjx for Kestra
• Kestra release notes for 1.0.45 and 1.3.21
• CISA Known Exploited Vulnerabilities catalog entry for CVE-2026-49869, added 2 September 2026
• NVD record for CVE-2026-49869