Spots 
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: The asset inventory knows Kestra is deployed.
Software composition analysis or image scanning can identify the version actually running, not the version someone believes is running. The fixed version reaches the artifact repository and completes a production deployment.
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. For environments that ran an affected version while reachable, the check should go beyond version confirmation: Confirm the running version against the fixed versions.
A patch released in June 2026 became an urgent remediation item in September.