Kestra skips authentication for any request path that ends in the string "configs"

Kestra schedules and runs workflows, and before anyone logs in it has one job to allow: let the setup screen read the server's base configuration so it knows how login and feature flags are set. ^[1][2] Basic Auth is the default, and every API request passes through a single filter; when the path is on the allow list the filter proceeds without authentication. ^[8][9] The flaw is tracked as CVE-2026-49869. ^[15]

A dev.to writeup traces the hole to a suffix test at line 49 of AuthenticationFilter.java. `request.getPath().endsWith("/configs")` answers whether the tail of a path matches the string `/configs`, which is exactly what it promises. ^[3] What the code needed to know was whether the request was the public config endpoint. ^[4] For the endpoint the check was written for, both questions get the same answer. For any other path with the same ending, they don't. ^[17]

The gap was easy to use because Kestra names resources from caller input. The route `/flows/{namespace}/{flowId}` drops the flow id straight into the path. ^[5] Set the id to `configs` and the flow's write routes end in `/configs` too, so `endsWith`, which cannot separate a config read from a flow write, waves them through. ^[6][18]

Creating the flow executes nothing on its own. In the proof-of-concept a POST to the matching executions path triggers the run, clears authentication the same way, and a worker picks the execution up. ^[11] FlowController and ExecutionController together carry it from a created flow to code execution. ^[16]

The worker container runs as `uid=0(root)` out of the box. ^[13] So the flow's single shell task runs as root, and one broken check becomes unauthenticated remote code execution. ^[14]

The two legitimate endpoints are `GET /api/v1/configs` and `GET /api/v1/{tenant}/configs`. ^[7] An equality check against those, path and method both, would have passed the setup screen and admitted nothing else.