ENDOR-VUL-2026-0202
Command Injection via the interpreter Property
01Record
| Project | Kestra |
|---|---|
| Component | AbstractExecScript.interpreter |
| CWE | CWE-78 |
| CVSS | 9.8 |
| Disclosed | 2026-08-08 |
| Endor reference | ENDOR-VUL-2026-0202 |
| Writeup | Link |
02Detail
Description: AbstractExecScript in Kestra through 1.2.0 exposes interpreter as a dynamic, Pebble-templated list of strings, and ScriptService.scriptCommands() passes that list to ProcessBuilder as the argument vector with no validation. A flow author selects the interpreter binary outright, so no shell metacharacter is needed: an interpreter of [/usr/bin/python3, -c, "import os; os.system('touch /tmp/pwned')"] executes on the Kestra host and the declared commands block is never reached. Where a flow carries a webhook trigger the sink is reachable without authentication, because Kestra webhooks are unauthenticated by default.
Impact: Command Execution. Code runs with the privileges of the Kestra process, reaching the credentials, task state, and internal network the worker holds.
Kestra closed the report as intended functionality, on the argument that executing scripts is the product and hardening the deployment is the operator's job, and recommends the Docker and Kubernetes task runners for isolation. No advisory was assigned and no patch is planned, so the compensating controls are the fix: authenticate every webhook trigger, treat flow-creation permission as host code-execution permission, and run tasks under an isolated runner rather than the process runner. Full analysis is in the technical whitepaper.
Discovered by Peyton Kennedy (p80n).