Any Kestra API path ending in /configs skipped Basic Authentication

The filter did not parse the route. It asked whether the request path string ended in `/configs`, and when it did, Basic Authentication was skipped ^[3]. Kestra's API also accepts `configs` as a caller-controlled resource identifier on other routes, so protected endpoints could be reached with no credentials at all ^[4].

The patch normalizes the path and matches the public configuration endpoint exactly as `/api/v1/configs`, and it adds regression tests confirming that other paths ending in `/configs` return `401 Unauthorized` ^[6]. An exact match on one known route, plus tests that encode the failure mode, is the fix I would want to see.

The 10.0 comes from what the product does. Kestra's documented job is to define and schedule workflows, run shell, Python and Node.js tasks, connect to databases, cloud services, message systems and internal APIs, and store flow configuration, variables and run logs ^[7]. Script execution plugins ship enabled by default ^[5]. So the chain is short: an anonymous caller creates a workflow through a route that satisfies the suffix check, triggers it, and the platform runs the script task, with no separate command-injection bug required ^[8].

The exposure numbers are where the story gets softer. Two ZoomEye queries run on 2026-09-16 with scope `all` returned 119 assets for `app="Kestra"` ^[9] and 231 for `title="Kestra"` ^[10], a ratio of about 1.9 to one ^[22]. Those are two different signals on the same product: an `app` fingerprint matches the application as the scanner identifies it, while a `title` match reads the HTML title of the page ^[13]. A higher title count is common where a login or landing page carries a recognizable title and the application fingerprint is narrower ^[14]. The two sets overlap, so the counts cannot be added. Neither is a count of exposed instances ^[15]. `app="Kestra OSS"` returned zero assets, because that string is not a valid product fingerprint in the index ^[11]. A CVE query returned zero as well, which reflects indexing lag ^[12].

The write-up's first recommended step is to cross-check the public counts against your own inventory, since orchestrators are often stood up by platform or data teams and may never reach the central asset register ^[18]. That step is sound, and the data behind it is thinner than the case for it: the 119-versus-231 gap describes how one index fingerprints Kestra, not how well any organization tracks its own orchestrators. The counts also leave open which version each instance runs, whether it is reachable beyond the scanned port, whether an upstream authentication layer sits in front, and whether any instance has already been accessed ^[16].

Affected versions run up to and including Kestra OSS 1.3.20, expressed in the CVE data as `< 1.0.45` and `>= 1.1.0, < 1.3.21`, with fixes in 1.0.45 and 1.3.21 ^[17]. Until an upgrade lands, the source's advice is to restrict the API at the network layer to trusted administrative entry points and enforce authentication at the upstream proxy instead of the application filter ^[20]. Internal-only does not mean safe here, because an attacker already on an office, development or cluster network can exploit an instance that is not internet-facing ^[19]. And scanning is not the end of it: unexpected flows, unfamiliar executions, key-value changes, deleted logs and script tasks from unknown sources are the things to look for, along with whatever the worker could reach at cloud metadata endpoints or in database credentials ^[21].