Kestra's 10.0 auth bypass reaches CISA's exploited list 91 days after the fix shipped

The suffix rule meant Kestra's filter and its request handling disagreed about what a request was for ^[3]. A dev.to write-up that measured the flaw's exposure explains the split: the filter judged the path string, and the application then sent the request to whichever endpoint it actually addressed ^[3]. Suffix matching is the sort of check that passes every test its author thought to write. Nothing more is needed after that, because running shell commands is an ordinary workflow step ^[4]. The write-up cites the CISA entry for the 10.0 rating ^[2].

Ninety-one days separate the fix, available on 3 June 2026, from CISA's listing on 2 September ^[15]. In the write-up's account, the technical facts did not change in that interval. The evidence of exploitation did, and the listing turned a scheduled upgrade into an urgent one for anyone still behind ^[14]. The write-up does not say when exploitation began, and it names only the two fixed releases, not the full affected range. Without a start date, the period to examine runs back to the first day an instance was reachable on a vulnerable build ^[11].

The measurement section is careful with its own numbers. The ZoomEye title search found 110 more matches than the application fingerprint ^[16]. The fingerprint has to identify the product from service evidence, which is a stricter test than finding a string in a page title ^[8]. The write-up states that neither count is a count of vulnerable instances ^[8]. For either figure to describe one team's risk, that team's Kestra would have to face the internet ^[17]. According to the write-up, most deployments sit on private networks, reached by VPN or an internal address, and never show up in the scan ^[17].

I think a Kestra compromise check should start from the list of credentials its workflows hold. Code running as the Kestra process can use whatever the process can reach, and the instance holds the credentials its workflows use ^[4][10].

The write-up puts the defect in a familiar category ^[12]. Filters that match partial paths, ignore the HTTP method, or compare string suffixes instead of structured routes tend to expose endpoints their developers did not mean to expose ^[12]. Its recommendation is to express authentication decisions against the same route definitions the application uses ^[13].